From owner-freebsd-bugs@FreeBSD.ORG Fri Feb 17 03:00:22 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 C489F1065677 for ; Fri, 17 Feb 2012 03:00:22 +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 DB1478FC16 for ; Fri, 17 Feb 2012 03:00:21 +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 q1H30Lov011870 for ; Fri, 17 Feb 2012 03:00:21 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1H30LqS011869; Fri, 17 Feb 2012 03:00:21 GMT (envelope-from gnats) Resent-Date: Fri, 17 Feb 2012 03:00:21 GMT Resent-Message-Id: <201202170300.q1H30LqS011869@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 63E4A106566B for ; Fri, 17 Feb 2012 02:50:11 +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 51C9D8FC14 for ; Fri, 17 Feb 2012 02:50:11 +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 q1H2oB6v022659 for ; Fri, 17 Feb 2012 02:50:11 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id q1H2oB7u022658; Fri, 17 Feb 2012 02:50:11 GMT (envelope-from nobody) Message-Id: <201202170250.q1H2oB7u022658@red.freebsd.org> Date: Fri, 17 Feb 2012 02:50:11 GMT From: Adrian Chadd To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: kern/165220: [ath] "ath_rx_tasklet: sc_inreset_cnt > 0; skipping" messages 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, 17 Feb 2012 03:00:22 -0000 >Number: 165220 >Category: kern >Synopsis: [ath] "ath_rx_tasklet: sc_inreset_cnt > 0; skipping" messages >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 Feb 17 03:00:21 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release: 9.0-RELEASE i386, with -HEAD net80211/ath >Organization: >Environment: >Description: There are far too many of the following messages showing up: [100191] ath0: ath_rx_tasklet: sc_inreset_cnt > 0; skipping [100191] ath0: ath_rx_tasklet: sc_inreset_cnt > 0; skipping [100191] ath0: ath_rx_tasklet: sc_inreset_cnt > 0; skipping [100191] ath0: ath_rx_tasklet: sc_inreset_cnt > 0; skipping [100191] ath0: ath_start: sc_inreset_cnt > 0; bailing [100191] ath0: ath_rx_tasklet: sc_inreset_cnt > 0; skipping [100191] ath0: ath_rx_tasklet: sc_inreset_cnt > 0; skipping [100191] ath0: ath_rx_tasklet: sc_inreset_cnt > 0; skipping . What's happening is that a bunch of TX or RX completion is occuring at the same time as a channel change/reset. The previous code just had these run concurrently, causing all kinds of random and weird behaviour. I introduced some debugging in FreeBSD-HEAD that tries to (a) stop these and (b) log when they occur, so I could actually try finding/figuring out what's going on. This is one of these cases. :-) >How-To-Repeat: Just run ath :-) >Fix: The problem is that although interrupts are disabled in reset, the ath taskqueue may currently be running and this means existing TX completion and RX will occur. I think the fix is to do this: * grab the PCU lock * disable interrupts * grab the reset counter * stop the ath taskqueue and wait for pending tasks to complete . but is this still racy? A patch I've done to do the above in ath_reset() and ath_chan_change() reduces the instances of this quite heavily but it still occasionally turns up. >Release-Note: >Audit-Trail: >Unformatted: