From owner-freebsd-bugs@FreeBSD.ORG Sat Mar 10 01:50:01 2012 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3E201065674 for ; Sat, 10 Mar 2012 01:50:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 810598FC14 for ; Sat, 10 Mar 2012 01:50:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2A1o1kB081931 for ; Sat, 10 Mar 2012 01:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2A1o1O7081930; Sat, 10 Mar 2012 01:50:01 GMT (envelope-from gnats) Resent-Date: Sat, 10 Mar 2012 01:50:01 GMT Resent-Message-Id: <201203100150.q2A1o1O7081930@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Adrian Chadd Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48FF6106566C for ; Sat, 10 Mar 2012 01:44:06 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 387EB8FC12 for ; Sat, 10 Mar 2012 01:44:06 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id q2A1i6OP053624 for ; Sat, 10 Mar 2012 01:44:06 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id q2A1i5dF053614; Sat, 10 Mar 2012 01:44:05 GMT (envelope-from nobody) Message-Id: <201203100144.q2A1i5dF053614@red.freebsd.org> Date: Sat, 10 Mar 2012 01:44:05 GMT From: Adrian Chadd To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: kern/165895: [ath] overly busy cabq can tie up all tx buffers X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 01:50:01 -0000 >Number: 165895 >Category: kern >Synopsis: [ath] overly busy cabq can tie up all tx buffers >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Mar 10 01:50:01 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release: FreeBSD-HEAD >Organization: >Environment: -MIPS, AR9130 AP (TP-WR1043nd) >Description: In a congested air environment with a very busy broadcast traffic LAN (in my instance, a _lot_ of IPv4 ARP and IPv6 ND frames) the CABQ can fill up with traffic and tie up all the tx buffers. This stops things such as management traffic (ie, probe response/authentication frames) from successfully transmitting. >How-To-Repeat: * AR9130 AP * _VERY_ busy 2.4GHz environment * configure in HT/40 mode * inject a lot of broadcast traffic sysctl dev.ath.0.txagg will show the CABQ (queue 8) will be constantly filled with traffic. >Fix: In the short term, we should just limit the amount of data going into the multicast queue. This includes power save traffic, so we need to be careful. In the longer term, when we decouple ath_buf TX from actual software TX queues, we may wish to buffer some frames in the avp->av_mcastq before we assign them a hardware TX ath_buf + descriptor. We still will have a problem with traffic filling up. There may be a radio configuration issue causing it to think the air is overly congested. I'll investigate that in a separate PR. >Release-Note: >Audit-Trail: >Unformatted: