If a ath9k_htc device is on the USB bus and functioning, a module reset (either by warm-booting the machine, or by rmmod/insmod'ing the ath9k_htc.ko module) causes the device to stop responding. Apparently once loaded, the firmware will not permit a reload of new firmware (done unconditionally by the driver) without a power cycle. This issue was submitted originally to the open source firmware project for these devices (note that the same bug is present in the proprietary firmware build still used in linux-firmware, not just in builds from the free project which descends from the same code): https://github.com/qca/open-ath9k-htc-firmware/issues/1 There is some argument as to which side of the USB connection the issue should be fixed on, but it's quite real.
Is this bug still reproducable?
For me this bug is not reproducable (Kernel 3.14.6 from Fedora 20 x86_64)
I am not sure if this is the same issue, but I see this: [10738.012037] ath9k_htc 1-2.4:1.0: ath9k_htc: Target is unresponsive [10738.012058] ath9k_htc: Failed to initialize the device in recent kernels (currently 3.16.3) after I wake up my PC from sleep. I have to manually disconnect my USB adapter and connect it back to get it working.
Is it working with latest firmware? https://github.com/olerem/ath9k-htc-firmware-blob
Created attachment 152051 [details] wifi not working after getting a new fw
I have downloaded htc_9271.fw from the link you provided and copied it to /usr/lib/firmware. After that, my wifi did not work at all. See attached log. I am not sure, if I have not done it properly or it just does not work.
FW size reported by kernel is incorrect: >[ 61.772881] usb 3-2.4: ath9k_htc: Transferred FW: htc_9271.fw, size: 23948 it should be 51008. and the path should be /lib/firmware/.
I tried again and this time I got expected fw size. It works fine, but the issue after waking up from sleep is still there. p.s. On my system (Arch Linux) /lib is symlink to /usr/lib/
Hi Martin, can you please test latest branch: https://git.kernel.org/cgit/linux/kernel/git/linville/wireless-testing.git/ I can't reproduce this suspend/resume issue on my laptop. It is just working. If it is working with latest source, then ok. If not, and this issue is regression (worked on some version before), then please try to make "git bisect". In this case i would assume, this issue was coused by usb subsystem and not by wireless driver.
I think this is a bit beyond my capabilities, I don't know how to do that.
What kind of USB host controller do you have? Is it a USB port with charging support? Usually it is easy to recognise by always working usb mouse, even is sleep mode. If it is the case, can you please try different port.
I have it connected to my monitor, which does not have powered hub, but I switched it to USB directly on my PC, which is powered (double checked that, my phone was charging while connected) and the result is the same.
I tested ar9271 on 3 different usb controllers, kernel version 3.17, still can't reproduce it.
Would my HW info help? What exactly do you need to identify the HW I do run, lspci?
"lspci -v" to know which usb controller do you use. "lsusb -t" to see where is this adapter attached. complete dmesg, after suspend resume.
Strange thing is that I can not reproduce it at the moment. But I will keep an eye on it and once it happens again, I will post the required data. It was happening all the time before.
Created attachment 155011 [details] Requested output of lspci
Created attachment 155021 [details] Requested output of lsusb
Created attachment 155031 [details] Dmesg after resume
Created attachment 155041 [details] Dmesg after resume and reinsert of adapter After removing the USB adapter and reattaching it, wifi works again.
This is log with old firmware, version 1.3. Did you tested it with latest firmware? The link i provided you?
Yes, I have tested it with the FW you provided and the result was the same.
Please send dmesg with new firmware.
I still experience this problem but all my googling only result in posts from 2013 indicating that the problem is solved. I case someone comes across this bug report while googling like I did I just want to share how I managed to work around the problem. Here is what I did: 1. Boot a 4.14.105 kernel 2. Plug in an ath9k_htc based usb dongle and let the 9271 firmware load successfully 3. Bring up the interface with ifconfig wlan0 up and use it 4. Bring down the interface with ifconfig wlan0 down 5. Hibernate the system 6. After resume the "Target is unresponsive" The dongle is now in a wedged state and only a usb replugging can bring it back. The problem turned out to be step 4. If I hibernate without doing ifconfig down the dongle works fine after resume. It's probably some residual bug in the driver. The reason why I used ifconfig down is because I sometimes use a iwlwifi based device and hibernation always fails unless I first bring the interface down.