Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#67041 - [linux] Update to 5.7.3 breaks ath9k_htc device

Attached to Project: Arch Linux
Opened by Roma Tentser (rtentser) - Friday, 19 June 2020, 07:48 GMT
Last edited by freswa (frederik) - Monday, 13 July 2020, 23:48 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Tobias Powalowski (tpowa)
Jan Alexander Steffens (heftig)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


There was some ath9k patches in upstream, so it probably a regression.

lsusb sees the device (TL-WN722N v1, Bus 001 Device 007: ID 0cf3:9271 Qualcomm Atheros Communications AR9271 802.11n), but there is no interface for it with ip a. Also, other kernels don't see the device after boot from 5.7.3, i need to manually remove and again insert the device.

Still an issue in 5.7.4. Also an issue in 5.8-rc1 (linux-mainline).
This task depends upon

Closed by  freswa (frederik)
Monday, 13 July 2020, 23:48 GMT
Reason for closing:  Fixed
Additional comments about closing:  linux 5.7.8.arch1-1 linux-lts 5.4.51-1
Comment by Henrique Antunes (HA012) - Friday, 19 June 2020, 13:38 GMT
I've experienced the same problem. The device won't be recognized even after unplugging and plugging it back, though.
Kernel: 5.4.47-1-lts
Comment by Viktor Jägersküpper (viktorjk) - Friday, 19 June 2020, 14:19 GMT
Has anyone bisected the kernel (5.7 or 5.4) to find the bad commit? I'm about to do this, but I'm using an old Core 2 Duo, so this might take a while unfortunately. Since I don't see anything useful in dmesg or the journal I think bisecting is the best way to help the kernel developers identify the bug.
Comment by loqs (loqs) - Friday, 19 June 2020, 15:40 GMT
You can use the ALA [1] to find a good kernel. If you can not locate a good kernel, bisection will not work.
Bisecting between two stable kernels will generally be quicker than between two mainline kernels.

Comment by Roma Tentser (rtentser) - Friday, 19 June 2020, 17:20 GMT
5.7.2 is good. Downgrading is a workaround.
Comment by loqs (loqs) - Friday, 19 June 2020, 18:46 GMT
Please bisect between 5.7.2 and 5.7.3.
Comment by Roma Tentser (rtentser) - Friday, 19 June 2020, 19:16 GMT
I'm using an old Core 2 Duo too, so it'll take time.
Comment by Viktor Jägersküpper (viktorjk) - Saturday, 20 June 2020, 08:37 GMT
So the first build was actually good (the firmware was loaded correctly), but for some reason wpa_supplicant didn't work as it should and GDM broke and I couldn't switch to the tty. Perhaps some of the commits depend on each other and bisecting between them breaks things, so I will probably build a kernel (based on 5.7.4) without the bad commit when I have finished the bisection to be sure that this commit is really the bad one. Let's just hope that I don't run into a build failure.

There is already an upstream bug report [1], but we still have to find the bad commit.

Comment by Roma Tentser (rtentser) - Saturday, 20 June 2020, 10:30 GMT
wpa_supplicant broken since 5.4 for me. Or actually even earlier, but since 5.4 there are kernel panics instead of minor fails. Not always, just sometimes when initializing the interface, other times it works fine. I don't think this bugs are related, i actually hope 5.7.3 changes (when properly fixed) will fix panics.
Comment by Viktor Jägersküpper (viktorjk) - Saturday, 20 June 2020, 16:13 GMT
I finished the bisection and reported it upstream. I will test if reverting the bad commit helps.
Comment by Roma Tentser (rtentser) - Saturday, 20 June 2020, 17:35 GMT
Thanks a lot!
Comment by loqs (loqs) - Saturday, 20 June 2020, 19:20 GMT
If you do not receive a response in a few days you could reply to [1] which added it to 5.7.Y or [2] the original commit or add the commits author to the bug report.

Comment by CBotulinum (CBotulinum) - Thursday, 02 July 2020, 08:12 GMT
I can confirm that this bug still exists in kernel 5.6.7, checking dmesg the device seems to be correctly detected, and the driver correctly selected but never actually loaded.
The specific device I am testing is the exact same one as in the OP.
Comment by taylor (crushv) - Thursday, 09 July 2020, 03:50 GMT
Running into the same issue with tp-link tl-wn722n on 5.7.7
Comment by ARB (Alinux) - Thursday, 09 July 2020, 16:10 GMT
Same problem with 5.4.50-1-lts, no problem on other distros
Comment by loqs (loqs) - Sunday, 12 July 2020, 16:14 GMT
Can you confirm the issue is fixed in linux 5.7.8.arch1-1 and linux-lts 5.4.51-1 currently in testing?
Comment by Patryk Tech (patryk-tech) - Sunday, 12 July 2020, 20:37 GMT
On a TP-Link TL-WN722N, upgrading to `5.7.8.arch1-1` appears to resolve the issue for me.