From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bernhard Schmidt Date: Fri, 4 Mar 2011 18:16:10 +0100 Subject: [ath9k-devel] DMA issues with ar9280 cards In-Reply-To: References: <201102230955.35674.bschmidt@techwires.net> Message-ID: <201103041816.11100.bschmidt@techwires.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org On Friday 04 March 2011 16:29:13 Mohammed Shafi wrote: > On Fri, Mar 4, 2011 at 8:55 PM, Mohammed Shafi wrote: > > On Fri, Mar 4, 2011 at 4:59 PM, Bernhard Schmidt wrote: > >> On Wednesday, March 02, 2011 15:51:37 Mohammed Shafi wrote: > >>> On Thu, Feb 24, 2011 at 1:36 AM, Bernhard Schmidt > >>> 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