From owner-freebsd-bugs@FreeBSD.ORG Sun May 20 17:30:14 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 7EF731065673 for ; Sun, 20 May 2012 17:30:14 +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 B82B88FC0C for ; Sun, 20 May 2012 17:30:13 +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 q4KHU2LI026300 for ; Sun, 20 May 2012 17:30:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q4KHU2x2026292; Sun, 20 May 2012 17:30:02 GMT (envelope-from gnats) Resent-Date: Sun, 20 May 2012 17:30:02 GMT Resent-Message-Id: <201205201730.q4KHU2x2026292@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 918E9106566C for ; Sun, 20 May 2012 17:21:29 +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 62DF18FC08 for ; Sun, 20 May 2012 17:21:29 +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 q4KHLSvm021478 for ; Sun, 20 May 2012 17:21:28 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id q4KHLSc6021477; Sun, 20 May 2012 17:21:28 GMT (envelope-from nobody) Message-Id: <201205201721.q4KHLSc6021477@red.freebsd.org> Date: Sun, 20 May 2012 17:21:28 GMT From: Adrian Chadd To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: misc/168170: [net80211] ieee80211_send_bar() doesn't complete correctly if there's a resource shortage 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: Sun, 20 May 2012 17:30:14 -0000 >Number: 168170 >Category: misc >Synopsis: [net80211] ieee80211_send_bar() doesn't complete correctly if there's a resource shortage >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: Sun May 20 17:30:02 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release: -HEAD >Organization: >Environment: FreeBSD freebsd-wifi-build 10.0-CURRENT FreeBSD 10.0-CURRENT #5 r235338:235659M: Wed Dec 31 16:00:00 PST 1969 adrian@dummy:/home/adrian/work/freebsd/svn/obj/mipseb/mips.mips/usr/home/adrian/work/freebsd/svn/src/sys/RSPRO mips >Description: I'm seeing scenarios where the TID pauses, tying up all ath_buf entries (and mbufs, further up in the network stack) until the STA is forcibly removed. Here's a snippet from the AP log: ath1: ath_tx_tid_drain: node 0xc1d8a000: bf=0xc1cd417c: addbaw=1, dobaw=1, seqno_assign=1, seqno_required=1, seqno=1560, retry=10 ath1: ath_tx_tid_drain: node 0xc1d8a000: bf=0xc1cd417c: tid txq_depth=78 hwq_depth=0, bar_wait=1 ath1: ath_tx_tid_drain: node 0xc1d8a000: bf=0xc1cd417c: tid 0: txq_depth=0, txq_aggr_depth=0, sched=0, paused=1, hwq_depth=0, incomp=0, baw_head=123, baw_tail=33 txa_start=1537, ni_txseqs=1575 After doing a whole lot of digging, I found this: * ieee80211_bar_send() is called from the wifi driver. If it fails there then the wifi driver will have to consider the BAR failed and continue. * if it succeeds, then the wifi driver should hold TXing any further frames until it completes. * If it does succeed, then bar_start_timer() is called. * If the TX completes succesfully, then everything is ok * But then, if it fails - either it's told that it fails or it times out, bar_timeout() is (eventually) called. The timer here has completed, so it won't be called again. * It then calls ieee80211_send_bar(), which should try sending again. * .. but if the call to ieee80211_send_bar() fails, the timer is never restarted - its only restarted _if_ ieee80211_send_bar() actually successfully completed. >How-To-Repeat: Fire up 802.11n on ath(4) in hostap mode; wait for TX failures to occur. >Fix: I'm not entirely sure. It may be good enough to just call bar_start_timer() from bar_timeout(), just to enforce that the timer needs to be kicked along whether or not ieee80211_send_bar() succeeded. The other problem is resource exhaustion. At this point, all ieee80211_send_bar() calls may fail because the driver is completely out of internal buffers (here ath_buf), or the network stack has exhausted all mbufs. So it likely requires a few fixes in a few places. >Release-Note: >Audit-Trail: >Unformatted: