From owner-freebsd-bugs@FreeBSD.ORG Fri Mar 16 23:20:08 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 DF7031065678 for ; Fri, 16 Mar 2012 23:20:08 +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 A402C8FC1D for ; Fri, 16 Mar 2012 23:20:08 +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 q2GNK8ZE097054 for ; Fri, 16 Mar 2012 23:20:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2GNK8GS097053; Fri, 16 Mar 2012 23:20:08 GMT (envelope-from gnats) Resent-Date: Fri, 16 Mar 2012 23:20:08 GMT Resent-Message-Id: <201203162320.q2GNK8GS097053@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 E024C106564A for ; Fri, 16 Mar 2012 23:18:40 +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 D04518FC08 for ; Fri, 16 Mar 2012 23:18:40 +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 q2GNIedY087697 for ; Fri, 16 Mar 2012 23:18:40 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id q2GNIeh5087696; Fri, 16 Mar 2012 23:18:40 GMT (envelope-from nobody) Message-Id: <201203162318.q2GNIeh5087696@red.freebsd.org> Date: Fri, 16 Mar 2012 23:18:40 GMT From: Adrian Chadd To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: kern/166190: [ath] TX hangs and frames stuck in TX queue 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: Fri, 16 Mar 2012 23:20:09 -0000 >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: