* [ath9k-devel] DMA issues with ar9280 cards [not found] <201102230955.35674.bschmidt@techwires.net> @ 2011-02-23 17:46 ` Luis R. Rodriguez 2011-02-23 18:12 ` Adrian Chadd 2011-02-23 20:06 ` Bernhard Schmidt 0 siblings, 2 replies; 26+ messages in thread From: Luis R. Rodriguez @ 2011-02-23 17:46 UTC (permalink / raw) To: ath9k-devel 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 ? > % 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! Do you see the same issue if you just have one card plugged in or is this happening on two separate boxes? Luis ^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards 2011-02-23 17:46 ` [ath9k-devel] DMA issues with ar9280 cards Luis R. Rodriguez @ 2011-02-23 18:12 ` Adrian Chadd 2011-02-23 18:20 ` Adrian Chadd 2011-02-23 20:06 ` Bernhard Schmidt 1 sibling, 1 reply; 26+ messages in thread From: Adrian Chadd @ 2011-02-23 18:12 UTC (permalink / raw) To: ath9k-devel I can reproduce this with my FreeBSD STA talking to an AR9132-based AP running a recent (~ 2 weeks old) openwrt. There seems to be certain situations where the MAC gets completely confused and does crazy stuff like continuously retransmit a frame+ACK. It ends up as a BB hang on the STA side, and these messages on the AP side. I can't provide more info; I'll try to re-re-reproduce it when I'm back home in a couple weeks. Adrian On 23 February 2011 12:46, Luis R. Rodriguez <lrodriguez@atheros.com> 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 ? > > > % 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! > > Do you see the same issue if you just have one card plugged in or > is this happening on two separate boxes? > > Luis > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110223/77ec9d6b/attachment.htm ^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards 2011-02-23 18:12 ` Adrian Chadd @ 2011-02-23 18:20 ` Adrian Chadd 2011-02-23 18:24 ` Jouni Malinen 0 siblings, 1 reply; 26+ messages in thread From: Adrian Chadd @ 2011-02-23 18:20 UTC (permalink / raw) To: ath9k-devel in fact, I lie - it's ath9k seemingly sending two ACKs for the same frame. Why would the hardware do that? Adrian On 23 February 2011 13:12, Adrian Chadd <adrian@freebsd.org> wrote: > I can reproduce this with my FreeBSD STA talking to an AR9132-based AP > running a recent (~ 2 weeks old) openwrt. > > There seems to be certain situations where the MAC gets completely confused > and does crazy stuff like continuously retransmit a frame+ACK. It ends up as > a BB hang on the STA side, and these messages on the AP side. > > I can't provide more info; I'll try to re-re-reproduce it when I'm back > home in a couple weeks. > > > Adrian > > On 23 February 2011 12:46, Luis R. Rodriguez <lrodriguez@atheros.com>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 ? >> >> > % 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! >> >> Do you see the same issue if you just have one card plugged in or >> is this happening on two separate boxes? >> >> Luis >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110223/b7fd1975/attachment.htm ^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards 2011-02-23 18:20 ` Adrian Chadd @ 2011-02-23 18:24 ` Jouni Malinen 2011-02-23 18:40 ` Adrian Chadd 0 siblings, 1 reply; 26+ messages in thread From: Jouni Malinen @ 2011-02-23 18:24 UTC (permalink / raw) To: ath9k-devel On Wed, 2011-02-23 at 10:20 -0800, Adrian Chadd wrote: > in fact, I lie - it's ath9k seemingly sending two ACKs for the same > frame. I don't remember having seen that and cannot really think of any reason that would cause this type of behavior. Would you happen to have a wireless capture file showing this? - Jouni ^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards 2011-02-23 18:24 ` Jouni Malinen @ 2011-02-23 18:40 ` Adrian Chadd 2011-02-23 23:06 ` Jouni Malinen 0 siblings, 1 reply; 26+ messages in thread From: Adrian Chadd @ 2011-02-23 18:40 UTC (permalink / raw) To: ath9k-devel Absolutely! I'll dig out some examples and fire them off. The trouble is, I don't know if this macbook pro NIC (some broadcom 11n thing) is handing over garbage frames or not. I know it sometimes shows frames from ath9k with incorrect FCS, but that could be in-air garbage. So it's entirely possible there -was- a frame in there, but it was garbled to the point where the NIC couldn't decode it. I've also got a wireless capture file showing this exchange (which feels a lot more "validly" broken) : Ath9k -> STA : QoS Data (non-aggregate) STA->AP : ACK Ath9k -> STA : same frame STA->AP : ACK .. .. .. Ath9k -> STA: QoS data (same frame, again) STA-> AP : ACK You can find that at http://people.freebsd.org/~adrian/pcap4-sn-512-retrans.pcap I also see the FreeBSD STA (AR9280) send multiple CTS-to-self before not sending an actual data frame. Is there any way to stick an ath9k hostap interface in actual monitor mode, and get =all= the frames to show up on mon.wlan0 ? (So I can compare what ath9k thinks its sending/receiving, to what FreeBSD STA thinks its sending/receiving, to what's going on in the air) ? Or should I just hack the code to enable all the RX filter bits? Adrian On 23 February 2011 13:24, Jouni Malinen <jouni.malinen@atheros.com> wrote: > On Wed, 2011-02-23 at 10:20 -0800, Adrian Chadd wrote: > > in fact, I lie - it's ath9k seemingly sending two ACKs for the same > > frame. > > I don't remember having seen that and cannot really think of any reason > that would cause this type of behavior. Would you happen to have a > wireless capture file showing this? > > - Jouni > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110223/305204d4/attachment-0001.htm ^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards 2011-02-23 18:40 ` Adrian Chadd @ 2011-02-23 23:06 ` Jouni Malinen 0 siblings, 0 replies; 26+ messages in thread From: Jouni Malinen @ 2011-02-23 23:06 UTC (permalink / raw) To: ath9k-devel On Wed, 2011-02-23 at 10:40 -0800, Adrian Chadd wrote: > The trouble is, I don't know if this macbook pro NIC (some broadcom > 11n thing) is handing over garbage frames or not. I know it sometimes > shows frames from ath9k with incorrect FCS, but that could be in-air > garbage. So it's entirely possible there -was- a frame in there, but > it was garbled to the point where the NIC couldn't decode it. Yeah.. That was kind of the reason I wanted to see a capture trace, so that I could look at the timing of the frames. > I've also got a wireless capture file showing this exchange (which > feels a lot more "validly" broken) : > > > Ath9k -> STA : QoS Data (non-aggregate) > STA->AP : ACK > Ath9k -> STA : same frame > STA->AP : ACK > .. > .. > .. > Ath9k -> STA: QoS data (same frame, again) > STA-> AP : ACK > You can find that at > http://people.freebsd.org/~adrian/pcap4-sn-512-retrans.pcap Which device is the ath9k device? The one with MAC address ending a2:2a? There were some innovative uses of sequence number 512 in some frames, but the payload was actually different even if the seq# did not change. I don't think that those frames would be duplicated by ath9k (they could be duplicated by mac80211). Which kernel/driver/mac80211 was used here? > I also see the FreeBSD STA (AR9280) send multiple CTS-to-self before > not sending an actual data frame. Are you sure the TX descriptor for the frame that triggered this is set correctly? > Is there any way to stick an ath9k hostap interface in actual monitor > mode, and get =all= the frames to show up on mon.wlan0 ? (So I can > compare what ath9k thinks its sending/receiving, to what FreeBSD STA > thinks its sending/receiving, to what's going on in the air) ? Or > should I just hack the code to enable all the RX filter bits? I don't think you would want all the frames on mon.wlan0, but adding another monitor interface without using cooked mode could do more or less this. Not that all frames would be seen since TX frames generated in hardware (like ack) would not be indicated. - Jouni ^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards 2011-02-23 17:46 ` [ath9k-devel] DMA issues with ar9280 cards Luis R. Rodriguez 2011-02-23 18:12 ` Adrian Chadd @ 2011-02-23 20:06 ` Bernhard Schmidt 2011-02-24 9:33 ` Bernhard Schmidt 2011-03-02 14:51 ` Mohammed Shafi 1 sibling, 2 replies; 26+ messages in thread From: Bernhard Schmidt @ 2011-02-23 20:06 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards 2011-02-23 20:06 ` Bernhard Schmidt @ 2011-02-24 9:33 ` Bernhard Schmidt 2011-02-24 18:18 ` Luis R. Rodriguez 2011-03-02 14:51 ` Mohammed Shafi 1 sibling, 1 reply; 26+ messages in thread From: Bernhard Schmidt @ 2011-02-24 9:33 UTC (permalink / raw) To: ath9k-devel On Wednesday, February 23, 2011 21:06:30 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: > > > 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. I've stripped everything not necessary, this one is use for the log below. # cat /etc/hostapd.conf interface=wlan0 driver=nl80211 ssid=testtest hw_mode=a channel=44 > > > % 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. # hostapd /etc/hostapd.conf Configuration file: /etc/hostapd.conf [ 568.080816] device: 'mon.wlan0': device_add [ 568.086085] PM: Adding info for No Bus:mon.wlan0 [ 568.111733] ath: Reset TX queue: 0 [ 568.115192] ath: Reset TX queue: 1 [ 568.118645] ath: Reset TX queue: 2 [ 568.122092] ath: Reset TX queue: 3 [ 568.125540] ath: Reset TXQ, inactive queue: 4 [ 568.129941] ath: Reset TXQ, inactive queue: 5 [ 568.134336] ath: Reset TXQ, inactive queue: 6 [ 568.138738] ath: Reset TXQ, inactive queue: 7 [ 568.143140] ath: Reset TX queue: 8 [ 568.146590] ath: Reset TX queue: 9 [ 568.159349] ath: Reset TX queue: 0 [ 568.162805] ath: Reset TX queue: 1 [ 568.166287] ath: Reset TX queue: 2 [ 568.169730] ath: Reset TX queue: 3 [ 568.173178] ath: Reset TXQ, inactive queue: 4 [ 568.177581] ath: Reset TXQ, inactive queue: 5 [ 568.181982] ath: Reset TXQ, inactive queue: 6 [ 568.186375] ath: Reset TXQ, inactive queue: 7 [ 568.190769] ath: Reset TX queue: 8 [ 568.194249] ath: Reset TX queue: 9 [ 568.206830] ath: Reset TX queue: 0 [ 568.210288] ath: Reset TX queue: 1 [ 568.213738] ath: Reset TX queue: 2 [ 568.217186] ath: Reset TX queue: 3 [ 568.220626] ath: Reset TXQ, inactive queue: 4 [ 568.225027] ath: Reset TXQ, inactive queue: 5 [ 568.229421] ath: Reset TXQ, inactive queue: 6 [ 568.233814] ath: Reset TXQ, inactive queue: 7 [ 568.238239] ath: Reset TX queue: 8 [ 568.241691] ath: Reset TX queue: 9 [ 568.248196] ath: Set queue properties for: 0 [ 568.252538] ath: Reset TX queue: 0 [ 568.256004] ath: Set queue properties for: 1 [ 568.260329] ath: Reset TX queue: 1 [ 568.263806] ath: Set queue properties for: 2 [ 568.268131] ath: Reset TX queue: 2 [ 568.271594] ath: Set queue properties for: 3 [ 568.275919] ath: Reset TX queue: 3 [ 568.395590] ath: Reset TX queue: 0 [ 568.399075] ath: Reset TX queue: 1 [ 568.402527] ath: Reset TX queue: 2 [ 568.405980] ath: Reset TX queue: 3 [ 568.409429] ath: Reset TXQ, inactive queue: 4 [ 568.413828] ath: Reset TXQ, inactive queue: 5 [ 568.418229] ath: Reset TXQ, inactive queue: 6 [ 568.422621] ath: Reset TXQ, inactive queue: 7 [ 568.427016] ath: Reset TX queue: 8 [ 568.430465] ath: Reset TX queue: 9 [ 568.439461] ath: qnum: 0, txq depth: 0 [ 568.443276] ath: Enable TXE on queue: 0 [ 568.447335] ath: tx queue 0 (2f4c0000), link ef4c0000 [ 568.452851] ath: tx queue 0 (2f4c0000), link ef4c0000 Using interface wlan0 with hwadd[ 568.462337] ath: Set queue properties for: 9 r 00:0e:8e:30:8f[ 568.467299] ath: Reset TX queue: 9 :e2 and ssid 'testtest' [ 568.564542] ath: Enable TXE on queue: 9 [ 568.666920] ath: Enable TXE on queue: 9 [ 568.769318] ath: Enable TXE on queue: 9 [ 568.871718] ath: Enable TXE on queue: 9 [ 568.974158] ath: Enable TXE on queue: 9 [ 569.076514] ath: Enable TXE on queue: 9 [ 569.178910] ath: Enable TXE on queue: 9 [ 569.281309] ath: Enable TXE on queue: 9 [ 569.383702] ath: Enable TXE on queue: 9 [ 569.486145] ath: Enable TXE on queue: 9 [ 569.588492] ath: Enable TXE on queue: 9 [ 569.690887] ath: Enable TXE on queue: 9 [ 569.793287] ath: Enable TXE on queue: 9 [ 569.895680] ath: Enable TXE on queue: 9 [ 569.998122] ath: Enable TXE on queue: 9 [ 570.100481] ath: Enable TXE on queue: 9 [ 570.202873] ath: Enable TXE on queue: 9 [ 570.305273] ath: Enable TXE on queue: 9 [ 570.407668] ath: Enable TXE on queue: 9 [ 570.510097] ath: Enable TXE on queue: 9 [ 570.612470] ath: Enable TXE on queue: 9 [ 570.714910] ath: Enable TXE on queue: 9 [ 570.817262] ath: Enable TXE on queue: 9 [ 570.919655] ath: Enable TXE on queue: 9 [ 571.022052] ath: Enable TXE on queue: 9 [ 571.124456] ath: Enable TXE on queue: 9 [ 571.226883] ath: Enable TXE on queue: 9 [ 571.329246] ath: Enable TXE on queue: 9 [ 571.431649] ath: Enable TXE on queue: 9 [ 571.534047] ath: Enable TXE on queue: 9 [ 571.636442] ath: Enable TXE on queue: 9 [ 571.738853] ath: Enable TXE on queue: 9 [ 571.841237] ath: Enable TXE on queue: 9 [ 571.943629] ath: Enable TXE on queue: 9 [ 572.046024] ath: Enable TXE on queue: 9 [ 572.148419] ath: Enable TXE on queue: 9 [ 572.250824] ath: Enable TXE on queue: 9 [ 572.353220] ath: Enable TXE on queue: 9 [ 572.455655] ath: Enable TXE on queue: 9 [ 572.558012] ath: Enable TXE on queue: 9 [ 572.660416] ath: Enable TXE on queue: 9 [ 572.762815] ath: Enable TXE on queue: 9 [ 572.865201] ath: Enable TXE on queue: 9 [ 572.967641] ath: Enable TXE on queue: 9 [ 573.069994] ath: Enable TXE on queue: 9 [ 573.172397] ath: Enable TXE on queue: 9 [ 573.274792] ath: Enable TXE on queue: 9 [ 573.377193] ath: Enable TXE on queue: 9 [ 573.479588] ath: Enable TXE on queue: 9 [ 573.581980] ath: Enable TXE on queue: 9 [ 573.684433] ath: Enable TXE on queue: 9 [ 573.786786] ath: Enable TXE on queue: 9 [ 573.889176] ath: Enable TXE on queue: 9 [ 573.991567] ath: Enable TXE on queue: 9 [ 574.093968] ath: Enable TXE on queue: 9 [ 574.196417] ath: Enable TXE on queue: 9 [ 574.298764] ath: Enable TXE on queue: 9 [ 574.401156] ath: Enable TXE on queue: 9 [ 574.503557] ath: Enable TXE on queue: 9 [ 574.605956] ath: Enable TXE on queue: 9 [ 574.708386] ath: Enable TXE on queue: 9 [ 574.810752] ath: Enable TXE on queue: 9 [ 574.913151] ath: Enable TXE on queue: 9 [ 575.015541] ath: Enable TXE on queue: 9 [ 575.117938] ath: Enable TXE on queue: 9 [ 575.220335] ath: Enable TXE on queue: 9 [ 575.322732] ath: Enable TXE on queue: 9 [ 576.248395] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 [ 576.259188] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 576.270827] ath: Reset TX queue: 0 [ 576.274288] ath: Reset TX queue: 1 [ 576.277732] ath: Reset TX queue: 2 [ 576.281179] ath: Reset TX queue: 3 [ 576.284620] ath: Reset TXQ, inactive queue: 4 [ 576.289042] ath: Reset TXQ, inactive queue: 5 [ 576.293439] ath: Reset TXQ, inactive queue: 6 [ 576.297833] ath: Reset TXQ, inactive queue: 7 [ 576.302227] ath: Reset TX queue: 8 [ 576.305676] ath: Reset TX queue: 9 [ 576.311886] ath: Set queue properties for: 9 [ 576.316216] ath: Reset TX queue: 9 [ 576.412070] ath: Enable TXE on queue: 9 [ 576.514417] ath: Enable TXE on queue: 9 [ 576.616820] ath: Enable TXE on queue: 9 [ 576.719211] ath: Enable TXE on queue: 9 [ 576.821613] ath: Enable TXE on queue: 9 [ 576.924041] ath: Enable TXE on queue: 9 [ 577.026404] ath: Enable TXE on queue: 9 [ 577.128809] ath: Enable TXE on queue: 9 [ 577.231203] ath: Enable TXE on queue: 9 [ 577.333589] ath: Enable TXE on queue: 9 [ 577.435986] ath: Enable TXE on queue: 9 [ 577.538387] ath: Enable TXE on queue: 9 [ 577.640834] ath: Enable TXE on queue: 9 [ 577.743186] ath: Enable TXE on queue: 9 [ 577.845593] ath: Enable TXE on queue: 9 [ 577.947986] ath: Enable TXE on queue: 9 [ 578.050372] ath: Enable TXE on queue: 9 [ 578.152823] ath: Enable TXE on queue: 9 [ 578.255175] ath: Enable TXE on queue: 9 [ 578.357573] ath: Enable TXE on queue: 9 [ 578.459970] ath: Enable TXE on queue: 9 [ 578.562363] ath: Enable TXE on queue: 9 [ 578.664793] ath: Enable TXE on queue: 9 [ 578.767159] ath: Enable TXE on queue: 9 [ 578.869553] ath: Enable TXE on queue: 9 [ 578.971949] ath: Enable TXE on queue: 9 [ 579.074347] ath: Enable TXE on queue: 9 [ 579.176751] ath: Enable TXE on queue: 9 [ 579.279147] ath: Enable TXE on queue: 9 [ 579.381592] ath: Enable TXE on queue: 9 [ 579.483945] ath: Enable TXE on queue: 9 [ 579.586339] ath: Enable TXE on queue: 9 [ 579.688730] ath: Enable TXE on queue: 9 [ 579.791131] ath: Enable TXE on queue: 9 [ 579.893564] ath: Enable TXE on queue: 9 [ 579.995919] ath: Enable TXE on queue: 9 [ 580.098316] ath: Enable TXE on queue: 9 [ 580.200722] ath: Enable TXE on queue: 9 [ 580.303114] ath: Enable TXE on queue: 9 [ 580.405526] ath: Enable TXE on queue: 9 [ 580.507907] ath: Enable TXE on queue: 9 [ 580.610308] ath: Enable TXE on queue: 9 [ 580.712702] ath: Enable TXE on queue: 9 [ 580.815106] ath: Enable TXE on queue: 9 [ 580.917496] ath: Enable TXE on queue: 9 [ 581.019892] ath: Enable TXE on queue: 9 [ 581.122337] ath: Enable TXE on queue: 9 [ 581.224692] ath: Enable TXE on queue: 9 [ 581.327082] ath: Enable TXE on queue: 9 [ 581.429485] ath: Enable TXE on queue: 9 [ 581.531882] ath: Enable TXE on queue: 9 [ 581.634308] ath: Enable TXE on queue: 9 [ 581.736672] ath: Enable TXE on queue: 9 [ 581.839070] ath: Enable TXE on queue: 9 [ 581.941469] ath: Enable TXE on queue: 9 [ 582.043873] ath: Enable TXE on queue: 9 [ 582.146288] ath: Enable TXE on queue: 9 [ 582.248664] ath: Enable TXE on queue: 9 [ 582.351054] ath: Enable TXE on queue: 9 [ 582.453454] ath: Enable TXE on queue: 9 [ 582.555857] ath: Enable TXE on queue: 9 [ 582.658256] ath: Enable TXE on queue: 9 [ 582.760643] ath: Enable TXE on queue: 9 [ 582.863090] ath: Enable TXE on queue: 9 [ 582.965450] ath: Enable TXE on queue: 9 [ 583.067847] ath: Enable TXE on queue: 9 [ 583.170237] ath: Enable TXE on queue: 9 [ 583.272634] ath: Enable TXE on queue: 9 [ 583.375065] ath: Enable TXE on queue: 9 [ 583.477429] ath: Enable TXE on queue: 9 [ 583.579826] ath: Enable TXE on queue: 9 [ 583.682228] ath: Enable TXE on queue: 9 [ 583.784627] ath: Enable TXE on queue: 9 [ 583.887024] ath: Enable TXE on queue: 9 [ 583.989414] ath: Enable TXE on queue: 9 [ 584.091867] ath: Enable TXE on queue: 9 [ 584.194207] ath: Enable TXE on queue: 9 [ 584.296603] ath: Enable TXE on queue: 9 [ 584.399002] ath: Enable TXE on queue: 9 [ 584.501401] ath: Enable TXE on queue: 9 [ 584.603841] ath: Enable TXE on queue: 9 [ 584.706197] ath: Enable TXE on queue: 9 [ 584.808599] ath: Enable TXE on queue: 9 [ 584.910990] ath: Enable TXE on queue: 9 [ 585.013390] ath: Enable TXE on queue: 9 [ 585.115810] ath: Enable TXE on queue: 9 [ 585.218186] ath: Enable TXE on queue: 9 [ 585.320578] ath: Enable TXE on queue: 9 [ 585.422982] ath: Enable TXE on queue: 9 [ 585.525379] ath: Enable TXE on queue: 9 [ 585.627771] ath: Enable TXE on queue: 9 [ 585.730166] ath: Enable TXE on queue: 9 [ 585.832622] ath: Enable TXE on queue: 9 [ 585.934957] ath: Enable TXE on queue: 9 [ 586.037370] ath: Enable TXE on queue: 9 [ 586.139772] ath: Enable TXE on queue: 9 [ 586.242158] ath: Enable TXE on queue: 9 [ 586.344587] ath: Enable TXE on queue: 9 [ 586.446947] ath: Enable TXE on queue: 9 [ 586.549348] ath: Enable TXE on queue: 9 [ 586.651748] ath: Enable TXE on queue: 9 [ 586.754137] ath: Enable TXE on queue: 9 [ 586.856552] ath: Enable TXE on queue: 9 [ 586.958936] ath: Enable TXE on queue: 9 [ 587.061339] ath: Enable TXE on queue: 9 [ 587.163731] ath: Enable TXE on queue: 9 [ 587.266125] ath: Enable TXE on queue: 9 [ 587.368522] ath: Enable TXE on queue: 9 [ 587.470922] ath: Enable TXE on queue: 9 [ 587.573366] ath: Enable TXE on queue: 9 [ 587.675716] ath: Enable TXE on queue: 9 [ 587.778118] ath: Enable TXE on queue: 9 [ 587.880508] ath: Enable TXE on queue: 9 [ 587.982912] ath: Enable TXE on queue: 9 [ 588.085345] ath: Enable TXE on queue: 9 [ 588.187705] ath: Enable TXE on queue: 9 [ 588.290108] ath: Enable TXE on queue: 9 [ 588.392494] ath: Enable TXE on queue: 9 [ 588.494893] ath: Enable TXE on queue: 9 [ 588.597289] ath: Enable TXE on queue: 9 [ 588.699696] ath: Enable TXE on queue: 9 [ 588.802134] ath: Enable TXE on queue: 9 [ 588.904478] ath: Enable TXE on queue: 9 [ 589.006885] ath: Enable TXE on queue: 9 [ 589.109276] ath: Enable TXE on queue: 9 [ 589.211674] ath: Enable TXE on queue: 9 [ 589.314120] ath: Enable TXE on queue: 9 [ 589.416464] ath: Enable TXE on queue: 9 [ 589.518861] ath: Enable TXE on queue: 9 [ 589.621271] ath: Enable TXE on queue: 9 [ 589.723665] ath: Enable TXE on queue: 9 [ 589.826095] ath: Enable TXE on queue: 9 [ 589.928452] ath: Enable TXE on queue: 9 [ 590.030855] ath: Enable TXE on queue: 9 [ 590.133255] ath: Enable TXE on queue: 9 [ 590.235646] ath: Enable TXE on queue: 9 [ 590.338045] ath: Enable TXE on queue: 9 [ 590.440437] ath: Enable TXE on queue: 9 [ 590.542882] ath: Enable TXE on queue: 9 [ 590.645237] ath: Enable TXE on queue: 9 [ 590.747627] ath: Enable TXE on queue: 9 [ 590.850028] ath: Enable TXE on queue: 9 [ 590.952428] ath: Enable TXE on queue: 9 [ 591.054865] ath: Enable TXE on queue: 9 [ 591.157228] ath: Enable TXE on queue: 9 [ 591.259622] ath: Enable TXE on queue: 9 [ 591.362016] ath: Enable TXE on queue: 9 [ 591.464416] ath: Enable TXE on queue: 9 [ 591.566828] ath: Enable TXE on queue: 9 [ 591.669215] ath: Enable TXE on queue: 9 [ 591.771604] ath: Enable TXE on queue: 9 [ 591.874003] ath: Enable TXE on queue: 9 [ 591.976405] ath: Enable TXE on queue: 9 [ 592.078806] ath: Enable TXE on queue: 9 [ 592.181201] ath: Enable TXE on queue: 9 [ 592.283649] ath: Enable TXE on queue: 9 [ 592.385993] ath: Enable TXE on queue: 9 [ 592.488387] ath: Enable TXE on queue: 9 [ 592.590786] ath: Enable TXE on queue: 9 [ 592.693186] ath: Enable TXE on queue: 9 [ 592.795611] ath: Enable TXE on queue: 9 [ 592.897975] ath: Enable TXE on queue: 9 [ 593.000381] ath: Enable TXE on queue: 9 [ 593.102772] ath: Enable TXE on queue: 9 [ 593.205170] ath: Enable TXE on queue: 9 [ 593.307568] ath: Enable TXE on queue: 9 [ 593.409963] ath: Enable TXE on queue: 9 [ 593.512358] ath: Enable TXE on queue: 9 [ 593.614759] ath: Enable TXE on queue: 9 [ 593.717149] ath: Enable TXE on queue: 9 [ 593.819548] ath: Enable TXE on queue: 9 [ 593.921958] ath: Enable TXE on queue: 9 [ 594.024388] ath: Enable TXE on queue: 9 [ 594.126741] ath: Enable TXE on queue: 9 [ 594.229140] ath: Enable TXE on queue: 9 [ 594.331537] ath: Enable TXE on queue: 9 [ 594.433940] ath: Enable TXE on queue: 9 [ 594.536366] ath: Enable TXE on queue: 9 [ 594.638731] ath: Enable TXE on queue: 9 [ 594.741125] ath: Enable TXE on queue: 9 [ 594.843521] ath: Enable TXE on queue: 9 [ 594.945917] ath: Enable TXE on queue: 9 [ 595.048340] ath: Enable TXE on queue: 9 [ 595.150714] ath: Enable TXE on queue: 9 [ 595.253167] ath: Enable TXE on queue: 9 [ 595.355505] ath: Enable TXE on queue: 9 [ 595.457913] ath: Enable TXE on queue: 9 [ 595.560303] ath: Enable TXE on queue: 9 [ 595.662703] ath: Enable TXE on queue: 9 [ 595.765141] ath: Enable TXE on queue: 9 [ 595.867498] ath: Enable TXE on queue: 9 [ 595.969895] ath: Enable TXE on queue: 9 [ 596.072298] ath: Enable TXE on queue: 9 [ 596.174687] ath: Enable TXE on queue: 9 [ 596.277116] ath: Enable TXE on queue: 9 [ 596.379487] ath: Enable TXE on queue: 9 [ 596.481881] ath: Enable TXE on queue: 9 [ 596.584280] ath: Enable TXE on queue: 9 [ 596.686673] ath: Enable TXE on queue: 9 [ 596.789068] ath: Enable TXE on queue: 9 [ 596.891468] ath: Enable TXE on queue: 9 [ 596.993912] ath: Enable TXE on queue: 9 [ 597.096263] ath: Enable TXE on queue: 9 [ 597.198659] ath: Enable TXE on queue: 9 [ 597.301055] ath: Enable TXE on queue: 9 [ 597.403450] ath: Enable TXE on queue: 9 [ 597.505888] ath: Enable TXE on queue: 9 [ 597.608248] ath: Enable TXE on queue: 9 [ 597.710655] ath: Enable TXE on queue: 9 [ 597.813050] ath: Enable TXE on queue: 9 [ 597.915446] ath: Enable TXE on queue: 9 [ 598.017881] ath: Enable TXE on queue: 9 [ 598.120235] ath: Enable TXE on queue: 9 [ 598.222630] ath: Enable TXE on queue: 9 [ 599.148292] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 [ 599.159148] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 599.170789] ath: Reset TX queue: 0 [ 599.174242] ath: Reset TX queue: 1 [ 599.177684] ath: Reset TX queue: 2 [ 599.181127] ath: Reset TX queue: 3 [ 599.184575] ath: Reset TXQ, inactive queue: 4 [ 599.188976] ath: Reset TXQ, inactive queue: 5 [ 599.193368] ath: Reset TXQ, inactive queue: 6 [ 599.197762] ath: Reset TXQ, inactive queue: 7 [ 599.202157] ath: Reset TX queue: 8 [ 599.205605] ath: Reset TX queue: 9 [ 599.211798] ath: Set queue properties for: 9 [ 599.216128] ath: Reset TX queue: 9 [ 599.311924] ath: Enable TXE on queue: 9 [ 600.237580] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 [ 600.248425] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 600.267322] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 600.275012] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 600.283526] ------------[ cut here ]------------ [ 600.288203] WARNING: at drivers/net/wireless/ath/ath9k/recv.c:509 ath_stoprecv+0xb7/0xc9 [ath9k]() [ 600.297198] Hardware name: To be filled by O.E.M. [ 600.301934] Modules linked in: ath9k mac80211 ath9k_common ath9k_hw ath cfg80211 [last unloaded: cfg80211] [ 600.311932] Pid: 0, comm: swapper Tainted: G W 2.6.38-rc6-wl-12525-g2f478dd #24 [ 600.320045] Call Trace: [ 600.322549] [<c01288c2>] ? warn_slowpath_common+0x6a/0x7f [ 600.328082] [<fa74bbcb>] ? ath_stoprecv+0xb7/0xc9 [ath9k] [ 600.333614] [<c01288eb>] ? warn_slowpath_null+0x14/0x18 [ 600.338974] [<fa74bbcb>] ? ath_stoprecv+0xb7/0xc9 [ath9k] [ 600.344512] [<fa748d37>] ? ath_reset+0x6b/0x185 [ath9k] [ 600.349876] [<fa746aa9>] ? ath9k_ioread32+0x56/0x60 [ath9k] [ 600.355587] [<fa745186>] ? ath_beacon_tasklet+0xad/0x63c [ath9k] [ 600.361733] [<c014564e>] ? local_clock+0x2d/0x4e [ 600.366492] [<c014dbc8>] ? lock_release_holdtime+0x1a/0x10e [ 600.372198] [<c037a05d>] ? _raw_spin_unlock_irq+0x27/0x2b [ 600.377724] [<c037a31c>] ? restore_all_notrace+0x0/0x18 [ 600.383081] [<c0233190>] ? trace_hardirqs_on_thunk+0xc/0x10 [ 600.388786] [<c012d825>] ? tasklet_action+0x3a/0xd9 [ 600.393793] [<c012d858>] ? tasklet_action+0x6d/0xd9 [ 600.398803] [<c012df14>] ? __do_softirq+0xb1/0x16a [ 600.403724] [<c012de63>] ? __do_softirq+0x0/0x16a [ 600.408551] <IRQ> [<c012d62a>] ? irq_exit+0x3a/0x3c [ 600.413713] [<c0103dc2>] ? do_IRQ+0x81/0x95 [ 600.418028] [<c0102d6e>] ? common_interrupt+0x2e/0x34 [ 600.423215] [<c037a09e>] ? _raw_spin_unlock_irqrestore+0x3d/0x41 [ 600.429350] [<c014b0b3>] ? clockevents_notify+0xcd/0xd4 [ 600.434708] [<c0279f27>] ? lapic_timer_state_broadcast+0x36/0x39 [ 600.440840] [<c027a4d8>] ? acpi_idle_enter_bm+0x267/0x27f [ 600.446377] [<c02ef3cf>] ? cpuidle_idle_call+0xee/0x183 [ 600.451734] [<c0101aec>] ? cpu_idle+0x44/0x5c [ 600.456228] [<c0368d5e>] ? rest_init+0x92/0x97 [ 600.460806] [<c04f4884>] ? start_kernel+0x2d7/0x2dc [ 600.465821] [<c04f40d2>] ? i386_start_kernel+0xd2/0xd9 [ 600.471084] ---[ end trace 90d0638f5273e6d8 ]--- [ 600.487573] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 600.499749] ath: Reset TX queue: 0 [ 600.503206] ath: Reset TX queue: 1 [ 600.506649] ath: Reset TX queue: 2 [ 600.510089] ath: Reset TX queue: 3 [ 600.513532] ath: Reset TXQ, inactive queue: 4 [ 600.517930] ath: Reset TXQ, inactive queue: 5 [ 600.522325] ath: Reset TXQ, inactive queue: 6 [ 600.526718] ath: Reset TXQ, inactive queue: 7 [ 600.531113] ath: Reset TX queue: 8 [ 600.534561] ath: Reset TX queue: 9 [ 600.540762] ath: Set queue properties for: 9 [ 600.545091] ath: Reset TX queue: 9 [ 600.640849] ath: Enable TXE on queue: 9 [ 601.566512] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 [ 601.577368] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 601.596278] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 601.603968] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 601.624273] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 601.636474] ath: Reset TX queue: 0 [ 601.639931] ath: Reset TX queue: 1 [ 601.643375] ath: Reset TX queue: 2 [ 601.646814] ath: Reset TX queue: 3 [ 601.650255] ath: Reset TXQ, inactive queue: 4 [ 601.654648] ath: Reset TXQ, inactive queue: 5 [ 601.659040] ath: Reset TXQ, inactive queue: 6 [ 601.663433] ath: Reset TXQ, inactive queue: 7 [ 601.667826] ath: Reset TX queue: 8 [ 601.671277] ath: Reset TX queue: 9 [ 601.677477] ath: Set queue properties for: 9 [ 601.681806] ath: Reset TX queue: 9 [ 601.777567] ath: Enable TXE on queue: 9 [ 602.703270] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 [ 602.714126] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 602.733107] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 602.740800] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 602.761182] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 602.773405] ath: Reset TX queue: 0 [ 602.776860] ath: Reset TX queue: 1 [ 602.780308] ath: Reset TX queue: 2 [ 602.783748] ath: Reset TX queue: 3 [ 602.787190] ath: Reset TXQ, inactive queue: 4 [ 602.791590] ath: Reset TXQ, inactive queue: 5 [ 602.795982] ath: Reset TXQ, inactive queue: 6 [ 602.800377] ath: Reset TXQ, inactive queue: 7 [ 602.804771] ath: Reset TX queue: 8 [ 602.808221] ath: Reset TX queue: 9 [ 602.814422] ath: Set queue properties for: 9 [ 602.818753] ath: Reset TX queue: 9 [ 602.914530] ath: Enable TXE on queue: 9 [ 603.840166] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 [ 603.851022] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 603.869909] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 603.877600] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 603.897916] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 603.910127] ath: Reset TX queue: 0 [ 603.913581] ath: Reset TX queue: 1 [ 603.917023] ath: Reset TX queue: 2 [ 603.920462] ath: Reset TX queue: 3 [ 603.923905] ath: Reset TXQ, inactive queue: 4 [ 603.928307] ath: Reset TXQ, inactive queue: 5 [ 603.932699] ath: Reset TXQ, inactive queue: 6 [ 603.937091] ath: Reset TXQ, inactive queue: 7 [ 603.941484] ath: Reset TX queue: 8 [ 603.944936] ath: Reset TX queue: 9 [ 603.951134] ath: Set queue properties for: 9 [ 603.955466] ath: Reset TX queue: 9 [ 604.051225] ath: Enable TXE on queue: 9 [ 604.976891] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 [ 604.987746] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 605.006735] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 605.014430] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 605.034754] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 605.046956] ath: Reset TX queue: 0 [ 605.050411] ath: Reset TX queue: 1 [ 605.053854] ath: Reset TX queue: 2 [ 605.057303] ath: Reset TX queue: 3 [ 605.060788] ath: Reset TXQ, inactive queue: 4 [ 605.065192] ath: Reset TXQ, inactive queue: 5 [ 605.069590] ath: Reset TXQ, inactive queue: 6 [ 605.073982] ath: Reset TXQ, inactive queue: 7 [ 605.078376] ath: Reset TX queue: 8 [ 605.081826] ath: Reset TX queue: 9 [ 605.088038] ath: Set queue properties for: 9 [ 605.092366] ath: Reset TX queue: 9 [ 605.188161] ath: Enable TXE on queue: 9 [ 606.113820] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 [ 606.124675] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 606.143583] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 606.151275] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 606.171592] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 606.183782] ath: Reset TX queue: 0 [ 606.187241] ath: Reset TX queue: 1 [ 606.190683] ath: Reset TX queue: 2 [ 606.194133] ath: Reset TX queue: 3 [ 606.197581] ath: Reset TXQ, inactive queue: 4 [ 606.201982] ath: Reset TXQ, inactive queue: 5 [ 606.206374] ath: Reset TXQ, inactive queue: 6 [ 606.210767] ath: Reset TXQ, inactive queue: 7 [ 606.215160] ath: Reset TX queue: 8 [ 606.218611] ath: Reset TX queue: 9 [ 606.224803] ath: Set queue properties for: 9 [ 606.229131] ath: Reset TX queue: 9 [ 606.324880] ath: Enable TXE on queue: 9 [ 607.250573] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 [ 607.261401] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 607.280294] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 607.287984] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 607.308292] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 607.320469] ath: Reset TX queue: 0 [ 607.323923] ath: Reset TX queue: 1 [ 607.327365] ath: Reset TX queue: 2 [ 607.330815] ath: Reset TX queue: 3 [ 607.334290] ath: Reset TXQ, inactive queue: 4 [ 607.338689] ath: Reset TXQ, inactive queue: 5 [ 607.343080] ath: Reset TXQ, inactive queue: 6 [ 607.347477] ath: Reset TXQ, inactive queue: 7 [ 607.351868] ath: Reset TX queue: 8 [ 607.355320] ath: Reset TX queue: 9 [ 607.361547] ath: Set queue properties for: 9 [ 607.365873] ath: Reset TX queue: 9 [ 607.461645] ath: Enable TXE on queue: 9 [ 608.387340] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 [ 608.398185] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 608.417136] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 608.424832] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 608.445154] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 608.457373] ath: Reset TX queue: 0 [ 608.460829] ath: Reset TX queue: 1 [ 608.464273] ath: Reset TX queue: 2 [ 608.467720] ath: Reset TX queue: 3 [ 608.471162] ath: Reset TXQ, inactive queue: 4 [ 608.475564] ath: Reset TXQ, inactive queue: 5 [ 608.479964] ath: Reset TXQ, inactive queue: 6 [ 608.484358] ath: Reset TXQ, inactive queue: 7 [ 608.488750] ath: Reset TX queue: 8 [ 608.492201] ath: Reset TX queue: 9 [ 608.498401] ath: Set queue properties for: 9 [ 608.502730] ath: Reset TX queue: 9 [ 608.598520] ath: Enable TXE on queue: 9 [ 609.524198] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 [ 609.535053] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 609.553987] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 609.561678] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 609.581992] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 609.594203] ath: Reset TX queue: 0 [ 609.597660] ath: Reset TX queue: 1 [ 609.601102] ath: Reset TX queue: 2 [ 609.604548] ath: Reset TX queue: 3 [ 609.607989] ath: Reset TXQ, inactive queue: 4 [ 609.612384] ath: Reset TXQ, inactive queue: 5 [ 609.616777] ath: Reset TXQ, inactive queue: 6 [ 609.621168] ath: Reset TXQ, inactive queue: 7 [ 609.625562] ath: Reset TX queue: 8 [ 609.629013] ath: Reset TX queue: 9 [ 609.635213] ath: Set queue properties for: 9 [ 609.639542] ath: Reset TX queue: 9 [ 609.735332] ath: Enable TXE on queue: 9 [ 610.660995] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 [ 610.671842] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 610.690802] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 610.698499] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 610.718807] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 610.731028] ath: Reset TX queue: 0 [ 610.734476] ath: Reset TX queue: 1 [ 610.737922] ath: Reset TX queue: 2 [ 610.741371] ath: Reset TX queue: 3 [ 610.744810] ath: Reset TXQ, inactive queue: 4 [ 610.749205] ath: Reset TXQ, inactive queue: 5 [ 610.753605] ath: Reset TXQ, inactive queue: 6 [ 610.757998] ath: Reset TXQ, inactive queue: 7 [ 610.762391] ath: Reset TX queue: 8 [ 610.765842] ath: Reset TX queue: 9 [ 610.772045] ath: Set queue properties for: 9 [ 610.776372] ath: Reset TX queue: 9 [ 610.872125] ath: Enable TXE on queue: 9 [ 611.797822] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 [ 611.808666] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 611.827561] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 611.835259] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 611.855601] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 611.867777] ath: Reset TX queue: 0 [ 611.871230] ath: Reset TX queue: 1 [ 611.874673] ath: Reset TX queue: 2 [ 611.878120] ath: Reset TX queue: 3 [ 611.881591] ath: Reset TXQ, inactive queue: 4 [ 611.885989] ath: Reset TXQ, inactive queue: 5 [ 611.890381] ath: Reset TXQ, inactive queue: 6 [ 611.894775] ath: Reset TXQ, inactive queue: 7 [ 611.899168] ath: Reset TX queue: 8 [ 611.902618] ath: Reset TX queue: 9 [ 611.908846] ath: Set queue properties for: 9 [ 611.913176] ath: Reset TX queue: 9 [ 612.008933] ath: Enable TXE on queue: 9 [ 612.934678] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 [ 612.945534] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 612.964430] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 612.972121] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 612.992426] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 613.004684] ath: Reset TX queue: 0 [ 613.008137] ath: Reset TX queue: 1 [ 613.011578] ath: Reset TX queue: 2 [ 613.015037] ath: Reset TX queue: 3 [ 613.018479] ath: Reset TXQ, inactive queue: 4 [ 613.022878] ath: Reset TXQ, inactive queue: 5 [ 613.027271] ath: Reset TXQ, inactive queue: 6 [ 613.031666] ath: Reset TXQ, inactive queue: 7 [ 613.036060] ath: Reset TX queue: 8 [ 613.039509] ath: Reset TX queue: 9 [ 613.045703] ath: Set queue properties for: 9 [ 613.050030] ath: Reset TX queue: 9 [ 613.145822] ath: Enable TXE on queue: 9 [ 614.071505] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 [ 614.082362] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 614.101292] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 614.108986] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 614.129346] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 614.141563] ath: Reset TX queue: 0 [ 614.145018] ath: Reset TX queue: 1 [ 614.148461] ath: Reset TX queue: 2 [ 614.151900] ath: Reset TX queue: 3 [ 614.155342] ath: Reset TXQ, inactive queue: 4 [ 614.159733] ath: Reset TXQ, inactive queue: 5 [ 614.164129] ath: Reset TXQ, inactive queue: 6 [ 614.168520] ath: Reset TXQ, inactive queue: 7 [ 614.172915] ath: Reset TX queue: 8 [ 614.176365] ath: Reset TX queue: 9 [ 614.182558] ath: Set queue properties for: 9 [ 614.186886] ath: Reset TX queue: 9 [ 614.282647] ath: Enable TXE on queue: 9 ^C[ 614.494452] ath: qnum: 0, txq depth: 0 [ 614.498324] ath: Enable TXE on queue: 0 [ 614.522420] PM: Removing info for No Bus:mon.wlan0 [ 614.795955] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 [ 614.806919] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 614.825618] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 [ 614.836493] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 614.848169] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 [ 614.859083] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 614.866350] ieee80211 phy0: device now idle [ 615.052173] ath: Drop frames from hw queue:0 [ 615.060878] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 0 [ 615.071768] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 615.083072] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 [ 615.093887] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 615.105036] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 0 [ 615.115854] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 615.122901] ath: Failed to stop TX DMA! [ 615.138958] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 615.146659] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 615.167008] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 615.179248] ath: Reset TX queue: 0 [ 615.182707] ath: Reset TX queue: 1 [ 615.186158] ath: Reset TX queue: 2 [ 615.189605] ath: Reset TX queue: 3 [ 615.193055] ath: Reset TXQ, inactive queue: 4 [ 615.197505] ath: Reset TXQ, inactive queue: 5 [ 615.201905] ath: Reset TXQ, inactive queue: 6 [ 615.206304] ath: Reset TXQ, inactive queue: 7 [ 615.210700] ath: Reset TX queue: 8 [ 615.214158] ath: Reset TX queue: 9 [ 615.233921] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 615.241624] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 615.255148] ath: Reset TX queue: 0 [ 615.258607] ath: Reset TX queue: 1 [ 615.262092] ath: Reset TX queue: 2 [ 615.265542] ath: Reset TX queue: 3 [ 615.268991] ath: Reset TXQ, inactive queue: 4 [ 615.273391] ath: Reset TXQ, inactive queue: 5 [ 615.277793] ath: Reset TXQ, inactive queue: 6 [ 615.282187] ath: Reset TXQ, inactive queue: 7 [ 615.286582] ath: Reset TX queue: 8 [ 615.290032] ath: Reset TX queue: 9 # -- Bernhard ^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards 2011-02-24 9:33 ` Bernhard Schmidt @ 2011-02-24 18:18 ` Luis R. Rodriguez 2011-02-25 9:37 ` Bernhard Schmidt 0 siblings, 1 reply; 26+ messages in thread From: Luis R. Rodriguez @ 2011-02-24 18:18 UTC (permalink / raw) To: ath9k-devel On Thu, Feb 24, 2011 at 01:33:18AM -0800, Bernhard Schmidt wrote: > > I've stripped everything not necessary, this one is use for the log > below. > > # cat /etc/hostapd.conf > interface=wlan0 > driver=nl80211 > ssid=testtest > hw_mode=a > channel=44 > [ 574.605956] ath: Enable TXE on queue: 9 > [ 574.708386] ath: Enable TXE on queue: 9 > [ 574.810752] ath: Enable TXE on queue: 9 > [ 574.913151] ath: Enable TXE on queue: 9 > [ 575.015541] ath: Enable TXE on queue: 9 > [ 575.117938] ath: Enable TXE on queue: 9 > [ 575.220335] ath: Enable TXE on queue: 9 > [ 575.322732] ath: Enable TXE on queue: 9 > [ 576.248395] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 > [ 576.259188] ath: Failed to stop TX DMA in 100 msec after killing last frame Can you confirm what kernel ? I see 2.6.38-rc6-wl-12466-g09f3227 So I take it you are using wireless-testing, is this right? Can you reproduce with wireless-testing as of today? This would be helpful for our own testing. Luis ^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards 2011-02-24 18:18 ` Luis R. Rodriguez @ 2011-02-25 9:37 ` Bernhard Schmidt 2011-02-25 17:12 ` Luis R. Rodriguez 0 siblings, 1 reply; 26+ messages in thread From: Bernhard Schmidt @ 2011-02-25 9:37 UTC (permalink / raw) To: ath9k-devel On Thursday, February 24, 2011 19:18:25 Luis R. Rodriguez wrote: > On Thu, Feb 24, 2011 at 01:33:18AM -0800, Bernhard Schmidt wrote: > > > > I've stripped everything not necessary, this one is use for the log > > below. > > > > # cat /etc/hostapd.conf > > interface=wlan0 > > driver=nl80211 > > ssid=testtest > > hw_mode=a > > channel=44 > > > [ 574.605956] ath: Enable TXE on queue: 9 > > [ 574.708386] ath: Enable TXE on queue: 9 > > [ 574.810752] ath: Enable TXE on queue: 9 > > [ 574.913151] ath: Enable TXE on queue: 9 > > [ 575.015541] ath: Enable TXE on queue: 9 > > [ 575.117938] ath: Enable TXE on queue: 9 > > [ 575.220335] ath: Enable TXE on queue: 9 > > [ 575.322732] ath: Enable TXE on queue: 9 > > [ 576.248395] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 > > [ 576.259188] ath: Failed to stop TX DMA in 100 msec after killing last frame > > Can you confirm what kernel ? > > I see 2.6.38-rc6-wl-12466-g09f3227 > > So I take it you are using wireless-testing, is this right? Can you reproduce with > wireless-testing as of today? This would be helpful for our own testing. Yes, the logs were posted using wireless-testing, always pulled before doing the tests. Just to confirm, with wireless-testing as of a few minutes ago, same behavior. # uname -a Linux meshnode 2.6.38-rc6-wl-12527-g8ccd3c8 #25 SMP Fri Feb 25 10:19:49 CET 2011 i686 GNU/Linux # git log --pretty=oneline | head -n1 8ccd3c862a39d46626ba89777e59d1775a579b62 Merge ssh://master.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6 [ 176.675020] ath: Enable TXE on queue: 9 [ 176.777416] ath: Enable TXE on queue: 9 [ 176.827134] ath: qnum: 0, txq depth: 0 [ 176.831007] ath: Enable TXE on queue: 0 [ 176.834979] ath: tx queue 0 (2f1b01f4), link ef1b01f4 [ 176.840244] ath: tx queue 0 (2f1b01f4), link ef1b01f4 [ 176.879857] ath: Enable TXE on queue: 9 [ 176.982217] ath: Enable TXE on queue: 9 .. [ 202.786342] ath: Enable TXE on queue: 9 [ 202.888732] ath: Enable TXE on queue: 9 [ 203.814434] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 [ 203.825260] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 203.836898] ath: Reset TX queue: 0 [ 203.840352] ath: Reset TX queue: 1 [ 203.843794] ath: Reset TX queue: 2 [ 203.847238] ath: Reset TX queue: 3 [ 203.850683] ath: Reset TXQ, inactive queue: 4 [ 203.855077] ath: Reset TXQ, inactive queue: 5 [ 203.859469] ath: Reset TXQ, inactive queue: 6 [ 203.863864] ath: Reset TXQ, inactive queue: 7 [ 203.868258] ath: Reset TX queue: 8 [ 203.871709] ath: Reset TX queue: 9 [ 203.877917] ath: Set queue properties for: 9 [ 203.882244] ath: Reset TX queue: 9 [ 203.978048] ath: Enable TXE on queue: 9 [ 204.903691] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 [ 204.914536] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 204.933408] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 204.941106] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 204.949576] ------------[ cut here ]------------ [ 204.954249] WARNING: at drivers/net/wireless/ath/ath9k/recv.c:509 ath_stoprecv+0xb7/0xc9 [ath9k]() [ 204.963240] Hardware name: To be filled by O.E.M. [ 204.967982] Modules linked in: ath9k mac80211 ath9k_common ath9k_hw ath cfg80211 e1000e [last unloaded: cfg80211] [ 204.978657] Pid: 0, comm: swapper Not tainted 2.6.38-rc6-wl-12527-g8ccd3c8 #25 [ 204.985905] Call Trace: [ 204.988409] [<c01288c2>] ? warn_slowpath_common+0x6a/0x7f [ 204.993952] [<f88e9bcb>] ? ath_stoprecv+0xb7/0xc9 [ath9k] [ 204.999483] [<c01288eb>] ? warn_slowpath_null+0x14/0x18 [ 205.004860] [<f88e9bcb>] ? ath_stoprecv+0xb7/0xc9 [ath9k] [ 205.010398] [<f88e6d37>] ? ath_reset+0x6b/0x185 [ath9k] [ 205.015760] [<f88e4aa9>] ? ath9k_ioread32+0x56/0x60 [ath9k] [ 205.021486] [<f88e3186>] ? ath_beacon_tasklet+0xad/0x63c [ath9k] [ 205.027622] [<c0233190>] ? trace_hardirqs_on_thunk+0xc/0x10 [ 205.033326] [<c037a31c>] ? restore_all_notrace+0x0/0x18 [ 205.038680] [<c037a05f>] ? _raw_spin_unlock_irq+0x29/0x2b [ 205.044209] [<c01337af>] ? run_timer_softirq+0x28a/0x292 [ 205.049654] [<c012d825>] ? tasklet_action+0x3a/0xd9 [ 205.054661] [<c012d858>] ? tasklet_action+0x6d/0xd9 [ 205.059670] [<c012df14>] ? __do_softirq+0xb1/0x16a [ 205.064591] [<c012de63>] ? __do_softirq+0x0/0x16a [ 205.069449] <IRQ> [<c012d62a>] ? irq_exit+0x3a/0x3c [ 205.074644] [<c0103dc2>] ? do_IRQ+0x81/0x95 [ 205.078957] [<c0102d6e>] ? common_interrupt+0x2e/0x34 [ 205.084146] [<c027a4bc>] ? acpi_idle_enter_bm+0x24b/0x27f [ 205.089676] [<c02ef3cf>] ? cpuidle_idle_call+0xee/0x183 [ 205.095035] [<c0101aec>] ? cpu_idle+0x44/0x5c [ 205.099528] [<c0368d5e>] ? rest_init+0x92/0x97 [ 205.104107] [<c04f4884>] ? start_kernel+0x2d7/0x2dc [ 205.109122] [<c04f40d2>] ? i386_start_kernel+0xd2/0xd9 [ 205.114382] ---[ end trace dfe2ba9402d5b1b9 ]--- [ 205.130883] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 205.143064] ath: Reset TX queue: 0 [ 205.146515] ath: Reset TX queue: 1 [ 205.149959] ath: Reset TX queue: 2 [ 205.153401] ath: Reset TX queue: 3 [ 205.156849] ath: Reset TXQ, inactive queue: 4 [ 205.161249] ath: Reset TXQ, inactive queue: 5 [ 205.165641] ath: Reset TXQ, inactive queue: 6 [ 205.170034] ath: Reset TXQ, inactive queue: 7 [ 205.174459] ath: Reset TX queue: 8 [ 205.177913] ath: Reset TX queue: 9 [ 205.184112] ath: Set queue properties for: 9 [ 205.188473] ath: Reset TX queue: 9 [ 205.284238] ath: Enable TXE on queue: 9 [ 206.209936] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 [ 206.220793] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 206.239678] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 206.247372] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 206.267676] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 206.279844] ath: Reset TX queue: 0 [ 206.283302] ath: Reset TX queue: 1 [ 206.286744] ath: Reset TX queue: 2 [ 206.290185] ath: Reset TX queue: 3 [ 206.293633] ath: Reset TXQ, inactive queue: 4 [ 206.298026] ath: Reset TXQ, inactive queue: 5 [ 206.302418] ath: Reset TXQ, inactive queue: 6 [ 206.306813] ath: Reset TXQ, inactive queue: 7 [ 206.311204] ath: Reset TX queue: 8 [ 206.314655] ath: Reset TX queue: 9 [ 206.320858] ath: Set queue properties for: 9 [ 206.325186] ath: Reset TX queue: 9 [ 206.420948] ath: Enable TXE on queue: 9 [ 207.346657] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 [ 207.357515] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 207.376403] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 207.384127] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 207.404435] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 .. -- Bernhard ^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards 2011-02-25 9:37 ` Bernhard Schmidt @ 2011-02-25 17:12 ` Luis R. Rodriguez 2011-02-26 9:37 ` Bernhard Schmidt 0 siblings, 1 reply; 26+ messages in thread From: Luis R. Rodriguez @ 2011-02-25 17:12 UTC (permalink / raw) To: ath9k-devel On Fri, Feb 25, 2011 at 01:37:07AM -0800, Bernhard Schmidt wrote: > On Thursday, February 24, 2011 19:18:25 Luis R. Rodriguez wrote: > > On Thu, Feb 24, 2011 at 01:33:18AM -0800, Bernhard Schmidt wrote: > > > > > > I've stripped everything not necessary, this one is use for the log > > > below. > > > > > > # cat /etc/hostapd.conf > > > interface=wlan0 > > > driver=nl80211 > > > ssid=testtest > > > hw_mode=a > > > channel=44 > > > > > [ 574.605956] ath: Enable TXE on queue: 9 > > > [ 574.708386] ath: Enable TXE on queue: 9 > > > [ 574.810752] ath: Enable TXE on queue: 9 > > > [ 574.913151] ath: Enable TXE on queue: 9 > > > [ 575.015541] ath: Enable TXE on queue: 9 > > > [ 575.117938] ath: Enable TXE on queue: 9 > > > [ 575.220335] ath: Enable TXE on queue: 9 > > > [ 575.322732] ath: Enable TXE on queue: 9 > > > [ 576.248395] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 > > > [ 576.259188] ath: Failed to stop TX DMA in 100 msec after killing last frame > > > > Can you confirm what kernel ? > > > > I see 2.6.38-rc6-wl-12466-g09f3227 > > > > So I take it you are using wireless-testing, is this right? Can you reproduce with > > wireless-testing as of today? This would be helpful for our own testing. > > Yes, the logs were posted using wireless-testing, always pulled before > doing the tests. > > Just to confirm, with wireless-testing as of a few minutes ago, same > behavior. > > # uname -a > Linux meshnode 2.6.38-rc6-wl-12527-g8ccd3c8 #25 SMP Fri Feb 25 10:19:49 CET 2011 i686 GNU/Linux > # git log --pretty=oneline | head -n1 > 8ccd3c862a39d46626ba89777e59d1775a579b62 Merge ssh://master.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6 > > [ 176.675020] ath: Enable TXE on queue: 9 > [ 176.777416] ath: Enable TXE on queue: 9 > [ 176.827134] ath: qnum: 0, txq depth: 0 > [ 176.831007] ath: Enable TXE on queue: 0 > [ 176.834979] ath: tx queue 0 (2f1b01f4), link ef1b01f4 > [ 176.840244] ath: tx queue 0 (2f1b01f4), link ef1b01f4 > [ 176.879857] ath: Enable TXE on queue: 9 > [ 176.982217] ath: Enable TXE on queue: 9 > .. > [ 202.786342] ath: Enable TXE on queue: 9 > [ 202.888732] ath: Enable TXE on queue: 9 > [ 203.814434] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 > [ 203.825260] ath: Failed to stop TX DMA in 100 msec after killing last frame > [ 203.836898] ath: Reset TX queue: 0 > [ 203.840352] ath: Reset TX queue: 1 > [ 203.843794] ath: Reset TX queue: 2 > [ 203.847238] ath: Reset TX queue: 3 > [ 203.850683] ath: Reset TXQ, inactive queue: 4 > [ 203.855077] ath: Reset TXQ, inactive queue: 5 > [ 203.859469] ath: Reset TXQ, inactive queue: 6 > [ 203.863864] ath: Reset TXQ, inactive queue: 7 > [ 203.868258] ath: Reset TX queue: 8 > [ 203.871709] ath: Reset TX queue: 9 > [ 203.877917] ath: Set queue properties for: 9 > [ 203.882244] ath: Reset TX queue: 9 > [ 203.978048] ath: Enable TXE on queue: 9 > [ 204.903691] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9 > [ 204.914536] ath: Failed to stop TX DMA in 100 msec after killing last frame > [ 204.933408] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 > [ 204.941106] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up > [ 204.949576] ------------[ cut here ]------------ > [ 204.954249] WARNING: at drivers/net/wireless/ath/ath9k/recv.c:509 ath_stoprecv+0xb7/0xc9 [ath9k]() Ok neat.. how soon after starting hostapd does this come up, immeidiately? What version of hostapd? Luis ^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards 2011-02-25 17:12 ` Luis R. Rodriguez @ 2011-02-26 9:37 ` Bernhard Schmidt 2011-03-10 0:40 ` Felix Fietkau 0 siblings, 1 reply; 26+ messages in thread From: Bernhard Schmidt @ 2011-02-26 9:37 UTC (permalink / raw) To: ath9k-devel On Friday 25 February 2011 18:12:09 Luis R. Rodriguez wrote: > On Fri, Feb 25, 2011 at 01:37:07AM -0800, Bernhard Schmidt wrote: > > On Thursday, February 24, 2011 19:18:25 Luis R. Rodriguez wrote: > > > On Thu, Feb 24, 2011 at 01:33:18AM -0800, Bernhard Schmidt wrote: > > > > I've stripped everything not necessary, this one is use for the > > > > log below. > > > > > > > > # cat /etc/hostapd.conf > > > > interface=wlan0 > > > > driver=nl80211 > > > > ssid=testtest > > > > hw_mode=a > > > > channel=44 > > > > > > > > [ 574.605956] ath: Enable TXE on queue: 9 > > > > [ 574.708386] ath: Enable TXE on queue: 9 > > > > [ 574.810752] ath: Enable TXE on queue: 9 > > > > [ 574.913151] ath: Enable TXE on queue: 9 > > > > [ 575.015541] ath: Enable TXE on queue: 9 > > > > [ 575.117938] ath: Enable TXE on queue: 9 > > > > [ 575.220335] ath: Enable TXE on queue: 9 > > > > [ 575.322732] ath: Enable TXE on queue: 9 > > > > [ 576.248395] ath: ath9k_hw_stoptxdma: Num of pending TX > > > > Frames 1 on Q 9 [ 576.259188] ath: Failed to stop TX DMA in > > > > 100 msec after killing last frame > > > > > > Can you confirm what kernel ? > > > > > > I see 2.6.38-rc6-wl-12466-g09f3227 > > > > > > So I take it you are using wireless-testing, is this right? Can > > > you reproduce with wireless-testing as of today? This would be > > > helpful for our own testing. > > > > Yes, the logs were posted using wireless-testing, always pulled > > before doing the tests. > > > > Just to confirm, with wireless-testing as of a few minutes ago, > > same behavior. > > > > # uname -a > > Linux meshnode 2.6.38-rc6-wl-12527-g8ccd3c8 #25 SMP Fri Feb 25 > > 10:19:49 CET 2011 i686 GNU/Linux # git log --pretty=oneline | head > > -n1 > > 8ccd3c862a39d46626ba89777e59d1775a579b62 Merge > > ssh://master.kernel.org/pub/scm/linux/kernel/git/linville/wireless > > -next-2.6 > > > > [ 176.675020] ath: Enable TXE on queue: 9 > > [ 176.777416] ath: Enable TXE on queue: 9 > > [ 176.827134] ath: qnum: 0, txq depth: 0 > > [ 176.831007] ath: Enable TXE on queue: 0 > > [ 176.834979] ath: tx queue 0 (2f1b01f4), link ef1b01f4 > > [ 176.840244] ath: tx queue 0 (2f1b01f4), link ef1b01f4 > > [ 176.879857] ath: Enable TXE on queue: 9 > > [ 176.982217] ath: Enable TXE on queue: 9 > > .. > > [ 202.786342] ath: Enable TXE on queue: 9 > > [ 202.888732] ath: Enable TXE on queue: 9 > > [ 203.814434] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 > > on Q 9 [ 203.825260] ath: Failed to stop TX DMA in 100 msec after > > killing last frame > > > > [ 203.836898] ath: Reset TX queue: 0 > > [ 203.840352] ath: Reset TX queue: 1 > > [ 203.843794] ath: Reset TX queue: 2 > > [ 203.847238] ath: Reset TX queue: 3 > > [ 203.850683] ath: Reset TXQ, inactive queue: 4 > > [ 203.855077] ath: Reset TXQ, inactive queue: 5 > > [ 203.859469] ath: Reset TXQ, inactive queue: 6 > > [ 203.863864] ath: Reset TXQ, inactive queue: 7 > > [ 203.868258] ath: Reset TX queue: 8 > > [ 203.871709] ath: Reset TX queue: 9 > > [ 203.877917] ath: Set queue properties for: 9 > > [ 203.882244] ath: Reset TX queue: 9 > > [ 203.978048] ath: Enable TXE on queue: 9 > > [ 204.903691] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 > > on Q 9 [ 204.914536] ath: Failed to stop TX DMA in 100 msec after > > killing last frame [ 204.933408] ath: DMA failed to stop in 10 ms > > AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 204.941106] ath: Could > > not stop RX, we could be confusing the DMA engine when we start RX > > up [ 204.949576] ------------[ cut here ]------------ > > [ 204.954249] WARNING: at > > drivers/net/wireless/ath/ath9k/recv.c:509 ath_stoprecv+0xb7/0xc9 > > [ath9k]() > > Ok neat.. how soon after starting hostapd does this come up, > immeidiately? 2 mails back is a complete log including timestamps, about 30 seconds from hostapd start until the error. > What version of hostapd? hostap.git @cbcf92b4 -- Bernhard ^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards 2011-02-26 9:37 ` Bernhard Schmidt @ 2011-03-10 0:40 ` Felix Fietkau 0 siblings, 0 replies; 26+ messages in thread From: Felix Fietkau @ 2011-03-10 0:40 UTC (permalink / raw) To: ath9k-devel On 2011-02-26 10:37 AM, Bernhard Schmidt wrote: > On Friday 25 February 2011 18:12:09 Luis R. Rodriguez wrote: >> On Fri, Feb 25, 2011 at 01:37:07AM -0800, Bernhard Schmidt wrote: >> > On Thursday, February 24, 2011 19:18:25 Luis R. Rodriguez wrote: >> > > On Thu, Feb 24, 2011 at 01:33:18AM -0800, Bernhard Schmidt wrote: >> > > > I've stripped everything not necessary, this one is use for the >> > > > log below. >> > > > >> > > > # cat /etc/hostapd.conf >> > > > interface=wlan0 >> > > > driver=nl80211 >> > > > ssid=testtest >> > > > hw_mode=a >> > > > channel=44 >> > > > >> > > > [ 574.605956] ath: Enable TXE on queue: 9 >> > > > [ 574.708386] ath: Enable TXE on queue: 9 >> > > > [ 574.810752] ath: Enable TXE on queue: 9 >> > > > [ 574.913151] ath: Enable TXE on queue: 9 >> > > > [ 575.015541] ath: Enable TXE on queue: 9 >> > > > [ 575.117938] ath: Enable TXE on queue: 9 >> > > > [ 575.220335] ath: Enable TXE on queue: 9 >> > > > [ 575.322732] ath: Enable TXE on queue: 9 >> > > > [ 576.248395] ath: ath9k_hw_stoptxdma: Num of pending TX >> > > > Frames 1 on Q 9 [ 576.259188] ath: Failed to stop TX DMA in >> > > > 100 msec after killing last frame >> > > >> > > Can you confirm what kernel ? >> > > >> > > I see 2.6.38-rc6-wl-12466-g09f3227 >> > > >> > > So I take it you are using wireless-testing, is this right? Can >> > > you reproduce with wireless-testing as of today? This would be >> > > helpful for our own testing. >> > >> > Yes, the logs were posted using wireless-testing, always pulled >> > before doing the tests. >> > >> > Just to confirm, with wireless-testing as of a few minutes ago, >> > same behavior. >> > >> > # uname -a >> > Linux meshnode 2.6.38-rc6-wl-12527-g8ccd3c8 #25 SMP Fri Feb 25 >> > 10:19:49 CET 2011 i686 GNU/Linux # git log --pretty=oneline | head >> > -n1 >> > 8ccd3c862a39d46626ba89777e59d1775a579b62 Merge >> > ssh://master.kernel.org/pub/scm/linux/kernel/git/linville/wireless >> > -next-2.6 >> > >> > [ 176.675020] ath: Enable TXE on queue: 9 >> > [ 176.777416] ath: Enable TXE on queue: 9 >> > [ 176.827134] ath: qnum: 0, txq depth: 0 >> > [ 176.831007] ath: Enable TXE on queue: 0 >> > [ 176.834979] ath: tx queue 0 (2f1b01f4), link ef1b01f4 >> > [ 176.840244] ath: tx queue 0 (2f1b01f4), link ef1b01f4 >> > [ 176.879857] ath: Enable TXE on queue: 9 >> > [ 176.982217] ath: Enable TXE on queue: 9 >> > .. >> > [ 202.786342] ath: Enable TXE on queue: 9 >> > [ 202.888732] ath: Enable TXE on queue: 9 >> > [ 203.814434] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 >> > on Q 9 [ 203.825260] ath: Failed to stop TX DMA in 100 msec after >> > killing last frame >> > >> > [ 203.836898] ath: Reset TX queue: 0 >> > [ 203.840352] ath: Reset TX queue: 1 >> > [ 203.843794] ath: Reset TX queue: 2 >> > [ 203.847238] ath: Reset TX queue: 3 >> > [ 203.850683] ath: Reset TXQ, inactive queue: 4 >> > [ 203.855077] ath: Reset TXQ, inactive queue: 5 >> > [ 203.859469] ath: Reset TXQ, inactive queue: 6 >> > [ 203.863864] ath: Reset TXQ, inactive queue: 7 >> > [ 203.868258] ath: Reset TX queue: 8 >> > [ 203.871709] ath: Reset TX queue: 9 >> > [ 203.877917] ath: Set queue properties for: 9 >> > [ 203.882244] ath: Reset TX queue: 9 >> > [ 203.978048] ath: Enable TXE on queue: 9 >> > [ 204.903691] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 >> > on Q 9 [ 204.914536] ath: Failed to stop TX DMA in 100 msec after >> > killing last frame [ 204.933408] ath: DMA failed to stop in 10 ms >> > AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 204.941106] ath: Could >> > not stop RX, we could be confusing the DMA engine when we start RX >> > up [ 204.949576] ------------[ cut here ]------------ >> > [ 204.954249] WARNING: at >> > drivers/net/wireless/ath/ath9k/recv.c:509 ath_stoprecv+0xb7/0xc9 >> > [ath9k]() >> >> Ok neat.. how soon after starting hostapd does this come up, >> immeidiately? > > 2 mails back is a complete log including timestamps, about 30 seconds > from hostapd start until the error. > >> What version of hostapd? > > hostap.git @cbcf92b4 I just sent out a 4-patch series to linux-wireless@ which almost completely fixes all the tx dma stop issues that I could reproduce in my setup. Please give it a try and let me know if it fixes your issues as well. - Felix ^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards 2011-02-23 20:06 ` Bernhard Schmidt 2011-02-24 9:33 ` Bernhard Schmidt @ 2011-03-02 14:51 ` Mohammed Shafi 2011-03-04 11:29 ` Bernhard Schmidt 1 sibling, 1 reply; 26+ messages in thread From: Mohammed Shafi @ 2011-03-02 14:51 UTC (permalink / raw) To: ath9k-devel 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: >> > 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. :) 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 > >> 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 > _______________________________________________ > ath9k-devel mailing list > ath9k-devel at lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > ^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards 2011-03-02 14:51 ` Mohammed Shafi @ 2011-03-04 11:29 ` Bernhard Schmidt 2011-03-04 15:25 ` Mohammed Shafi 2011-03-05 23:49 ` crocket 0 siblings, 2 replies; 26+ messages in thread From: Bernhard Schmidt @ 2011-03-04 11:29 UTC (permalink / raw) To: ath9k-devel 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. 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. -- Bernhard ^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards 2011-03-04 11:29 ` Bernhard Schmidt @ 2011-03-04 15:25 ` Mohammed Shafi 2011-03-04 15:29 ` Mohammed Shafi 2011-03-05 23:49 ` crocket 1 sibling, 1 reply; 26+ messages in thread From: Mohammed Shafi @ 2011-03-04 15:25 UTC (permalink / raw) To: ath9k-devel 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. > Oh the issue is easily reproducible with AR9280 > -- > Bernhard > ^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards 2011-03-04 15:25 ` Mohammed Shafi @ 2011-03-04 15:29 ` Mohammed Shafi 2011-03-04 17:16 ` Bernhard Schmidt 0 siblings, 1 reply; 26+ messages in thread From: Mohammed Shafi @ 2011-03-04 15:29 UTC (permalink / raw) To: ath9k-devel 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? thanks, shafi >> > > Oh the issue is easily reproducible with AR9280 > >> -- >> Bernhard >> > ^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards 2011-03-04 15:29 ` Mohammed Shafi @ 2011-03-04 17:16 ` Bernhard Schmidt 2011-03-09 9:58 ` Mohammed Shafi 2011-03-09 10:01 ` Mohammed Shafi 0 siblings, 2 replies; 26+ messages in thread From: Bernhard Schmidt @ 2011-03-04 17:16 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards 2011-03-04 17:16 ` Bernhard Schmidt @ 2011-03-09 9:58 ` Mohammed Shafi 2011-03-09 10:01 ` Mohammed Shafi 1 sibling, 0 replies; 26+ messages in thread From: Mohammed Shafi @ 2011-03-09 9:58 UTC (permalink / raw) To: ath9k-devel On Fri, Mar 4, 2011 at 10:46 PM, Bernhard Schmidt <bschmidt@techwires.net> wrote: > 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. Ok thanks, looks like the deafness happens when configured as AP mode > > -- > Bernhard > ^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards 2011-03-04 17:16 ` Bernhard Schmidt 2011-03-09 9:58 ` Mohammed Shafi @ 2011-03-09 10:01 ` Mohammed Shafi 1 sibling, 0 replies; 26+ messages in thread From: Mohammed Shafi @ 2011-03-09 10:01 UTC (permalink / raw) To: ath9k-devel On Fri, Mar 4, 2011 at 10:46 PM, Bernhard Schmidt <bschmidt@techwires.net> wrote: > 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. Ok does the fix provided by Felix might help this issue? [PATCH 2.6.38] ath9k: remove support for the FIF_PROMISC_IN_BSS filter flag > > -- > Bernhard > ^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards 2011-03-04 11:29 ` Bernhard Schmidt 2011-03-04 15:25 ` Mohammed Shafi @ 2011-03-05 23:49 ` crocket 2011-03-09 10:22 ` Peter Stuge 1 sibling, 1 reply; 26+ messages in thread From: crocket @ 2011-03-05 23:49 UTC (permalink / raw) To: ath9k-devel I knew it. AR9280 wouldn't last days or months in AP or station mode. AR9280 would go deaf after one or more scan requests and after hostapd stays idle for a while. I don't know why Luis said " "DMA failed to stop" issues are non-fatal " It definitely stops the chipset and is certainly fatal. On Fri, Mar 4, 2011 at 8:29 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. > > 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. > > -- > Bernhard > _______________________________________________ > ath9k-devel mailing list > ath9k-devel at lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > ^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards 2011-03-05 23:49 ` crocket @ 2011-03-09 10:22 ` Peter Stuge 0 siblings, 0 replies; 26+ messages in thread From: Peter Stuge @ 2011-03-09 10:22 UTC (permalink / raw) To: ath9k-devel crocket wrote: > I don't know why Luis said " "DMA failed to stop" issues are non-fatal " > It definitely stops the chipset and is certainly fatal. I believe because Luis has only seen the error message in other, unrelated, circumstances, where the issue is indeed not fatal. This can of course not invalidate reports of the issue having a different effect. //Peter ^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards @ 2011-02-23 15:34 Bernhard Schmidt 2011-02-23 16:22 ` Peter Stuge 0 siblings, 1 reply; 26+ messages in thread From: Bernhard Schmidt @ 2011-02-23 15:34 UTC (permalink / raw) To: ath9k-devel Hi, [resend, due to ehlo/MX being checked case sensitive] 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 .. % 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 % .. A monitor mode vif on another interface tells me that on average only 6 beacons leave the device before it's going deaf. Restarting hostapd will make it send another 6 beacons. Behaviour in sta mode is similar unusable, if I'm lucky enough to get any scan results the connect fails or it goes deaf after the first few packets have been transmitted. I tried a few different kernel version back to 2.6.36.4 which all have the same behaviour (except the error messages, which have been mask till lately). Also, this issue seems to be only seen on AR9820, all other chips I have (9160, 9220, 93xx) work as expected. Felix already told me that this is a known issue and going over other reports on this list and linux-wireless-ml it indeed is. Just wanted to know if there is any "known-good" kernel version or a workaround for that? -- Bernhard ^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards 2011-02-23 15:34 Bernhard Schmidt @ 2011-02-23 16:22 ` Peter Stuge 2011-02-23 18:02 ` Luis R. Rodriguez 0 siblings, 1 reply; 26+ messages in thread From: Peter Stuge @ 2011-02-23 16:22 UTC (permalink / raw) To: ath9k-devel Bernhard Schmidt wrote: > Felix already told me that this is a known issue and going over other > reports on this list and linux-wireless-ml it indeed is. Just wanted > to know if there is any "known-good" kernel version or a workaround > for that? I fear you will not get any further info on this mailing list. I would suggest to watch the l-w list and try any patches that are sent there. They never appear here and there's also no discussion here. Thinking about it I actually don't really understand the purpose of this list. It's mostly disinforming, in that it detracts from l-w, which seems to be the more significant forum for ath9k development. //Peter ^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards 2011-02-23 16:22 ` Peter Stuge @ 2011-02-23 18:02 ` Luis R. Rodriguez 2011-02-23 19:51 ` Peter Stuge 0 siblings, 1 reply; 26+ messages in thread From: Luis R. Rodriguez @ 2011-02-23 18:02 UTC (permalink / raw) To: ath9k-devel On Wed, Feb 23, 2011 at 08:22:30AM -0800, Peter Stuge wrote: > Bernhard Schmidt wrote: > > Felix already told me that this is a known issue and going over other > > reports on this list and linux-wireless-ml it indeed is. Just wanted > > to know if there is any "known-good" kernel version or a workaround > > for that? > > I fear you will not get any further info on this mailing list. I would > suggest to watch the l-w list and try any patches that are sent there. > > They never appear here and there's also no discussion here. Thinking > about it I actually don't really understand the purpose of this list. > It's mostly disinforming, in that it detracts from l-w, which seems > to be the more significant forum for ath9k development. Would you stop trolling, really. I told you what you can do to help with resolving observed issues, where are your bug reports BTW? Trust me that people are reading these lists, and issues do get fixed, for some reason however *you* are not getting your issues resolved. Have you ever stopped to really consider perhaps its not *us* and that you can likely consider some changes on your behalf to work better with our teams who *are* engaged in fixing issues. Your focus is to say you are very well experienced but don't want to hack.. fine but, given your experience you should be able to work even further with devlopers, but that's not happening, why? Because *you* are expecting people to simply read every e-mail rant from you digged into other people's replies. Make this simple, split all of your issues, document them into bug reports for a specific kernel release, help see if you can identify them as regressions, etc. Have you done all this? LUis ^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards 2011-02-23 18:02 ` Luis R. Rodriguez @ 2011-02-23 19:51 ` Peter Stuge 0 siblings, 0 replies; 26+ messages in thread From: Peter Stuge @ 2011-02-23 19:51 UTC (permalink / raw) To: ath9k-devel Luis R. Rodriguez wrote: > > I fear you will not get any further info on this mailing list. I would > > suggest to watch the l-w list and try any patches that are sent there. > > > > They never appear here and there's also no discussion here. Thinking > > about it I actually don't really understand the purpose of this list. > > It's mostly disinforming, in that it detracts from l-w, which seems > > to be the more significant forum for ath9k development. > > Would you stop trolling, really. I'm sorry you feel it is trolling, and not constructive criticism. > I told you what you can do to help with resolving observed issues, > where are your bug reports BTW? I told you a few times by now why I can't really file the kind of bug reports for my issues that I believe you want. If I filed bug reports they would lack any useful information, and as has happened the oneor two times that I tried, they would likely be closed without much investigation or discussion. That's useless, so I'm saving everyone the time until there is something concrete to put into the bug report. What would be useful meanwhile is to discuss particulars of hardware and driver so that I could help find the actual problem. > Trust me that people are reading these lists, I have no doubt about that. What disappoints me is the lack of duplex communication. Open discussion. Two-way. Sharing. There's not much of that. There can be plenty of reasons, but regardless of why, the situation makes me sad and a little bit bitter. :\ > and issues do get fixed, I also have no doubt about that. But from following this list for well over a year it is clear to me that nearly nothing gets fixed *here* which is why I pointed out to Bernard that l-w is a better place to look for patches, and thus probably also discussion, even though this is an ath9k list. You yourself pointed me to l-w, and it matches my experience. > for some reason however *you* are not getting your issues resolved. > Have you ever stopped to really consider perhaps its not *us* and > that you can likely consider some changes on your behalf to work > better with our teams who *are* engaged in fixing issues. I don't have to stop and consider to see why there is not much progress; my issues are a f*ing pain in the ass to work with, especially remotely, and even more so if you're on the vendor side and gagged by NDAs. This is not a reason to throw the fight IMO, and why I am still on this list and still have the card in my machine. If I just wanted to get work done I would have thrown ath9k far f-ing away from my laptop long long ago. > Your focus is to say you are very well experienced but don't want > to hack.. I'm afraid you misunderstood. I never said I don't want to hack, but I said that I don't have time to really dig into the complete driver, and that this means that in order to help nail these issues I will need help from someone who is knowledgeable about both hardware and driver. Your teams seem like they would fit that perfectly, but they would need to spend some time focusing on the problem(s) together with me, and this seems not to be their modus operandi. Jouni is the exception so far. > given your experience you should be able to work even further with > devlopers, but that's not happening, why? It's difficult to say because I don't know what your teams are thinking. The questions I got back from Jouni not long ago I would love to pursue, but unfortunately that PCI problem I mentioned again yesterday is effectively blocking ath9k from even seeing the card. > Because *you* are expecting people to simply read every e-mail rant > from you digged into other people's replies. I try to combine my rants with something useful by now. This list is short on answers in my experience, and I try to not be a part of that problem, even if the answer is just to divert attention elsewhere, in this case to l-w. > Make this simple, split all of your issues, document them into > bug reports for a specific kernel release, help see if you can > identify them as regressions, etc. > > Have you done all this? I tried it once for my disconnect problem with the 5414 card, actually someone else had already opened a bug for that, but it got closed prematurely when you thought the issue had some satisfactory resolution. Basically I gave up on that bug for now because the right kind of questions weren't being asked and because I could not get data out of driver to confirm my speculation which might be required. I have explained at least once, but probably several times by now, why I really can't do all what you ask, for most if not all my issues. In particular I have never had a good system with ath9k, so I can't bisect and I can't consider anything a regression. The PCI thing I could file and if it would help of course I'll do that, but I'd think discussion on this list could be more efficient as a start. That's how it is in many other projects. And there is some already, over in the other thread, so let's go there. //Peter ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2011-03-10 0:40 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <201102230955.35674.bschmidt@techwires.net>
2011-02-23 17:46 ` [ath9k-devel] DMA issues with ar9280 cards Luis R. Rodriguez
2011-02-23 18:12 ` Adrian Chadd
2011-02-23 18:20 ` Adrian Chadd
2011-02-23 18:24 ` Jouni Malinen
2011-02-23 18:40 ` Adrian Chadd
2011-02-23 23:06 ` Jouni Malinen
2011-02-23 20:06 ` Bernhard Schmidt
2011-02-24 9:33 ` Bernhard Schmidt
2011-02-24 18:18 ` Luis R. Rodriguez
2011-02-25 9:37 ` Bernhard Schmidt
2011-02-25 17:12 ` Luis R. Rodriguez
2011-02-26 9:37 ` Bernhard Schmidt
2011-03-10 0:40 ` Felix Fietkau
2011-03-02 14:51 ` Mohammed Shafi
2011-03-04 11:29 ` Bernhard Schmidt
2011-03-04 15:25 ` Mohammed Shafi
2011-03-04 15:29 ` Mohammed Shafi
2011-03-04 17:16 ` Bernhard Schmidt
2011-03-09 9:58 ` Mohammed Shafi
2011-03-09 10:01 ` Mohammed Shafi
2011-03-05 23:49 ` crocket
2011-03-09 10:22 ` Peter Stuge
2011-02-23 15:34 Bernhard Schmidt
2011-02-23 16:22 ` Peter Stuge
2011-02-23 18:02 ` Luis R. Rodriguez
2011-02-23 19:51 ` Peter Stuge
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.