kern/165220: [ath] "ath_rx_tasklet: sc_inreset_cnt > 0; skipping" messages

[Adrian Chadd]

>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: