[ath9k-devel] Fix A-MPDU Length
Hi, I have two questions regarding frame aggregation in ath9k: 1. The maximum A-MPDU length I managed to get by saturating the link is around 30 frames. How can I push the length to the theoretical limit which is 64 frames? I am monitoring the (Average AMPDU length) in the* rc_stats*file. 2. How can I fix the A-MPDU size to be able to study the effect of aggregate size? Regards, Ahmad ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Fix A-MPDU Length
Ahmad Showail wrote: I have two questions regarding frame aggregation in ath9k: 1. The maximum A-MPDU length I managed to get by saturating the link is around 30 frames. How can I push the length to the theoretical limit which is 64 frames? I am monitoring the (Average AMPDU length) in the rc_stats file. 2. How can I fix the A-MPDU size to be able to study the effect of aggregate size? The maximum AMPDU size is limited to 4ms (which is a regulatory requirement). Check ath_update_max_aggr_framelen(), ath_lookup_rate() in xmit.c Sujith ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k not connecting to one particular network..
On Mon, Mar 25, 2013 at 07:12:57PM -0700, Linus Torvalds wrote: Nothing sane worked, so I did a brute-force let's just make wpa_supplicant a shell-script that adds the debug fields and then runs the real wpa_supplicant binary with the extra flags. Ah, yes. I remember having done that at some point long time ago when giving up with NM.. ;-) The bugzilla at https://bugzilla.redhat.com/show_bug.cgi?id=927191 now has a wpa_supplicant trace with keys and timestamps for the non-working NetworkManager case too. I see no sane difference. There are several dbus-related setup differences, but then in the actual handshake, afaik they do the same thing, except the non-working one never gets the reply after sending EAPOL-Key 2/4. I dunno. I have no idea what that thing is actually doing. I could not find any real difference in the security negotiation of EAPOL-Key messages 1-2. The point that Robert made in the bugzilla case is interesting, though. I did not notice this at first, but there is indeed a clear difference in the driver interface (nl80211 vs. WEXT) that is being used here. This should not have really caused the issue since both cases used cfg80211 and same set of parameters for association. Anyway, that is the only clear difference.. If you still happen to be at the location with this AP, it could be useful to confirm that this kernel interface difference is indeed the reason by running the manual configuration case with -Dnl80211 added to the wpa_supplicant command line to force nl80211 interface to be used. In addition, you could try to collect the frames exchanged by the success and failure cases using a monitor interface: iw wlan0 interface add mon0 type monitor ifconfig mon0 up dumpcap -i mon0 -w /tmp/capture.pkt And then run the success/failure case. -- Jouni MalinenPGP id EFC895FA ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k not connecting to one particular network..
Jouni Malinen wrote: a clear difference in the driver interface (nl80211 vs. WEXT) that is being used here. This should not have really caused the issue since both cases used cfg80211 and same set of parameters for association. Anyway, that is the only clear difference.. I can confirm that nl80211 and WEXT behave differently on ath5k AR5414. I'll look for repeatability and make captures if you want. //Peter ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Auth Packet TX Delay
ath9k bug created: https://bugzilla.kernel.org/show_bug.cgi?id=55771 On Tue, Mar 26, 2013 at 8:21 AM, Robert Shade robert.sh...@gmail.com wrote: I'll get a bug together, but I wanted to report that even with the patch above (fastcc disabled/cold reset always), it still eventually was unable to change the channel. As soon as that failed, it's back into the state where it never seems to xmit anything in the data queues and can't associate. On Mon, Mar 25, 2013 at 12:45 PM, Adrian Chadd adr...@freebsd.org wrote: One for each please. Adrian On 25 March 2013 09:12, Christian Lamparter chunk...@googlemail.com wrote: On Monday, March 25, 2013 03:23:53 AM Adrian Chadd wrote: Also, would you please make sure you file a bugzilla.kernel.org ticket so this gets tracked? It's good to know that some combination of fast channel change and warm versus cold reset is making things better/worse. And although a cold reset is likely a good thing to _fix_ the problem, it still leaves the underlying DMA/PHY hangs unresolved. But yes, please file a bugzilla ticket so this gets tracked right! Um, do you want a bugreport for ath9k or carl9170 or for both? Regards, Christian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Fix A-MPDU Length
Ahmad Showail wrote: I have two questions regarding frame aggregation in ath9k: 1. The maximum A-MPDU length I managed to get by saturating the link is around 30 frames. How can I push the length to the theoretical limit which is 64 frames? I am monitoring the (Average AMPDU length) in the rc_stats file. 2. How can I fix the A-MPDU size to be able to study the effect of aggregate size? The maximum AMPDU size is limited to 4ms (which is a regulatory requirement). Check ath_update_max_aggr_framelen(), ath_lookup_rate() in xmit.c Sujith ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k not connecting to one particular network..
On Tue, 2013-03-26 at 11:58 +0200, Jouni Malinen wrote: On Mon, Mar 25, 2013 at 07:12:57PM -0700, Linus Torvalds wrote: Nothing sane worked, so I did a brute-force let's just make wpa_supplicant a shell-script that adds the debug fields and then runs the real wpa_supplicant binary with the extra flags. Ah, yes. I remember having done that at some point long time ago when giving up with NM.. ;-) That debugging page should really be updated now that most people are on 0.9. In any case, when developing, to get around systemd + NM respawning the supplicant when it dies, I typically do: mv /usr/sbin/wpa_supplicant / killall -TERM wpa_supplicant /wpa_supplicant -dddtuK and then NM will see the supplicant start again, and reconnect, and you get all the debug logs. You can also poke the supplicant via D-Bus to increase the logging level, but I'm not sure if the D-Bus interface allows exposing the keys. The bugzilla at https://bugzilla.redhat.com/show_bug.cgi?id=927191 now has a wpa_supplicant trace with keys and timestamps for the non-working NetworkManager case too. I see no sane difference. There are several dbus-related setup differences, but then in the actual handshake, afaik they do the same thing, except the non-working one never gets the reply after sending EAPOL-Key 2/4. I dunno. I have no idea what that thing is actually doing. I could not find any real difference in the security negotiation of EAPOL-Key messages 1-2. The point that Robert made in the bugzilla case is interesting, though. I did not notice this at first, but there is indeed a clear difference in the driver interface (nl80211 vs. WEXT) that is being used here. This should not have really caused the issue since both cases used cfg80211 and same set of parameters for association. Anyway, that is the only clear difference.. NM has passed nl80211,wext as the supplicant driver for a year or so now, because we all know nl80211 is the way to go. Besides that, the network config sent to the supplicant does not change at all between nl80211 and wext; you can see the options in /var/log/messages: info Config: added 'ssid' value 'rio grande' info Config: added 'scan_ssid' value '1' info Config: added 'key_mgmt' value 'WPA-PSK' info Config: added 'psk' value 'omitted' info Config: added 'proto' value 'WPA RSN' info Activation (wlan0) Stage 2 of 5 (Device Configure) complete. NM doesn't dump the key, but that feature seems useful and could be added with some huge warnings. If you still happen to be at the location with this AP, it could be useful to confirm that this kernel interface difference is indeed the reason by running the manual configuration case with -Dnl80211 added to the wpa_supplicant command line to force nl80211 interface to be used. This would be a great test; obviously if nl80211 fails to work but wext does work, we need to fix that in the supplicant or kernel. Dan In addition, you could try to collect the frames exchanged by the success and failure cases using a monitor interface: iw wlan0 interface add mon0 type monitor ifconfig mon0 up dumpcap -i mon0 -w /tmp/capture.pkt And then run the success/failure case. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Upgraded to Kernel 3.8.4, ath9k missing
You also need to define CONFIG_ATH_CARDS=y Things like this can usually easily resolved when using make xconfig. 2013/3/26 Angela angela.sch...@wolke7.net I am running 3.5.0-rc2 for a long time, where the ath9k was available in the kernel. I upraded and compiled the v3.8.4 kernel from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git modprobe ath9k FATAL: Module ath9k not found. I noticed that in .config the following is missing: CONFIG_ATH9K_HW=m CONFIG_ATH9K_COMMON=m CONFIG_ATH9K_BTCOEX_SUPPORT=y CONFIG_ATH9K=m CONFIG_ATH9K_PCI=y # CONFIG_ATH9K_AHB is not set # CONFIG_ATH9K_DEBUGFS is not set CONFIG_ATH9K_RATE_CONTROL=y Adding them and afterwards running yes | make oldconfig removes them. Adding them without yes | make oldconfig and compiling removes them also. cd $HOME/dev/kernel/linux-stable CONCURRENCY_LEVEL=`getconf _NPROCESSORS_ONLN` fakeroot make-kpkg --initrd --append-to-version=-mine384 kernel_image kernel_headers What is the best way to get ath9k support ? ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k not connecting to one particular network..
On Tue, Mar 26, 2013 at 2:58 AM, Jouni Malinen jo...@qca.qualcomm.com wrote: If you still happen to be at the location with this AP, it could be useful to confirm that this kernel interface difference is indeed the reason by running the manual configuration case with -Dnl80211 added to the wpa_supplicant command line to force nl80211 interface to be used. Ok, added to the bugzilla. I'm still in the condo, but I'm leaving soon and need to pack up, so this is likely the last thing I can do.. It is indeed the nl80211 part that causes problems, so I guess we're back to an actual ath9k issue. In addition, you could try to collect the frames exchanged by the success and failure cases using a monitor interface: iw wlan0 interface add mon0 type monitor ifconfig mon0 up dumpcap -i mon0 -w /tmp/capture.pkt And then run the success/failure case. Ok, will try to do that too. Linus ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k not connecting to one particular network..
On Tue, Mar 26, 2013 at 08:25:20AM -0700, Linus Torvalds wrote: Ok, added to the bugzilla. I'm still in the condo, but I'm leaving soon and need to pack up, so this is likely the last thing I can do.. It is indeed the nl80211 part that causes problems, so I guess we're back to an actual ath9k issue. Thanks. This is peculiar, but indeed pretty clear on the issue being triggered by use of nl80211 instead of WEXT regardless of what the actual issue is. I haven't used wpa_supplicant v1.0-rc3 pretty much at all myself and there has been quite a few changes in nl80211 interaction since then. Anyway, this should give a good test case with the current kernel and that somewhat older version with nl80211 implementation in wpa_supplicant. In addition, you could try to collect the frames exchanged by the success and failure cases using a monitor interface: iw wlan0 interface add mon0 type monitor ifconfig mon0 up dumpcap -i mon0 -w /tmp/capture.pkt And then run the success/failure case. Ok, will try to do that too. If you'll get a chance to do that, it would be quite helpful since it could make it easier to try to reproduce this if there is indeed something special about that AP behavior that allows the issue to show up but does not show up in the wpa_supplicant debug log. -- Jouni MalinenPGP id EFC895FA ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Auth Packet TX Delay
carl9170 bug created here: https://bugzilla.kernel.org/show_bug.cgi?id=55751 On Mon, Mar 25, 2013 at 09:45:48AM -0700, Adrian Chadd wrote: One for each please. Adrian On 25 March 2013 09:12, Christian Lamparter chunk...@googlemail.com wrote: On Monday, March 25, 2013 03:23:53 AM Adrian Chadd wrote: Also, would you please make sure you file a bugzilla.kernel.org ticket so this gets tracked? It's good to know that some combination of fast channel change and warm versus cold reset is making things better/worse. And although a cold reset is likely a good thing to _fix_ the problem, it still leaves the underlying DMA/PHY hangs unresolved. But yes, please file a bugzilla ticket so this gets tracked right! Um, do you want a bugreport for ath9k or carl9170 or for both? Regards, Christian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Auth Packet TX Delay
On Tue, Mar 26, 2013 at 12:28 PM, Adrian Chadd adr...@freebsd.org wrote: On 26 March 2013 05:21, Robert Shade robert.sh...@gmail.com wrote: I'll get a bug together, but I wanted to report that even with the patch above (fastcc disabled/cold reset always), it still eventually was unable to change the channel. As soon as that failed, it's back into the state where it never seems to xmit anything in the data queues and can't associate. Even after a cold reset? Yes, which is why I'm curious about the start/stop queues calls. It looks to my (untrained) eye that it's simply not processing the data queue. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Auth Packet TX Delay
On 26 March 2013 09:29, Robert Shade robert.sh...@gmail.com wrote: Even after a cold reset? Yes, which is why I'm curious about the start/stop queues calls. It looks to my (untrained) eye that it's simply not processing the data queue. Well if there's anything in the data queue once you've reset the chip (ie, the whole no loss reset path for doing resets when you're doing a scan or recovering from a hung chip) you need to re-program the queue. For the pre-AR9380 chips its easy - for each TXQ: * update axq_link to the be the link field in the last descriptor in the last frame; * push the first descriptor in the first frame into the QCU TxDP address; * set TxE for that queue. For the AR9380 and later chips its a little more complicated because of how the FIFO management works. Felix knows more about this in ath9k; I'm doing something different in FreeBSD. But the basics are the same - you need to walk the FIFO frame list and push the head of each FIFO entry back into the FIFO, then start TX. adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Auth Packet TX Delay
... and the odd thing here is that during scanning, it should be flushing the queues entirely so any new frame being transmitted _SHOULD_ result in: * TxDP for that queue being written (either FIFO or otherwise); * TxE for that queue being set. So unless the queue is full already and isn't being drained, I'm kinda curious as to why TX isn't starting. Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Auth Packet TX Delay
On 03/26/2013 10:33 AM, Adrian Chadd wrote: Right. Well, when you reset the FIFO chances are you should walk said FIFO queue in the TXQ (not the pending frames, the hw frames) and requeue each to the hardware. What I am doing in my EDMA restart routine in FreeBSD: * (assume TX is stopped, chip is reset, the completed frames are already removed from the FIFO queue in the TXQ); * save the old FIFO count * blank the FIFO count * walk the FIFO list (NOT the pending list), pushing head pointers back into the FIFO - and this will bump the FIFO counter by one each time; * when I've finished that, compare the FIFO count to the old FIFO count - they should match. I've not looked at the ath9k code in too much depth lately as I've been more interested in getting FreeBSD's EDMA code finished (and I think it is, woo!); so if you give me an hour or two I'll go do another code review and see what pops up. Ok, I'm happy to test patches. Last we tried, we could reproduce the problem very often using lots of stations (32, I think) sending 64kbps or so UDP traffic through an attenuator as we ramp up the attenuation in 10db steps... Thanks, Ben -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Upgraded to Kernel 3.8.4, ath9k missing
Hello Holger Thanks for pushing me in the right direction. What struck me, was that the config's got deleted every time. Menuconfig is terrible, used xconfig and found it immediately, thanks for the tip. Cheers Angela From: Holger Schurig [mailto:holgerschu...@gmail.com] Sent: Tuesday, 26 March, 2013 15:41 To: Angela Cc: ath9k-devel Subject: Re: [ath9k-devel] Upgraded to Kernel 3.8.4, ath9k missing You also need to define CONFIG_ATH_CARDS=y Things like this can usually easily resolved when using make xconfig. 2013/3/26 Angela angela.sch...@wolke7.net I am running 3.5.0-rc2 for a long time, where the ath9k was available in the kernel. I upraded and compiled the v3.8.4 kernel from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git modprobe ath9k FATAL: Module ath9k not found. I noticed that in .config the following is missing: CONFIG_ATH9K_HW=m CONFIG_ATH9K_COMMON=m CONFIG_ATH9K_BTCOEX_SUPPORT=y CONFIG_ATH9K=m CONFIG_ATH9K_PCI=y # CONFIG_ATH9K_AHB is not set # CONFIG_ATH9K_DEBUGFS is not set CONFIG_ATH9K_RATE_CONTROL=y Adding them and afterwards running yes | make oldconfig removes them. Adding them without yes | make oldconfig and compiling removes them also. cd $HOME/dev/kernel/linux-stable CONCURRENCY_LEVEL=`getconf _NPROCESSORS_ONLN` fakeroot make-kpkg --initrd --append-to-version=-mine384 kernel_image kernel_headers What is the best way to get ath9k support ? ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k not connecting to one particular network..
Adding linux-wireless, not sure if many people read this list. Luis On Tue, Mar 26, 2013 at 8:40 AM, Jouni Malinen jo...@qca.qualcomm.com wrote: On Tue, Mar 26, 2013 at 08:25:20AM -0700, Linus Torvalds wrote: Ok, added to the bugzilla. I'm still in the condo, but I'm leaving soon and need to pack up, so this is likely the last thing I can do.. It is indeed the nl80211 part that causes problems, so I guess we're back to an actual ath9k issue. Thanks. This is peculiar, but indeed pretty clear on the issue being triggered by use of nl80211 instead of WEXT regardless of what the actual issue is. I haven't used wpa_supplicant v1.0-rc3 pretty much at all myself and there has been quite a few changes in nl80211 interaction since then. Anyway, this should give a good test case with the current kernel and that somewhat older version with nl80211 implementation in wpa_supplicant. In addition, you could try to collect the frames exchanged by the success and failure cases using a monitor interface: iw wlan0 interface add mon0 type monitor ifconfig mon0 up dumpcap -i mon0 -w /tmp/capture.pkt And then run the success/failure case. Ok, will try to do that too. If you'll get a chance to do that, it would be quite helpful since it could make it easier to try to reproduce this if there is indeed something special about that AP behavior that allows the issue to show up but does not show up in the wpa_supplicant debug log. -- Jouni MalinenPGP id EFC895FA ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Auth Packet TX Delay
On Tue, Mar 26, 2013 at 1:13 PM, Ben Greear gree...@candelatech.com wrote: Can you cat out the /debug/ieee80211/wiphy0/ath9k/xmit file when it gets in this hung state? I saw issues where the xmit queues got hung in our AR9380 NIC systems and ended up adding an ugly bit of cleanup/reset logic to get them working again... Dumps are attached on to the bug. I remember being hopeful when reading your thread that we stumbled on the same issue, but the symptoms don't look the same to me because pending-frames goes back to 0 in my case. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Auth Packet TX Delay
Think I found it: In ath_reset_internal, before we reset, we call
ath_prepare_reset, which calls ath9k_hw_disable_interrupts. If the
channel change fails, we never call ath_complete_reset, which calls
ath9k_hw_enable_interrupts.
ath9k_hw_{enable|disable}_interrupts calls definitely needs to be
balanced. Looking at an old log, IER never gets re-enabled after the
channel set failure.
Any suggestions on the proper cleanup? Could we just call
ath_complete_reset anyway? Some sort of special handling?
On Tue, Mar 26, 2013 at 8:55 PM, Robert Shade robert.sh...@gmail.com wrote:
On Tue, Mar 26, 2013 at 1:13 PM, Ben Greear gree...@candelatech.com wrote:
Can you cat out the /debug/ieee80211/wiphy0/ath9k/xmit
file when it gets in this hung state? I saw issues where
the xmit queues got hung in our AR9380 NIC systems and
ended up adding an ugly bit of cleanup/reset logic to
get them working again...
Dumps are attached on to the bug. I remember being hopeful when
reading your thread that we stumbled on the same issue, but the
symptoms don't look the same to me because pending-frames goes back to
0 in my case.
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] WiFi Failure with AR9280
On 25/3/2013 12:39 AM, Felix Fietkau wrote: On 2013-03-24 5:26 PM, Pannirselvam Kanagaratnam wrote: Hello, My WiFi connection drops while running the AR9280 on a Freescale MPC8315E platform in AP mode with hostapd. I get the following error within 15 seconds and the WiFi connection drops. However, I do not observe any issues when using the AR9382. Can you let me know what could be causing this and if there is a workaround for this. I am using Compat-Wireless-3.5.4.1. I suggest updating to a more recent version of compat-wireless - 3.5.4.1 is quite old. If a similar failure still occurs there, make sure you turn on CONFIG_KALLSYMS so that the trace is not just a long list of meaningless numbers. - Felix Here are my logs with Compat 3.9-rc2 and CONFIG_KALLSYMS enabled. ath: phy0: Failed to stop TX DMA, queues=0x004! ath: phy0: DMA failed to stop in 10 ms AR_CR=0x0024 AR_DIAG_SW=0x4220 DMADBG_7=0x62c0 ath: phy0: Could not stop RX, we could be confusing the DMA engine when we start RX up [ cut here ] Badness at /build/compat-wireless-3.9-rc2-2-su/drivers/net/wireless/ath/ath9k/recv.c:487 NIP: c9b72eec LR: c9b72ee0 CTR: c01bc900 REGS: c6c63e30 TRAP: 0700 Not tainted (2.6.35) MSR: 00029032 EE,ME,CE,IR,DR CR: 22002022 XER: 2000 TASK = c7859360[930] 'phy0' THREAD: c6c62000 GPR00: 0001 c6c63ee0 c7859360 004c 5665 c01b9e70 4000 GPR08: c9b9 5665 c046ad78 22002082 07ff9000 GPR16: 000a GPR24: c6c66b4c c6c68030 c6c68010 c6c65740 NIP [c9b72eec] ath_stoprecv+0x13c/0x154 [ath9k] LR [c9b72ee0] ath_stoprecv+0x130/0x154 [ath9k] Call Trace: [c6c63ee0] [c9b72ee0] ath_stoprecv+0x130/0x154 [ath9k] (unreliable) [c6c63f10] [c9b6ec20] ath_prepare_reset+0x54/0x90 [ath9k] [c6c63f30] [c9b6ee90] ath_reset_internal+0x6c/0x220 [ath9k] [c6c63f60] [c9b6f948] ath_reset+0x28/0x9c [ath9k] [c6c63f80] [c0039398] worker_thread+0x108/0x1b0 [c6c63fc0] [c003d338] kthread+0x78/0x7c [c6c63ff0] [c0010f08] kernel_thread+0x4c/0x68 Instruction dump: 2f80 419eff74 809f0888 3c60c9b8 3ca0c9b8 38637194 38a572c8 38840020 4bec2125 3d20c9b9 88099475 6801 0f00 2f80 419eff40 3801 ath: phy0: Failed to stop TX DMA, queues=0x004! ath: phy0: DMA failed to stop in 10 ms AR_CR=0x0024 AR_DIAG_SW=0x4220 DMADBG_7=0x6040 ath: phy0: Could not stop RX, we could be confusing the DMA engine when we start RX up Regards, Pannir ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
