From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bernhard Schmidt Date: Wed, 23 Feb 2011 21:06:30 +0100 Subject: [ath9k-devel] DMA issues with ar9280 cards In-Reply-To: <20110223174649.GD19293@tux> References: <201102230955.35674.bschmidt@techwires.net> <20110223174649.GD19293@tux> Message-ID: <201102232106.31236.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 Wednesday 23 February 2011 18:46:49 Luis R. Rodriguez wrote: > On Wed, Feb 23, 2011 at 12:55:35AM -0800, Bernhard Schmidt wrote: > > Hi, > > > > I have some issues using any of my AR9280 cards, identified as: > > - Ubiquiti SR71E > > [ 172.321483] ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf9760000, irq=11 > > - Sparklan WPEA-110N > > [ 58.456404] ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf8760000, irq=11 > > > > On a recent wireless-testing kernel: > > # uname -a > > % Linux meshnode 2.6.38-rc6-wl-12466-g09f3227 #23 SMP Wed Feb 23 08:48:45 CET 2011 i686 GNU/Linux > > > > I see this behaviour: > > # hostapd /etc/hostapd.conf > > % scan due to ht40 > > [ 289.389379] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 > > [ 289.397106] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up > > [ 289.548409] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 > > [ 289.700270] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 > > [ 289.707992] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up > > [ 289.728509] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 > > [ 289.880228] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 > > [ 289.887952] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up > > [ 289.908455] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 > > [ 290.060168] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 > > [ 290.067926] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up > > .. > > This should not be fatal but we do want to fix it, it was just hard to reproduce. > Can you paste your hostapd.conf ? Will do that tomorrow when back at the office. Note, the error might not be fatal, but, due it taking 100ms (see below), which is exactly the beacon interval, no frames are sent. It is also not related to AP mode, I see the exact same behavior in station mode. If I manage to get through the association phase, it quickly goes deaf after the first few packets. > > % 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. :) > Do you see the same issue if you just have one card plugged in or > is this happening on two separate boxes? It's one card at a time on this box. The monitor device is running on another box. It is the only miniPCIe capable box I have around here atm. While playing around a bit with various debug options, I've noticed that the amount of debug messages has an influence on when the issue does occur. As in the more debug message, the sooner it will go deaf. Smells racy somehow. Will post a slightly more verbose log tomorrow. -- Bernhard