-
Notifications
You must be signed in to change notification settings - Fork 182
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ath: phy82: Failed to wakeup in 500us #72
Comments
please try latest firmware Beside, i have similar adapter. What is your reproduction case? |
i am running the latest wireless backports and the latest firmware blob also i compiled my own it still acts the same way . this is the log that happens when the usb device disconnects [140606.192122] usb 1-1: USB disconnect, device number 92 i know windows driver runs solid because the alpha awus03nha works fine without any disconnecting in windows i said this to rule out this as a hardware issue to reproduce you pass a lot of traffic (by lot i mean the maximum of my isp) 2mbit which is hardly anything and it disconnects and then reconnects and keeps on doing this with a varied randomness sometimes it wont disconnect for a long while but rest assured it will the timing is very random i know the ath9k_htc is a firmware for the 144mhz xtensa soc inside the device so why is ath9k driver needed are they both required ? is the ath9k driver causing the problem ? i have seen the same error ath: phy87: Failed to wakeup in 500us reported in the ath9k driver for other pcie wlan cards in the forums so this might be a ath9k issue ? what is the role of that ath9k and ath9k_htc play to work this usb adapter ? thanks for your reply |
Uff... lots of questions :), lets do it step by step:
Lets try to reduce Interrupt traffic. Seems like it is causing some problems on different HW. Try this: |
by disabling the leds of the wifi card to reduce the interrupt traffic over the usb as you suggested i still get the ath: phy87: Failed to wakeup in 500us [140606.192122] usb 1-1: USB disconnect, device number 92 followed by the driver reloading itself [140606.607097] usb 1-1: ath9k_htc: USB layer deinitialized |
can u specify the particular kernel log your interested the system dmesg log is really huge its been running for some time and the log have accumulated a lot i have already pasted everything that has to concern with the ath9k_htc driver the system is running ubuntu 14.10 with kernel 3.18.5-031805-generic searching this error in google ath: phy87: Failed to wakeup in 500us reveals many pci atheros cards that run the ath9k driver has the same issue so we rule out that this specific to ath9k_htc |
@olerem the same message appears for pcie cards on the pci bus as far as i know pcie cannot be disconnected from the pci bus or removed they dont provide plug and play so this is not simple as the device getting unrecognized ? but in my case the kernel prints a usb-disconnect which leads to failed wakeups but the drivers usb layer is only deinitialized way later on [181215.433983] usb 1-1: USB disconnect, device number 108 |
The driver do not reloading itself. At some point usb layer getting "reset" or "detach" signal from hardware. After this, deinit process is starting, ath9k_htc is not needed any more since usb device is detached, so it is unloaded. Then usb layer get attach signal and the driver is loaded again. Forget about pci driver. |
i have come across many error that might be caused by something trivial like the wpa_supplicant or the network-manger i am asking this because after googling i seem to be the very few people reporting on this error can't find anyone reporting the same for the alpha awus03nha card nothing in the openwrt forums is also a clue because of it being custom distribution should i look into network-manger doing anything strange ? or is this absurd which linux distribution, kernel are you running with this device ? since you sound like your running a full linux distro with the same device and don't experience the problem i just read the wiki https://github.com/qca/open-ath9k-htc-firmware/wiki/usb-related-issues i can rule out the leds and as for the cable and power it works fine in windows with windows driver |
Like i said, i use this adapter and do some stress tests on it. Some times FW may fail and reboot adapter, but in this case with updated kernel you will get some thing like this: Your issue looks more like this: |
Here is updated list with usb related issues: feedbacks are welcome! :D |
Hi, Linux hostname 3.18.11+ #781 PREEMPT Tue Apr 21 18:02:18 BST 2015 armv6l GNU/Linux Are you still following this issue ? If I can help you resolve it ... Same symptom than yipperr: Works perfectly (or almost) on Windows. Just have to reduce TX/RX buffer to 128 instead of 256 else it seems to have the same problem on Windows but Microsoft manages better it by "not disconnecting". Do you know how to change the buffer in linux ? |
i have no idea what "TX/RX buffer" means. |
TX=Transmission This is an option from the Windows driver. In the device properties on Windows I can change "Transmit Buffers" and "Receive Buffers" |
I removed the blinked LED by doing It seems to be better. |
If you will update kernel and firmware, it should work even better. |
They are both up to date :) |
3.18.11? really? |
Yop --> |
$> apt-cache show firmware-atheros /lib/firmware # ll 9271 $> md5sum ar9271.fw htc_9271.fw If it could help ;-) |
Well.... it is very old kernel and firmware. |
I can't do better I think. I'm on a Raspberry Pi with ARM architecture. Unless I build my own kernel through cross compilation, I can't go to 4.0.5. Anyway, disabling the Led seems to solved the problem. |
@Skity |
@yipperr : Try to maximize the current on your USB ports (since RPI B+) with the following options in config.txt in /boot : safe_mode_gpio=4 |
I also changed the cable by one with two output (One to the adapter and Two to the RPI to provide more power to the adapter) |
i tried the usb 3.0 port and 2.0 ports on my laptop all behaves similarly |
@yipperr : not glad it doesn't fix it for you :) |
Advice: English no main language
|
Using new firmware with old driver/kernel will not do any changes. Please update kernel. |
Advice: English no main language |
If if there some disconnections, i hope it will restore within 10 seconds. |
Advice: English no main language |
glad to hear it :) |
Not sure if u are following this but I have similar issue, but with latest kernel + firmware
It try's to reconnect again and again, uname -r apt-cache show firmware-atheros
|
I did change the cable to a proper (with filter) + shorter one, no additional powering was need cause I'm connecting it to 3.0 interface, (2.0 may need some extra powering)
dmesg
Thanks @olerem |
i've had this problem too with alfa card, especially if enabled more channels e.g. 2.3-2.7GHz. eventually it's reception sensitivity went bad showing 12-15dB less signal. after replacing faulty T/R switch it now works without problems with even wider range set (2192-2992) and i noticed no more disconnects. so, most likely it is hardware fault |
Yeah, the hardware isn't designed for 2.3-2.7, so a bunch of weird crap can
go wrong. Sorry :(
…-a
On Sun, 13 Jan 2019 at 15:08, psyborg55 ***@***.***> wrote:
i've had this problem too with alfa card, especially if enabled more
channels e.g. 2.3-2.7GHz. eventually it's reception sensitivity went bad
showing 12-15dB less signal. after replacing faulty T/R switch it now works
without problems with even wider range set (2192-2992) and i noticed no
more disconnects. so, most likely it is hardware fault
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#72 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABGl7UWYR74fT6EcPdK_kFM9YP-qOSDEks5vC7yBgaJpZM4DgtiY>
.
|
no such crap with tl-wn722 |
@psyborg55 Hey psyborg. Can confirm, same issue. Would lenght of USB cable matter? I've put some shielding on mine and a ferrite bead. |
first, try using cable other than the one you got in package (suggestion 50cm or shorter) |
@psyborg55 Tried multiple cables too, didn't work. I thought that it might require more power and ask for a powered hub, but I saw people using it on Youtube with a regular old 2.0 USB. It should work normally. By debug I suppose you meant my dmesg output? I hope I got it right. Thank you so much once again dmesg |
try to get full debug output, by passing debug parameter to driver. e.g. on my system it is in /etc/modprobe.d/ath9k.conf |
@psyborg55 Thank you for suggesting a cable change. I was trying to debug @TheMrRandomDude exact same issue with my card, and other cards, on multiple OS, virtualbox, live USB and so on. |
8 years later, I'm seeing this error on a Lenovo X200 laptop running Guix System. It renders my ThinkPenguin TP150N dongle unusable:
Since the e1000e wired ethernet also appears to be flaky on that X200, I don't have connectivitity at the moment, so I wasn't able to upgrade the OS to see if it would help things. I'll try later using USB tethering. |
the error is most of the time caused by hw power fault. windows drivers might work just fine, but if you get this in every linux version with any kernel you try it is hw issue. sometimes using shorter cable might help, if not you need to repair device. @olerem @erikarn in the datasheet, section LDO Circuit Recommendation recommended capacitance for 1.2V supply is 10 to 33uF suggestion there "If the on-chip LDO is not used, the CTRL1 pin should be pulled down to ground by 10 kohm resistor to disable the internal amplifier." alfa does not use on-chip LDO, and it also looks like the pin is left floating. is there a sw way of disabling internal amp ? |
@psyborg55 I tried it from another Guix System laptop, and I had a different USB error but it also would not work, so your theory of a HW issue seems plausible. It's the first time I experienced such failure from this kind of electronic though, so I'm surprised. My adapter uses the AR9271 chipset (see: https://www.thinkpenguin.com/gnu-linux/penguin-wireless-n-usb-adapter-gnu-linux-tpe-n150usb). Here's what dmesg reported on that 2nd machine:
|
yeah, slightly different set of messages, only host dependent. |
i restored my awus036nha fully. no more any of these messages with old laptop and two routers. parts that needed replacement (except for richtek power converter) are VLS252012ET-2R2M and only one was faulty (1.2V i guess) according to LCR measurement. also tried to use parts from mq4wu5108 card but these did not work, i think they are of different value than 2.2uH |
@psyborg55 just to be clear, you needed to replace 1. richtek power converter integrated circuit (which model?) 2. one of the two VLS252012ET-2R2M, right? For other readers, the VLS252012Et-2R2M part is a 2.2 uH surface mounted inductor (see: https://product.tdk.com/system/files/dam/doc/product/inductor/inductor/smd/catalog/inductor_automotive_power_vls252012e-ca_en.pdf) |
yes, those were busted completely. it is RT8020GQW. visually, they looked fine, but the richtek was getting extremely hot just seconds after plugging in and voltages were bad. inductor was quite difficult to detect, tx/rx rates would drop to 108/120 Mbps - i took off almost all capacitors and checked only to find they all appear to be fine. then i replaced the inductor with the one from mq4wu5108 board, rates synced at 150/150 but there were still some issues. LCR confirmed original 2.2uH inductor went down to 0.3uH, the other inductor was good, the two inductors from mq4wu5108 card have more than 2.2uH (can't tell precisely as the measurement was with 2-wire) and one of these two has slightly higher inductance than the other one - about 0.1uH. at that point i decided to buy new TDK inductors and after soldering both new parts everything works fine (probably it would work fine if i replaced only the damaged one, but as they come in pack of 10 why not change both) |
I just opened my tpe-n150usb adapter from ThinkPenguin; it was a bit difficult to open: I used a small flat screwdriver to push the black plastic pin on the metal sleeve then pried around to push back the black plastic casing. Here are some shots of the board; I trust the bigger '13 NCJI C3101075X01' identified chip is the AR9271, and I also identified an STMicroelectronics 24C08RP EEPROM (8/16KB) and a BDC 9706A DC/DC voltage converter (https://www.diodes.com/assets/Datasheets/products_inactive_data/AUR9706.pdf). Perhaps I should probe with a DMM around the converter to verify the voltages are expected. |
yes, try on those two big flat SMDs. before that, have you tried connecting the device through a 1m extension cable, or you plug it in directly into PC ? try cable if you have one around just to see if anything other happens in log |
Hm, I've tried connecting it, but it's difficult while its case is disassembled: I shimmed it into the USB port using some thin polystyrene foam sheet. It appears completely dead (dmesg is silent), whether I connect it directly (the usual case) or via a 1 m USB extension cord. I hope I haven't made it worse :-). I'm lacking lab instruments here to do the measurements, unless I can somehow use my computer as both a function generator and an oscilloscope to use one of the tricks explained here: https://www.wikihow.com/Measure-Inductance (I think I've done so in the past for the scope part, using xoscope). audmes looks like another option for the oscilloscope part. |
@psyborg55 I'm not well equipped/motivated enough to fix mine. If you are interested, I could ship this to you free of charge; otherwise it'll soon find its way to the dust bin. |
hello i am using a alpha awus036nha in ubuntu with 3.18 kernel causes a lot of disconnects where the whole driver reloads itself and the usb layer is deinitialized
here is the dmesg
[134330.226799] ath: phy82: Failed to wakeup in 500us
[134330.337247] ath: phy82: Failed to wakeup in 500us
[134330.553857] cfg80211: Calling CRDA to update world regulatory domain
[134330.557245] cfg80211: World regulatory domain updated:
[134330.557249] cfg80211: DFS Master region: unset
[134330.557250] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[134330.557252] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm), (N/A)
[134330.557254] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm), (N/A)
[134330.557255] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm), (N/A)
[134330.557256] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm), (N/A)
[134330.557257] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm), (N/A)
[134330.621383] usb 1-1: ath9k_htc: USB layer deinitialized
[134330.861057] usb 1-1: new high-speed USB device number 87 using xhci_hcd
[134331.008352] usb 1-1: New USB device found, idVendor=0cf3, idProduct=9271
[134331.008363] usb 1-1: New USB device strings: Mfr=16, Product=32, SerialNumber=48
[134331.008369] usb 1-1: Product: UB91C
[134331.008373] usb 1-1: Manufacturer: ATHEROS
[134331.008377] usb 1-1: SerialNumber: 12345
[134331.010014] usb 1-1: ath9k_htc: Firmware htc_9271.fw requested
[134331.472999] usb 1-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
[134331.708841] ath9k_htc 1-1:1.0: ath9k_htc: HTC initialized with 33 credits
[134331.938832] ath9k_htc 1-1:1.0: ath9k_htc: FW Version: 1.3
[134331.938843] ath: EEPROM regdomain: 0x833a
[134331.938846] ath: EEPROM indicates we should expect a country code
[134331.938851] ath: doing EEPROM country->regdmn map search
[134331.938855] ath: country maps to regdmn code: 0x37
[134331.938859] ath: Country alpha2 being used: GB
[134331.938861] ath: Regpair used: 0x37
[134331.943193] ieee80211 phy83: Atheros AR9271 Rev:1
[134331.943229] cfg80211: Calling CRDA for country: GB
added notes tried on usb 2.0 and 3.0 ports its not the usb layer but the driver itself just so to rule out hardware the alpha nha works solid in windows while connecting to wifis
The text was updated successfully, but these errors were encountered: