Bug 215698
| Summary: | ath9k —> Wifi randomly disconnects [Ar5B22/AR9462] | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | SlayerProof32 (kortrax11) |
| Component: | network-wireless | Assignee: | drivers_network-wireless (drivers_network-wireless) |
| Status: | NEW --- | ||
| Severity: | normal | CC: | abc, adilson, alexander, daniel.calcoen, dpirate, gnu_stallman, gzhqyz, regressions |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 5.16.5 (latest) | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
|
Description
SlayerProof32
2022-03-18 08:54:45 UTC
Dmesg after restricting card to a specific BSSID. This doesn't fix anything. [ 4701.065410] wlp4s0: authenticate with ba:95:75:6f:45:68 [ 4701.075319] wlp4s0: send auth to ba:95:75:6f:45:68 (try 1/3) [ 4701.666707] wlp4s0: send auth to ba:95:75:6f:45:68 (try 2/3) [ 4701.709739] wlp4s0: authenticated [ 4701.710688] wlp4s0: associate with ba:95:75:6f:45:68 (try 1/3) [ 4701.818738] wlp4s0: associate with ba:95:75:6f:45:68 (try 2/3) [ 4701.886129] wlp4s0: RX AssocResp from ba:95:75:6f:45:68 (capab=0x1431 status=0 aid=1) [ 4701.886240] wlp4s0: associated [ 4701.886314] ath: EEPROM regdomain: 0x8348 [ 4701.886315] ath: EEPROM indicates we should expect a country code [ 4701.886316] ath: doing EEPROM country->regdmn map search [ 4701.886316] ath: country maps to regdmn code: 0x3a [ 4701.886317] ath: Country alpha2 being used: US [ 4701.886318] ath: Regpair used: 0x3a [ 4701.886319] ath: regdomain 0x8348 dynamically updated by country element [ 4702.287208] wlp4s0: Limiting TX power to 30 (30 - 0) dBm as advertised by ba:95:75:6f:45:68 [ 4704.161277] kauditd_printk_skb: 1 callbacks suppressed [ 4704.161280] audit: type=1130 audit(1647594646.727:672): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 4705.945121] wlp4s0: authenticate with ba:95:75:6f:45:68 [ 4705.955124] wlp4s0: send auth to ba:95:75:6f:45:68 (try 1/3) [ 4706.011160] wlp4s0: authenticated [ 4706.011528] wlp4s0: associate with ba:95:75:6f:45:68 (try 1/3) [ 4706.114582] wlp4s0: associate with ba:95:75:6f:45:68 (try 2/3) [ 4706.188402] wlp4s0: RX AssocResp from ba:95:75:6f:45:68 (capab=0x1431 status=0 aid=1) [ 4706.188535] wlp4s0: associated [ 4706.188623] ath: EEPROM regdomain: 0x8348 [ 4706.188625] ath: EEPROM indicates we should expect a country code [ 4706.188626] ath: doing EEPROM country->regdmn map search [ 4706.188627] ath: country maps to regdmn code: 0x3a [ 4706.188628] ath: Country alpha2 being used: US [ 4706.188629] ath: Regpair used: 0x3a [ 4706.188630] ath: regdomain 0x8348 dynamically updated by country element [ 4706.280681] wlp4s0: Limiting TX power to 30 (30 - 0) dBm as advertised by ba:95:75:6f:45:68 [ 4708.819971] wlp4s0: authenticate with ba:95:75:6f:45:68 [ 4708.830015] wlp4s0: send auth to ba:95:75:6f:45:68 (try 1/3) [ 4708.970474] wlp4s0: send auth to ba:95:75:6f:45:68 (try 2/3) [ 4708.977999] wlp4s0: authenticated [ 4708.978416] wlp4s0: associate with ba:95:75:6f:45:68 (try 1/3) [ 4709.082470] wlp4s0: associate with ba:95:75:6f:45:68 (try 2/3) [ 4709.154774] wlp4s0: RX AssocResp from ba:95:75:6f:45:68 (capab=0x1431 status=0 aid=1) [ 4709.154875] wlp4s0: associated [ 4709.154945] ath: EEPROM regdomain: 0x8348 [ 4709.154946] ath: EEPROM indicates we should expect a country code [ 4709.154947] ath: doing EEPROM country->regdmn map search [ 4709.154947] ath: country maps to regdmn code: 0x3a [ 4709.154948] ath: Country alpha2 being used: US [ 4709.154949] ath: Regpair used: 0x3a [ 4709.154949] ath: regdomain 0x8348 dynamically updated by country element [ 4709.250440] wlp4s0: Limiting TX power to 30 (30 - 0) dBm as advertised by ba:95:75:6f:45:68 [ 4716.017853] audit: type=1101 audit(1647594658.583:673): pid=114559 uid=1000 auid=1000 ses=2 msg='op=PAM:accounting grantors=pam_unix,pam_permit,pam_time acct="family" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success' [ 4716.017971] audit: type=1110 audit(1647594658.583:674): pid=114559 uid=1000 auid=1000 ses=2 msg='op=PAM:setcred grantors=pam_faillock,pam_permit,pam_env,pam_faillock acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1res=success' [ 4716.019498] audit: type=1105 audit(1647594658.585:675): pid=114559 uid=1000 auid=1000 ses=2 msg='op=PAM:session_open grantors=pam_systemd_home,pam_limits,pam_unix,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/d Update: I tried loading with nohwcrypt=1 and that did not fix the issue The most strange thing I see here is, that you only have authentication/association messages without any de-authentication line in between. And how you can get any data transmitted with only seconds between the associations also remains an question... Can you proved debug logs from wpa_supplicant, so we can see what it's going on here? Assuming you use wpa_supplicant with dbus, the most common combination: sudo dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1 \ /fi/w1/wpa_supplicant1 \ org.freedesktop.DBus.Properties.Set \ string:fi.w1.wpa_supplicant1 \ string:DebugLevel \ variant:string:"msgdump" That will write tons of debug information into the log and we should see better what's going on here. Hi, @SlayerProof32 The latest release of 5.16 kernel series should be 5.16.15 when you reported, not 5.16.5. It could be a regression if you are using 5.16.15, see https://bugzilla.kernel.org/show_bug.cgi?id=215703 I’m currently not at the computer I used to test this, however if a cause is not determined by the time I get back, I will upload the wpa_supplicant logs ASAP. Is it possible you can change the status to [needinfo] to reflect the fact that I must upload the logs before any progress can be made. I get the same kind of repetitive errors and disconnections in kernels 5.15.31 and 5.17.0 and using iwd. Here is one of them: [ +31.434515] wlan0: authenticate with 98:42:65:62:5c:e4 [ +0.014544] wlan0: send auth to 98:42:65:62:5c:e4 (try 1/3) [ +0.001078] wlan0: authenticated [ +0.001648] wlan0: associate with 98:42:65:62:5c:e4 (try 1/3) [ +0.001387] wlan0: RX AssocResp from 98:42:65:62:5c:e4 (capab=0x11 status=0 aid=1) [ +0.000137] wlan0: associated [ +0.004503] ath: EEPROM regdomain: 0x82d4 [ +0.000005] ath: EEPROM indicates we should expect a country code [ +0.000001] ath: doing EEPROM country->regdmn map search [ +0.000000] ath: country maps to regdmn code: 0x37 [ +0.000001] ath: Country alpha2 being used: ES [ +0.000001] ath: Regpair used: 0x37 [ +0.000000] ath: regdomain 0x82d4 dynamically updated by country element [ +0.000416] wlan0: Limiting TX power to 23 (23 - 0) dBm as advertised by 98:42:65:62:5c:e4 I also have an Atheros AR9462 card. Also, at kernel version 5.15.26 this doesn't happen, I started noticing this issue when I updated to 5.15.31 and 5.17.0 Is it possible you can run sudo dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1 \ /fi/w1/wpa_supplicant1 \ org.freedesktop.DBus.Properties.Set \ string:fi.w1.wpa_supplicant1 \ string:DebugLevel \ variant:string:"msgdump" >wpa_supplicant.log and upload? It may help show what the issue is. I will run it once I have access to the computer I put that chip in again. Also check out this bug https://bugzilla.kernel.org/show_bug.cgi?id=215703 TWIMC, the Linux developers are discussing a patch for mainline that seems to help, in case anyone wants to give it a shot: https://lore.kernel.org/stable/871qyr9t4e.fsf@toke.dk/ TWIMC: the change that afaics is causing this regression was reverted in mainline: https://git.kernel.org/torvalds/c/bddac7c1e02ba47f0570e494c9289acea3062cc1 The revert will likely be backported to the next (due today) or over-next kernel versions released in affected stable and long series. I can confirm this problem with M.2 "05:00.0 Network controller: Qualcomm Atheros AR9462 Wireless Network Adapter (rev 01)". I had the problem a while ago, then it disappeared for months and now it's back since about two weeks. my hardware : laptop Asus N751JK Network controller: Qualcomm Atheros AR9462 Wireless Network Adapter (rev 01) Subsystem: AzureWave AR9462 Wireless Network Adapter I was runing Ubuntu 20.10, 21.04 up to Ubuntu 21.10 with Kernel 5.13.0 without any problem. When migrated to Ubuntu 22.04 which installs Kernel 5.15 then the problems started. I upgraded and tested unsuccessfully the following Kernels : 5.15.28, 5.15.36, 5.16.14, 5.16.20, 5.17.4, 5.17.5 I disabled the power save as explained at https://askubuntu.com/questions/1403773/22-04-wifi-keeps-disconnecting-for-a-few-seconds-frequently/1404471#1404471 without improvement in any of the Kernels tested. Also the "intel_iommu=off" mentioned at https://groups.google.com/g/linux.debian.kernel/c/RFpPIp0cncA/m/v9ELDxLICgAJ Bug#994590 didn't help. I downgraded and currently running without any problem using the Kernel 5.13.19-051319-generic. There is no problem in my airpoint (router) nor my internet access, I have other different computers and devices working correctly on wifi. In addition my N751JK works correctly when using the Ethernet adapter for the physical cable. (In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #11) > TWIMC: the change that afaics is causing this regression was reverted in > mainline: > https://git.kernel.org/torvalds/c/bddac7c1e02ba47f0570e494c9289acea3062cc1 FWIW, this ticket afaics gets really confusing. It's unclear if some of the comments here are about the problem discussed in https://bugzilla.kernel.org/show_bug.cgi?id=215703 that is fixed by the patch mentioned in the quote above and present in the latest kernels series that were affected. Then there are comments about problems with heavily modified distro kernels (like the one in Ubuntu), which often are more confusing then helpful, because the upstream developers don't know if the problem might be caused by one of the many changes the distributor applied to their kernel. That's why the front-page of this server states that issues with such kernels need to be filed in the distros bug tracker. In the end I'd suggest to close this ticket. If there is someone that still has trouble with random disconnects on the latest vanilla kernel I'd suggest to file a new ticket and drop a link here, so those that others still affected can follow there and provide a update. It would also help to clarify in that ticket when this problem started to happen (ideally with a bisection to identify the change that causes this), as developers have to fix such identified regressions quickly. as suggested I open ticket https://bugzilla.kernel.org/show_bug.cgi?id=215918 dedicated to collect only for Ubuntu flavor of kernels Hello, I can confirm that the problem is fixed with Linux 5.16.20. Thank you very much for fixing it. for the Ubuntu kernel 5.16.20 continue to show the problem follow up at https://bugzilla.kernel.org/show_bug.cgi?id=215918 |