[ath9k-devel] DMA issues with ar9280 cards

[Bernhard Schmidt <bschmidt@techwires.net>]

On Friday 04 March 2011 16:29:13 Mohammed Shafi wrote:
> On Fri, Mar 4, 2011 at 8:55 PM, Mohammed Shafi <shafi.wireless@gmail.com> wrote:
> > On Fri, Mar 4, 2011 at 4:59 PM, Bernhard Schmidt <bschmidt@techwires.net> wrote:
> >> On Wednesday, March 02, 2011 15:51:37 Mohammed Shafi wrote:
> >>> On Thu, Feb 24, 2011 at 1:36 AM, Bernhard Schmidt
> >>> <bschmidt@techwires.net> wrote:
> >>> > On Wednesday 23 February 2011 18:46:49 Luis R. Rodriguez wrote:
> >>> >> On Wed, Feb 23, 2011 at 12:55:35AM -0800, Bernhard Schmidt wrote:
> >>> >> > % scan done, setting up the BSS
> >>> >> > [  296.060536] ath: Failed to stop TX DMA in 100 msec after killing last frame
> >>> >> > [  296.075985] ath: Failed to stop TX DMA in 100 msec after killing last frame
> >>> >> > [  296.083032] ath: Failed to stop TX DMA!
> >>> >> > [  296.099187] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> >>> >> > [  296.106884] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
> >>> >> > [  296.127247] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> >>> >> > [  297.163998] ath: Failed to stop TX DMA in 100 msec after killing last frame
> >>> >> > [  297.182977] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> >>> >> > [  297.190677] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
> >>> >> > [  297.211004] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> >>> >> > [  298.247659] ath: Failed to stop TX DMA in 100 msec after killing last frame
> >>> >> > % ..
> >>> >>
> >>> >> If its so easy to reproduce we can likely fix this for good!
> >>> >
> >>> > Actually, haven't found a way to *not* reproduce it. :)
> >>>
> >>> the obvious way of increasing the timeout for stopping the DMA might help ?
> >>> in mac.c
> >>>
> >>> 148 #define ATH9K_TX_STOP_DMA_TIMEOUT       4000    /* usec */
> >>> increase it to 10000 usec
> >>>
> >>> and
> >>> 781#define AH_RX_STOP_DMA_TIMEOUT 10000   /* usec */
> >>> increase it to 20,000 usec
> >>
> >> Did try to play with various values, no differences whatsoever,
> >> obviously. Even tried polling a whole second. The messages do indicate
> >> that there is an issue. It's not that the reg isn't polled for long
> >> enough, but instead this is an indicator for something wrong going on.
> >> What I'm wondering though is, that the queue resets which eventually
> >> happen do not have any effect, only after a "full" reset (e.g.
> >> ifconfig down/up) the queues will be usable again.
> >
> > Thanks for trying it out, I thought we have to give sufficient time so
> > that the bit goes low.
> >
> >>
> >> On a site note, after falling back to other chips (9380, 9160), I see
> >> the same issue there too. Not as often, or as immediate as with 9280,
> >> but they do occur (even on different hardware). Having a hostapd
> >> instance idle long enough is able to trigger it eventually.
> 
> Can you please give some information regarding this issue in station mode.
> In the station mode does scanning seems to easily trigger this issue?
> Or is there with something like running the traffic or plugging the card out?

After a fresh boot I can trigger it with just:
% modprobe ath9k
% ifconfig wlan0 up
% iw wlan0 scan
the only traffic involved are probe requests being sent and of course
all frames received during a scan. Most of the time it happens on the
first invocation of the scan command, sometimes I need to call it 2 or
3 times.

-- 
Bernhard