Bug 61111

Summary: [ath9k_htc] device overheating and failure on TP-Link TL-WN821N v3 (Atheros AR7010+AR9287)
Product: Drivers Reporter: Christian Stadelmann (dev)
Component: network-wirelessAssignee: drivers_network-wireless (drivers_network-wireless)
Status: NEW ---    
Severity: normal CC: ath9k-devel, ciberguerra, jeremy, linux, linville, nemesis, pagea
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 3.0 to 3.12 Subsystem:
Regression: No Bisected commit-id:
Attachments: $ iw phy0 info
output from dmesg. At about 2190 the device overheats, at around 2286 I disconnected the device, at 2292 I connected it again.
scan.diff
Output of # iw dev wlp0s26u1u2 scan dump
A complete dmesg with stock ath9k kernel module (not modified)
logging output for described problem (out of SW-IOMMU space) (VERY big file)
dmesg from second USB root hub
What I've tried to compile/run the ath9k module with printk output
systemd journal from suspend+freeze problem
htc_7010.fw
dmesg with new firmware
dmesg with 3.12.6-300 kernel with new router (AVM Fritz!Box 7360)
fw panic report
dmesg output on 3.16.0-28-generic connected to Netgear WNDR3400
dmesg linux 4.0.0-rc5 with new driver

Description Christian Stadelmann 2013-09-10 09:05:26 UTC
Created attachment 107981 [details]
$ iw phy0 info

I am running Fedora 19 x86_64 having a problem with TP-Link TL-WN821N v3 (Atheros AR7010+AR9287, USB Device ID: 0cf3:7015). This device is overheating every time I transfer much data over WLAN (>60°C) and then the connection drops or times out. Sometimes I even get system freezes or kernel panics I can't read. Seems like a power management issue to me.

As a workaround I reduced the TX power from 100mW (20dBm) to 1dBm or 0dBm (`iw dev wlp0s29u1u2 set txpower fixed 100` or `iwconfig wlp0s29u1u2 txpower 0`) and it takes much longer to overheat when downloading huge files (transfer rate does not change notably, around 1…3MiB/s) :
With TX power 20dBm I can transfer about 50MiB before device overheats,
with TX power 0dBm I can transfer about 1GiB before the device overheats.

As a result of the device being unresponsive suspend-to-ram sometimes does not work (see https://bugzilla.redhat.com/show_bug.cgi?id=997608 for details)
Comment 1 Oleksij Rempel 2013-11-08 18:37:17 UTC
Is this still reproducable?
Comment 2 Christian Stadelmann 2013-11-10 17:41:41 UTC
Created attachment 114101 [details]
output from dmesg. At about 2190 the device overheats, at around 2286 I disconnected the device, at 2292 I connected it again.

Yes, bug still present on 3.11.7 kernel (Fedora 20 Alpha/Beta).
Comment 3 Oleksij Rempel 2013-11-10 18:37:20 UTC
Created attachment 114121 [details]
scan.diff

can you please do some testing for me.

I have same adapter, but i can't reproduce this issue. Not sure that temperature triggering it. Even with 70C this adapter working for me.

I assume it can be combination of different bugs.
One of them is usb. Channel scan will do intensive IO over usb. On some controllers channel switch will take 1 second. It mean, that complete channel scan can take 30 seconds. The down/up speed will dramatically drop too.

Attached patch will do some printks for scan sequence. Please, provide complete dmesg. Every thing what happened before 2190 is interesting too.

Second part of bug can be your AP. I would like to know as match as possible about it: model, firmware. Output of "iw dev wlan0 scan dump"
Comment 4 Christian Stadelmann 2013-11-26 17:28:28 UTC
Created attachment 116221 [details]
Output of # iw dev wlp0s26u1u2 scan dump
Comment 5 Christian Stadelmann 2013-11-26 17:30:46 UTC
Created attachment 116231 [details]
A complete dmesg with stock ath9k kernel module (not modified)
Comment 6 Christian Stadelmann 2013-11-26 17:35:35 UTC
Created attachment 116241 [details]
logging output for described problem (out of SW-IOMMU space) (VERY big file)

In some rare cases I get this error message:
Nov 25 21:40:33 chstpc-2 kernel: DMA: Out of SW-IOMMU space for 16 bytes at device 0000:00:1d.0
(same with 20 instead of 16 bytes) printed several thousand times per second to system log. Got a 127MB (!) log file from just about 7 minutes…
Comment 7 Christian Stadelmann 2013-11-26 17:46:46 UTC
Created attachment 116251 [details]
dmesg from second USB root hub

I usually have few USB devices connected (keyboard, mouse, WLAN stick). This bug occurs for both of my USB root hubs (physically distinct root hubs). This log file is from the second USB root hub.
Comment 8 Christian Stadelmann 2013-11-26 17:48:15 UTC
Created attachment 116261 [details]
What I've tried to compile/run the ath9k module with printk output

I tried to compile that module but got some problems (mailed to fedora-kernel list since I think it's related to Fedora-specific code). Don't know what I've done wrong.
Comment 9 Oleksij Rempel 2013-11-26 18:09:14 UTC
Your access point is DIR-615 H1?
http://wikidevi.com/wiki/D-Link_DIR-615_rev_H1

what is you firmware version? Is it original d-link or openwrt FW?
Comment 10 Christian Stadelmann 2013-11-26 18:29:33 UTC
Original DIR-615, Hardware: Hx, Firmware: 8.03. No OpenWRT or something else, just original D-Link firmware.
Comment 11 Christian Stadelmann 2013-11-26 18:37:12 UTC
Ok, sorry. Firmware says it is Hardware revision Hx.
According to the firmware itself 8.03 is the latest version but D-Link website says 8.05b05 is the latest version: http://www.dlink.com/de/de/support/product/dir-615-wireless-n-300-router?revision=de_revh
Seems like H1 is the only Hx hardware revision.
Comment 12 Oleksij Rempel 2013-12-01 13:39:09 UTC
Thank you for info,
i found same router and now i'm able to reproduce this issue.
It is atho9k-htc-firmware related problem, so it will take some time.

Just a tip: use opewrt or replace this router... it is really bad.
Comment 13 Christian Stadelmann 2013-12-01 20:45:50 UTC
Ok, were gonna replace it in 1…3 months. Thanks for your help!
Comment 14 Christian Stadelmann 2013-12-13 13:37:24 UTC
Created attachment 118281 [details]
systemd journal from suspend+freeze problem

(Don't know if that helps)

Today I suspended my PC with this device attached. The connection dropped (freezed?) some seconds before I suspended my PC. Resuming (wake-up from suspend) took several seconds (30?; normally less than 5 on the same hardware/software) with the PC being unresponsive. I only got a black screen with a mouse cursor (the last frame I see before suspending). Mouse and keyboard input (including switching to tty) didn't work. According to the attached logs device and kernel failed to establish a connection.

I've seen this several times before, it seems to happen only under some circumstances when the connection dropped right before I suspend my PC.
Comment 15 Oleksij Rempel 2013-12-14 21:28:17 UTC
Created attachment 118481 [details]
htc_7010.fw

Hi,
can you please test this firmware? I add one workaround to reset usb interface if firmware crashed. This should reinit driver.
I'm still not able to find reason for firmware crash. But for now, it is better then nothing.
Comment 16 Christian Stadelmann 2013-12-19 17:54:56 UTC
Created attachment 119081 [details]
dmesg with new firmware

Thanks.
When the connection drops it still drops until I disconnect and reconnect the USB device manually. The USB device still gets warm when dropping connection (don't know whether heat causes drop or vice versa).
It looks like the new firmware causes to try reconnecting (in a loop) until it worked. This seems to have changed.
Comment 17 Oleksij Rempel 2013-12-19 18:20:31 UTC
According to my measurement, hottest is the WiFi chip and it is about 60C. It is not too hot.
On my tests not the heat cause FW panic, instead it is bad connection or concurrent download. It can run one day with 15MB/s without any problems, but if there is one more station running with netperf, then it will take max one hour to reproduce this crash.
If you use new firmware and still need to unplug usb adapter, then you have probably other issue.
Comment 18 Christian Stadelmann 2013-12-19 18:23:18 UTC
Really looks like I've a different issue since it sometimes takes just 1 or 2 minutes to make the firmware crash.
Comment 19 Christian Stadelmann 2014-01-17 16:52:35 UTC
Created attachment 122441 [details]
dmesg with 3.12.6-300 kernel with new router (AVM Fritz!Box 7360)

I'm still getting connection drops even with a new (better) router (AVM Fritz!Box 7360).
Comment 20 Oleksij Rempel 2014-01-27 08:00:09 UTC
One user reported on launchpad that, setting nohwcrypt and reducing tx power solve his problems. Can you please run some longterm tests to check if only one of this options will do the trick?
Comment 21 Christian Stadelmann 2014-01-27 18:41:08 UTC
Hi

Yeah, I read that on http://forum.ubuntuusers.de/topic/12-04-ath9k-htc-tp-link-tl-wn821n-v3-802-11n-3/?highlight=ath9k#post-6238742 (german ubuntu forum) some time ago. It didn't fix the problem. But both made the problem less worse.

Since I got the new router connection drops only when using >2MB/s for several minutes.

btw: I ran into some kernel bug yesterday, see https://bugzilla.redhat.com/show_bug.cgi?id=990955 for details.
Comment 22 Oleksij Rempel 2014-01-27 18:53:32 UTC
Arr...

i already heard about this bug. If you use self compiled kernel please try this workaround:

diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_m
index 228549a..12a9e10 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1314,6 +1314,7 @@ static void ath9k_htc_sta_rc_update(struct ieee80211_hw *hw,
        struct ath9k_htc_priv *priv = hw->priv;
        struct ath_common *common = ath9k_hw_common(priv->ah);
        struct ath9k_htc_target_rate trate;
+return;
 
        mutex_lock(&priv->mutex);
        ath9k_htc_ps_wakeup(priv);


If it will fix it for you, it will be good to continue on initial bug. The note about >2MB/s is interesting. Can you force rate controller to trigger this bug?
Comment 23 Oleksij Rempel 2014-01-29 19:44:57 UTC
Created attachment 123801 [details]
fw panic report

This patch will provide us some information if FW crashed.
Comment 24 Jeremy Sanders 2014-07-19 19:38:59 UTC
I'm seeing this problem too with Ubuntu Trusty (TL-WN821N v3). What I've found is that crash is very frequent if I enable wireless N on my router (FRITZ!Box 7240), but rather infrequent if I disable it. Running VNC or X over my connection seems a good way to break things. If I can, I'll try to include this patch in my kernel...

Kernel version is 3.13.0-32-generic on i686
Comment 25 Alden S. Page 2014-12-30 15:29:35 UTC
Created attachment 162121 [details]
dmesg output on 3.16.0-28-generic connected to Netgear WNDR3400

This device is still problematic with Ubuntu 14.04 (kernel 3.16.0-28-generic x86_64). I will attach my entire dmesg output, but here is the debug print statement:
...
[  225.195225] usb 2-1: reset high-speed USB device number 2 using ehci-pci
[  473.306080] usb 2-1: reset high-speed USB device number 2 using ehci-pci
[  564.675344] usb 1-2: ath: firmware panic! exccause: 0x0000000d; pc: 0x0090e11c; badvaddr: 0x10ff4038.
[  601.487338] ath: phy0: Unable to remove station entry for: c4:3d:c7:65:0f:36

After this, the only thing that will bring back the device is restarting the whole machine. I have had this happen while just browsing the internet, not downloading anything particularly substantial. The device runs very hot.

The workaround patch is out of date and rejected by the `patch` utility.
Comment 26 Oleksij Rempel 2014-12-30 16:01:00 UTC
You are using really old FW. Latest FW should reset device if panic will happen.
https://github.com/olerem/ath9k-htc-firmware-blob
Comment 27 agapito 2015-03-20 15:25:47 UTC
This bug is still present in 3.19.2 kernel, using 1.4 firmware. Downloading a big file or using a torrent client = wifi dies, and I have to replug the device. Reducing txpower doesn´t help here.
Comment 28 Oleksij Rempel 2015-03-21 09:27:57 UTC
Please send complete dmesg
Comment 29 agapito 2015-03-21 11:05:41 UTC
[  319.619562] usb 3-7: new high-speed USB device number 11 using xhci_hcd
[  319.793771] usb 3-7: ath9k_htc: Firmware htc_7010.fw requested
[  319.893888] usb 3-7: ath9k_htc: Transferred FW: htc_7010.fw, size: 72812
[  319.963800] ath9k_htc 3-7:1.0: ath9k_htc: HTC initialized with 45 credits
[  320.186770] ath9k_htc 3-7:1.0: ath9k_htc: FW Version: 1.4
[  320.186772] ath: EEPROM regdomain: 0x809c
[  320.186773] ath: EEPROM indicates we should expect a country code
[  320.186773] ath: doing EEPROM country->regdmn map search
[  320.186774] ath: country maps to regdmn code: 0x52
[  320.186775] ath: Country alpha2 being used: CN
[  320.186775] ath: Regpair used: 0x52
[  320.190121] ieee80211 phy1: Atheros AR9287 Rev:2
[  320.190214] cfg80211: Calling CRDA for country: CN
[  320.190762] ath9k_htc 3-7:1.0 wlp0s20u7: renamed from wlan0
[  320.215948] cfg80211: Current regulatory domain intersected:
[  320.215950] cfg80211:  DFS Master region: unset
[  320.215951] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[  320.215953] cfg80211:   (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[  320.215955] cfg80211:   (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2300 mBm), (N/A)
[  320.215956] cfg80211:   (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
[  320.215958] cfg80211:   (57240000 KHz - 59400000 KHz @ 2160000 KHz), (N/A, 2800 mBm), (N/A)
[  320.215959] cfg80211:   (59400000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A)
[  320.215960] cfg80211:   (63720000 KHz - 65880000 KHz @ 2160000 KHz), (N/A, 2800 mBm), (N/A)
[  345.432995] wlp0s20u7: authenticate with xx:xx:xx:xx:xx:xx
[  345.888729] wlp0s20u7: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
[  345.890376] wlp0s20u7: authenticated
[  345.890779] wlp0s20u7: associate with xx:xx:xx:xx:xx:xx (try 1/3)
[  345.894413] wlp0s20u7: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x411 status=0 aid=2)
[  345.904215] wlp0s20u7: associated
[ 1405.426571] usb 3-7: USB disconnect, device number 11
[ 1405.448532] wlp0s20u7: deauthenticating from xx:xx:xx:xx:xx:xx by local choice (Reason: 3=DEAUTH_LEAVING)
[ 1405.704361] ath: phy1: Chip reset failed
[ 1405.704364] ath: phy1: Unable to reset channel (2412 Mhz) reset status -22
[ 1405.704365] ath: phy1: Unable to set channel
[ 1405.804959] ath: phy1: Chip reset failed
[ 1405.804962] ath: phy1: Unable to reset channel (2412 Mhz) reset status -22
[ 1405.804963] ath: phy1: Unable to set channel
[ 1405.916090] ath: phy1: Failed to wakeup in 500us
Comment 30 Oleksij Rempel 2015-03-21 11:21:12 UTC
_complete_ dmesg?
Comment 31 agapito 2015-03-21 12:16:25 UTC
No more messages, wifi stick just dies in silence, I can't do ping to my router, and the only solution is replug it into usb port. After 5,10 or 20 minutes i lost my wifi again using a torrent client.
Comment 32 Oleksij Rempel 2015-03-21 12:35:13 UTC
If there are no messages,then there is no way to fix it within kernel driver.
This message means, there is no usb connection with device.
[ 1405.426571] usb 3-7: USB disconnect, device number 11
From kernel point of view, this device is just unplugged.

The fact that there is no error message from FW, i would assume FW didn't detected any error, even watchdog didn't triggered restart.

I don't know what exactly happened. And without access to this HW, i wont be able to find it out.
Comment 33 Oleksij Rempel 2015-03-21 13:33:38 UTC
@agapito
Beside, one of dmesg provided here do include "firmware panic!" message. This means, you have completely different bug.
Comment 34 Christian Stadelmann 2015-03-21 13:54:33 UTC
@Oleksij Rempel: Should I send you my device? I don't need it any more since It connection drops all the time and I installed an ethernet cable instead. Just send your postal address to my email address.
Comment 35 agapito 2015-03-21 16:00:51 UTC
Is the same bug. I have the same device (TP-Link TL-WN821N v3 ) and have the same symptoms of the first message. I had firmware panics with the older firmware (1.3) I don´t know if is a firmware or a driver problem, but this bug is still present.
Comment 36 agapito 2015-03-21 16:14:57 UTC
I put firmware 1.3 again and...


[  359.417849] usb 3-7: ath: firmware panic! exccause: 0x0000000d; pc: 0x0090e11c; badvaddr: 0x10ff4038.
[  392.722319] ath: phy0: Unable to remove station entry for: XX:XX:XX:XX:XX:XX
Comment 37 Oleksij Rempel 2015-03-21 18:14:44 UTC
@agapito,

since it is hard from you to get some information and i have no magic power, i'll describe you the problem:

- ar7010 + *, is a SoC (CPU) with PCIe bridge. Some times FW will get error on PCIe access.
- FW 1.3 triggered error in this case, send panic notification to the host and waited for new firmware
- FW 1.4 triggered error, send panic notification and reseted device.

In this way, recovery time for this error was reduced in FW 1.4. In my test PC it need less then 10 seconds to come back.

Now to the next problem. Some usb host controllers are not lucky about this kind of reset. At least about reset on firmware load to update usb settings (this is why we are not doing this kind of resetes).
I have small collection of usb controllers, with one problematic controller. On this controller didn't worked reset on FW load, but worked reset on error.

I'm sure other controllers may/will have different issues, this is why i usually need complete dmesg to get more info about complete system.

Some of bugs which i have seen, was reproduced only on AMD SB700/SB800/Hudson-2/3 usb controller. Some are specific to modifications of ar7010 board design.
Comment 38 Oleksij Rempel 2015-03-28 14:49:08 UTC
@all

can you please test latest firmware form here:
https://github.com/olerem/ath9k-htc-firmware-blob

i added short delay to interrupt handler of pci bus. Currently this FW passed 3 hours without triggering pci bug.
Comment 39 Ryan Underwood 2015-03-28 16:23:07 UTC
Should the FW version still show 1.4 when loaded by kernel?
Comment 40 Oleksij Rempel 2015-03-28 16:43:44 UTC
yes
Comment 41 Ryan Underwood 2015-03-28 22:09:47 UTC
It's hard to tell that I'm using the right firmware (I copied/overwrote in /lib/firmware, and did not find other htc_7010.fw).  It looks like an improvement though, since the device now resets itself instead of just locking up and requiring powercycle, but this is still unusable.

Here's the log of such an event:

Mar 28 17:00:46 iqrouter kernel: [20921.936700] usb 2-4: USB disconnect, device number 3
Mar 28 17:00:46 iqrouter kernel: [20922.078812] wlan_br0: port 1(wlan_priv0) entered disabled state
Mar 28 17:00:46 iqrouter kernel: [20922.080127] device wlan_priv0 left promiscuous mode
Mar 28 17:00:46 iqrouter kernel: [20922.081401] wlan_br0: port 1(wlan_priv0) entered disabled state
Mar 28 17:00:46 iqrouter kernel: [20922.284979] usb 2-4: ath9k_htc: USB layer deinitialized
Mar 28 17:00:46 iqrouter kernel: [20922.528486] usb 2-4: new high-speed USB device number 5 using ehci-pci
Mar 28 17:00:46 iqrouter kernel: [20922.666044] usb 2-4: New USB device found, idVendor=0cf3, idProduct=7015
Mar 28 17:00:46 iqrouter kernel: [20922.667740] usb 2-4: New USB device strings: Mfr=16, Product=32, SerialNumber=48
Mar 28 17:00:46 iqrouter kernel: [20922.669480] usb 2-4: Product: USB WLAN
Mar 28 17:00:46 iqrouter kernel: [20922.671144] usb 2-4: Manufacturer: ATHEROS
Mar 28 17:00:46 iqrouter kernel: [20922.672775] usb 2-4: SerialNumber: 12345
Mar 28 17:00:46 iqrouter kernel: [20922.675300] usb 2-4: ath9k_htc: Firmware htc_7010.fw requested
Mar 28 17:00:46 iqrouter kernel: [20922.677448] usb 2-4: firmware: direct-loading firmware htc_7010.fw
Mar 28 17:00:47 iqrouter kernel: [20922.787590] usb 2-4: ath9k_htc: Transferred FW: htc_7010.fw, size: 72812
Mar 28 17:00:47 iqrouter kernel: [20922.857674] ath9k_htc 2-4:1.0: ath9k_htc: HTC initialized with 45 credits
Mar 28 17:00:47 iqrouter kernel: [20923.060373] ath9k_htc 2-4:1.0: ath9k_htc: FW Version: 1.4
Mar 28 17:00:47 iqrouter kernel: [20923.074220] ieee80211 phy2: Atheros AR9287 Rev:2
Mar 28 17:00:47 iqrouter kernel: <30>[20923.092259] systemd-udevd[24802]: renamed network interface wlan0 to wlan_priv0
Mar 28 17:00:47 iqrouter kernel: [20923.330932] IPv6: ADDRCONF(NETDEV_UP): wlan_priv0: link is not ready
Mar 28 17:00:47 iqrouter kernel: [20923.332785] cfg80211: Calling CRDA for country: CN
Mar 28 17:00:47 iqrouter kernel: [20923.344873] cfg80211: Current regulatory domain intersected:
Mar 28 17:00:47 iqrouter kernel: [20923.346571] cfg80211:  DFS Master region: FCC
Mar 28 17:00:47 iqrouter kernel: [20923.346605] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
Mar 28 17:00:47 iqrouter kernel: [20923.350002] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
Mar 28 17:00:47 iqrouter kernel: [20923.351777] cfg80211:   (5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A, 1700 mBm), (N/A)
Mar 28 17:00:47 iqrouter kernel: [20923.353567] cfg80211:   (5250000 KHz - 5330000 KHz @ 80000 KHz), (N/A, 2300 mBm), (0 s)
Mar 28 17:00:47 iqrouter kernel: [20923.355341] cfg80211:   (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 3000 mBm), (N/A)
Mar 28 17:00:47 iqrouter kernel: [20923.357197] cfg80211:   (57240000 KHz - 59400000 KHz @ 2160000 KHz), (N/A, 2800 mBm), (N/A)
Mar 28 17:00:47 iqrouter kernel: [20923.358971] cfg80211:   (59400000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A)
Comment 42 Ryan Underwood 2015-03-28 22:12:07 UTC
Bus 001 Device 003: ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287]
Comment 43 agapito 2015-03-29 05:46:56 UTC
Still broken:


Bus 001 Device 011: ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 / TL-WN822N v2 802.11n [Atheros AR7010+AR9287]


[    5.495098] usb 1-1: ath9k_htc: Transferred FW: htc_7010.fw, size: 72812
[    5.564993] ath9k_htc 1-1:1.0: ath9k_htc: HTC initialized with 45 credits
[    5.787839] ath9k_htc 1-1:1.0: ath9k_htc: FW Version: 1.4
[    5.787841] ath: EEPROM regdomain: 0x809c
[    5.787841] ath: EEPROM indicates we should expect a country code
[    5.787842] ath: doing EEPROM country->regdmn map search
[    5.787843] ath: country maps to regdmn code: 0x52
[    5.787843] ath: Country alpha2 being used: CN
[    5.787844] ath: Regpair used: 0x52
[    5.792536] ieee80211 phy0: Atheros AR9287 Rev:2
[    5.792541] cfg80211: Calling CRDA for country: CN
[    5.793174] ath9k_htc 1-1:1.0 wlp0s20u1: renamed from wlan0
[    5.825473] cfg80211: Current regulatory domain intersected:
[    5.825474] cfg80211:  DFS Master region: unset
[    5.825475] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[    5.825477] cfg80211:   (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[    5.825478] cfg80211:   (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2300 mBm), (N/A)
[    5.825479] cfg80211:   (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
[    5.825479] cfg80211:   (57240000 KHz - 59400000 KHz @ 2160000 KHz), (N/A, 2800 mBm), (N/A)
[    5.825480] cfg80211:   (59400000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A)
[    5.825481] cfg80211:   (63720000 KHz - 65880000 KHz @ 2160000 KHz), (N/A, 2800 mBm), (N/A)
[   39.597028] wlp0s20u1: authenticate with xx:xx:xx:xx:xx:xx
[   40.056659] wlp0s20u1: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
[   40.058318] wlp0s20u1: authenticated
[   40.058539] wlp0s20u1: associate with xx:xx:xx:xx:xx:xx (try 1/3)
[   40.066735] wlp0s20u1: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x411 status=0 aid=2)
[   40.076642] wlp0s20u1: associated


[  214.348082] usb 1-1: ath: firmware panic! exccause: 0x0000000d; pc: 0x0090ae8c; badvaddr: 0x10ff4038.
[  214.470398] usb 1-1: USB disconnect, device number 2
[  214.481646] wlp0s20u1: deauthenticating from xx:xx:xx:xx:xx:xx by local choice (Reason: 3=DEAUTH_LEAVING)
[  214.763111] ath: phy0: Chip reset failed
[  214.763114] ath: phy0: Unable to reset channel (2412 Mhz) reset status -22
[  214.763115] ath: phy0: Unable to set channel
[  214.773193] ath: phy0: Failed to wakeup in 500us
[  214.783294] ath: phy0: Failed to wakeup in 500us
[  214.793355] ath: phy0: Failed to wakeup in 500us
[  215.011616] cfg80211: Calling CRDA to update world regulatory domain
[  215.046082] usb 1-1: ath9k_htc: USB layer deinitialized
[  215.052719] cfg80211: World regulatory domain updated:
[  215.052723] cfg80211:  DFS Master region: unset
[  215.052724] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[  215.052726] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[  215.052728] cfg80211:   (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[  215.052729] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
[  215.052731] cfg80211:   (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A)
[  215.052733] cfg80211:   (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
[  215.052734] cfg80211:   (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
[  215.052736] cfg80211:   (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
[  215.052737] cfg80211:   (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
[  215.052921] cfg80211: Calling CRDA for country: ES
[  215.054032] cfg80211: Regulatory domain changed to country: ES
[  215.054034] cfg80211:  DFS Master region: ETSI
[  215.054034] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[  215.054036] cfg80211:   (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[  215.054037] cfg80211:   (5150000 KHz - 5250000 KHz @ 80000 KHz, 200000 KHz AUTO), (N/A, 2301 mBm), (N/A)
[  215.054038] cfg80211:   (5250000 KHz - 5350000 KHz @ 80000 KHz, 200000 KHz AUTO), (N/A, 2000 mBm), (0 s)
[  215.054039] cfg80211:   (5470000 KHz - 5725000 KHz @ 160000 KHz), (N/A, 2698 mBm), (0 s)
[  215.054040] cfg80211:   (57000000 KHz - 66000000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A)
[  215.325560] usb 1-1: new high-speed USB device number 11 using xhci_hcd
[  215.499675] usb 1-1: ath9k_htc: Firmware htc_7010.fw requested
[  215.601316] usb 1-1: ath9k_htc: Transferred FW: htc_7010.fw, size: 72812
[  215.671295] ath9k_htc 1-1:1.0: ath9k_htc: HTC initialized with 45 credits
[  215.894663] ath9k_htc 1-1:1.0: ath9k_htc: FW Version: 1.4
[  215.894667] ath: EEPROM regdomain: 0x809c
[  215.894667] ath: EEPROM indicates we should expect a country code
[  215.894669] ath: doing EEPROM country->regdmn map search
[  215.894670] ath: country maps to regdmn code: 0x52
[  215.894670] ath: Country alpha2 being used: CN
[  215.894671] ath: Regpair used: 0x52
[  215.898120] ieee80211 phy1: Atheros AR9287 Rev:2
[  215.898250] cfg80211: Calling CRDA for country: CN
[  215.898585] ath9k_htc 1-1:1.0 wlp0s20u1: renamed from wlan0
[  215.924286] cfg80211: Current regulatory domain intersected:
[  215.924289] cfg80211:  DFS Master region: unset
[  215.924290] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[  215.924291] cfg80211:   (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[  215.924292] cfg80211:   (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2300 mBm), (N/A)
[  215.924293] cfg80211:   (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
[  215.924294] cfg80211:   (57240000 KHz - 59400000 KHz @ 2160000 KHz), (N/A, 2800 mBm), (N/A)
[  215.924295] cfg80211:   (59400000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A)
[  215.924296] cfg80211:   (63720000 KHz - 65880000 KHz @ 2160000 KHz), (N/A, 2800 mBm), (N/A)
[  217.895818] wlp0s20u1: authenticate with xx:xx:xx:xx:xx:xx
[  218.350871] wlp0s20u1: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
[  218.353064] wlp0s20u1: authenticated
[  218.353769] wlp0s20u1: associate with xx:xx:xx:xx:xx:xx (try 1/3)
[  218.358961] wlp0s20u1: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x411 status=0 aid=2)
[  218.368835] wlp0s20u1: associated
Comment 44 Oleksij Rempel 2015-03-29 06:10:44 UTC
@agapito, are you using never kernel version? this time i see firmware panic and the fact that adapter was able to recover within 3 seconds.

@Ryan Underwood, i assume you are using old kernel.

@all
please, use 
https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers-next.git/

i hope soon will be included this patch set, please test it if you can:
http://www.spinics.net/lists/linux-wireless/msg135122.html

It should be interesting for users with USB2.0 host controller.
Comment 45 Ryan Underwood 2015-03-29 07:11:42 UTC
Correct, on this system: Linux iqrouter 3.16.0-0.bpo.4-686-pae #1 SMP Debian 3.16.7-ckt4-3~bpo70+1 (2015-02-12) i686 GNU/Linux

Which version are you using or would advise me to try with the new driver?
Comment 46 Oleksij Rempel 2015-03-29 09:06:24 UTC
Please, use self compiled kernel from source. read my previous comment.
Comment 47 agapito 2015-03-29 10:33:47 UTC
@Oleksij: My kernel is 3.19.3-1-ARCH. I will try wireless-drivers-next.git when those patches are included. 

Thanks for your work anyway.
Comment 48 Ryan Underwood 2015-03-29 16:36:48 UTC
Do you refer to Comment 22?  Is this hack still needed?
Comment 49 Oleksij Rempel 2015-03-29 18:37:11 UTC
Comment 44. No.
Comment 50 Ryan Underwood 2015-03-29 20:19:45 UTC
Well, I meant by that comment, which version should I pull the wireless-drivers-next into.  Anyway, I've used the latest linux-stable tag (4.0.0-rc5), pulled wireless-drivers-next and applied all your patches, and using the firmware from your github.  Everything looks really great so far!  I can't believe it is this stable now, really.  I will report back after using it heavily for some time.
Comment 51 Ryan Underwood 2015-03-29 21:00:36 UTC
Ok, first failure happened.  Don't get me wrong, this is much better than before.

It is still unusable because USB reset leaves the adapter uninitialized, so hostapd is then in an unusable state until it is manually restarted.

Mar 29 15:54:29 iqrouter kernel: [ 3860.565933] usb 4-4: USB disconnect, device number 3
Mar 29 15:54:29 iqrouter kernel: [ 3860.910778] wlan_br0: port 1(wlan_priv0) entered disabled state
Mar 29 15:54:29 iqrouter kernel: [ 3860.911427] device wlan_priv0 left promiscuous mode
Mar 29 15:54:29 iqrouter kernel: [ 3860.911496] wlan_br0: port 1(wlan_priv0) entered disabled state
Mar 29 15:54:29 iqrouter kernel: [ 3860.963935] usb 4-4: ath9k_htc: USB layer deinitialized
Mar 29 15:54:29 iqrouter kernel: [ 3861.203669] usb 4-4: new high-speed USB device number 5 using ehci-pci
Mar 29 15:54:29 iqrouter kernel: [ 3861.336838] usb 4-4: New USB device found, idVendor=0cf3, idProduct=7015
Mar 29 15:54:29 iqrouter kernel: [ 3861.336912] usb 4-4: New USB device strings: Mfr=16, Product=32, SerialNumber=48
Mar 29 15:54:29 iqrouter kernel: [ 3861.336968] usb 4-4: Product: USB WLAN
Mar 29 15:54:29 iqrouter kernel: [ 3861.337003] usb 4-4: Manufacturer: ATHEROS
Mar 29 15:54:29 iqrouter kernel: [ 3861.337037] usb 4-4: SerialNumber: 12345
Mar 29 15:54:29 iqrouter kernel: [ 3861.338490] usb 4-4: ath9k_htc: Firmware htc_7010.fw requested
Mar 29 15:54:30 iqrouter kernel: [ 3861.449042] usb 4-4: ath9k_htc: Transferred FW: htc_7010.fw, size: 72812
Mar 29 15:54:30 iqrouter kernel: [ 3861.518110] ath9k_htc 4-4:1.0: ath9k_htc: HTC initialized with 45 credits
Mar 29 15:54:30 iqrouter kernel: [ 3861.705624] ath9k_htc 4-4:1.0: ath9k_htc: FW Version: 1.4
Mar 29 15:54:30 iqrouter kernel: [ 3861.705675] ath9k_htc 4-4:1.0: FW RMW support: On
Mar 29 15:54:30 iqrouter kernel: [ 3861.709456] ieee80211 phy1: Atheros AR9287 Rev:2
Mar 29 15:54:30 iqrouter kernel: [ 3861.709517] cfg80211: Calling CRDA for country: CN
Mar 29 15:54:30 iqrouter kernel: [ 3861.710851] ath9k_htc 4-4:1.0 wlan_priv0: renamed from wlan0
Mar 29 15:54:30 iqrouter kernel: <30>[ 3861.723616] systemd-udevd[7501]: renamed network interface wlan0 to wlan_priv0
Mar 29 15:54:30 iqrouter kernel: [ 3861.724009] cfg80211: Current regulatory domain intersected:
Mar 29 15:54:30 iqrouter kernel: [ 3861.724054] cfg80211:  DFS Master region: FCC
Mar 29 15:54:30 iqrouter kernel: [ 3861.724079] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
Mar 29 15:54:30 iqrouter kernel: [ 3861.724134] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
Mar 29 15:54:30 iqrouter kernel: [ 3861.724178] cfg80211:   (5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A, 1700 mBm), (N/A)
Mar 29 15:54:30 iqrouter kernel: [ 3861.724220] cfg80211:   (5250000 KHz - 5330000 KHz @ 80000 KHz), (N/A, 2300 mBm), (0 s)
Mar 29 15:54:30 iqrouter kernel: [ 3861.724263] cfg80211:   (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 3000 mBm), (N/A)
Mar 29 15:54:30 iqrouter kernel: [ 3861.724306] cfg80211:   (57240000 KHz - 59400000 KHz @ 2160000 KHz), (N/A, 2800 mBm), (N/A)
Mar 29 15:54:30 iqrouter kernel: [ 3861.724348] cfg80211:   (59400000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A)
Mar 29 15:54:30 iqrouter kernel: [ 3861.901704] IPv6: ADDRCONF(NETDEV_UP): wlan_priv0: link is not ready
Comment 52 Ryan Underwood 2015-03-29 21:03:03 UTC
Created attachment 172591 [details]
dmesg linux 4.0.0-rc5 with new driver
Comment 53 Ryan Underwood 2015-03-29 21:03:44 UTC
$ lspci
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 0c)
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) (rev 0c)
00:1a.0 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)
00:1a.7 USB controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)
00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 03)
00:1d.0 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)
00:1f.0 ISA bridge: Intel Corporation 82801HM (ICH8M) LPC Interface Controller (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) SATA Controller [AHCI mode] (rev 03)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 03)
05:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8039 PCI-E Fast Ethernet Controller (rev 14)
07:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN [Kedron] Network Connection (rev 61)
08:09.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 05)
08:09.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22)
08:09.2 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 12)
08:09.3 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 12)
Comment 54 Oleksij Rempel 2015-03-30 14:03:12 UTC
Then i assume. it is completely different bug. Le us limit this one to "firmware panic! exccause: 0x0000000d; pc: 0x0090ae8c;"