Date: Fri, 16 Mar 2012 23:18:40 GMT From: Adrian Chadd <adrian@FreeBSD.org> To: freebsd-gnats-submit@FreeBSD.org Subject: kern/166190: [ath] TX hangs and frames stuck in TX queue Message-ID: <201203162318.q2GNIeh5087696@red.freebsd.org> Resent-Message-ID: <201203162320.q2GNK8GS097053@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 166190 >Category: kern >Synopsis: [ath] TX hangs and frames stuck in TX queue >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: Fri Mar 16 23:20:08 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release: 9.0-RELEASE with -HEAD net80211/ath >Organization: >Environment: >Description: I've noticed that some frames get "stuck" in the software TX queue and dont' get flushed until: * the seqno's wrap around so that frame again falls within the BAW, at which point they're TXed, or * a scan or reset is done, flushing the queue. Further debugging will be provided once the PR has been created. >How-To-Repeat: This seems to occur only when: * doing multiple TX threads of traffic; * seems to reliably trigger with multiple threads/processes doing TX - eg chrome reloading all of its threads after a crash; * on an SMP machine. A non-SMP machine doesn't seem to have this issue. I've not seen this in AP mode but then I've not really tested AP mode out on SMP hardware and with multiple interfaces (ie, multiple sources of traffic.) >Fix: >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201203162318.q2GNIeh5087696>