I found out that using iwd things work out if I shut off the wifi and re-enable. It’s “good enogh” for now, I hope this gets fixed. Oddly enough the errors in iwd log don’t seem to show anything “new”.
I’ve been having this intermittently myself, using NetworkManager on Arch. Currently using the same workaround of re-enabling wifi after sleep. It’s quite an irony, I updated to the newest linux-firmware-git to get a newer APU firmware to solve the random freezes and it broke the wifi card instead…
I have the same thing. It’s very annoying. I’m on Arch Linux as well with NetworkManager.
rfblock block 1 && rfblock unblock 1 doesn’t work.
echo 1 |sudo tee /sys/bus/pci/devices/0000:01:00.0/remove && sudo tee /sys/bus/pci/rescan
fixes it.
Note that I’m not using the iwd backend, I’m using the normal wpa_supplicant backend of NetworkManager.
I am seeing exactly the same issue.
My system is 13 AMD Ryzen 7840U, Bios 03.03, Debian 12, Kernel 6.7.4, firmware 20230625 (from .deb) + newest updates 20240115 of amdgpu & mediatek firmware.
After coming back from hibernation, wifi is not reconnecting. After rebooting the system, the issue seems gone. It does not happen when waking up from suspend.
In my case, PCI remove & rescan alone does not help. To fix that, I have to do modprobe -r mt7921e && modprobe mt7921e before the rescan.
I had the same problem and ditched the mediatek for a Amazon.co.uk
Most of my suspend/resume problems have gone away (except for one I’m still trying to figure out)
Some additional info: it seems that iwd is not immune to getting stuck in a “unrecoverable” state either. I just had it unable to reconnect after hibernation, tho unlike with wpa_supplicant it seems to only happen 1/4 or so hibernations.
Also dmesg shows errors until i reload the module, here’s the log:
[ 132.240588] mt7921e 0000:01:00.0: Message 00000010 (seq 9) timeout
[ 132.240606] mt7921e 0000:01:00.0: Failed to get patch semaphore
[ 135.440958] mt7921e 0000:01:00.0: Message 000046ed (seq 10) timeout
[ 135.441153] mt7921e 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0002 address=0xffdcee00 flags=0x0000]
[ 136.612492] ucsi_acpi USBC000:00: unknown error 0
[ 136.612511] ucsi_acpi USBC000:00: UCSI_GET_PDOS failed (-5)
[ 138.640962] mt7921e 0000:01:00.0: Message 00000010 (seq 11) timeout
[ 138.640981] mt7921e 0000:01:00.0: Failed to get patch semaphore
[ 138.641202] mt7921e 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0002 address=0xfef07580 flags=0x0000]
[ 141.840513] ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)
[ 141.840603] mt7921e 0000:01:00.0: Message 00000010 (seq 12) timeout
[ 141.840618] mt7921e 0000:01:00.0: Failed to get patch semaphore
[ 145.041089] mt7921e 0000:01:00.0: Message 00000010 (seq 13) timeout
[ 145.041107] mt7921e 0000:01:00.0: Failed to get patch semaphore
[ 148.240599] mt7921e 0000:01:00.0: Message 00000010 (seq 14) timeout
[ 148.240618] mt7921e 0000:01:00.0: Failed to get patch semaphore
[ 148.240781] mt7921e 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0002 address=0xea365800 flags=0x0000]
[ 148.240805] mt7921e 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0002 address=0xea365800 flags=0x0000]
[ 148.240822] mt7921e 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0002 address=0xea365800 flags=0x0000]
[ 151.440715] mt7921e 0000:01:00.0: Message 00000010 (seq 15) timeout
[ 151.440734] mt7921e 0000:01:00.0: Failed to get patch semaphore
[ 154.640960] mt7921e 0000:01:00.0: Message 00000010 (seq 1) timeout
[ 154.640980] mt7921e 0000:01:00.0: Failed to get patch semaphore
[ 154.641161] mt7921e 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0002 address=0xda50f800 flags=0x0000]
[ 154.641185] mt7921e 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0002 address=0xda50f800 flags=0x0000]
[ 154.641202] mt7921e 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0002 address=0xda50f800 flags=0x0000]
[ 157.840980] mt7921e 0000:01:00.0: Message 00000010 (seq 2) timeout
[ 157.840998] mt7921e 0000:01:00.0: Failed to get patch semaphore
[ 161.040533] mt7921e 0000:01:00.0: Message 00000010 (seq 3) timeout
[ 161.040550] mt7921e 0000:01:00.0: Failed to get patch semaphore
[ 161.040578] mt7921e 0000:01:00.0: chip reset failed
[ 179.385270] mt7921e 0000:01:00.0: ASIC revision: 79220010
[ 179.465610] mt7921e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20231120183400a
perfmed a "RFBUMP" here by stopping iwd and networkmanage + doing a modprobe remove and re-add on `mt7921e`
[ 179.833448] mt7921e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20231120183441
[ 184.526895] wlan2: authenticate with <redacted> (local address=<redacted>)
[ 185.003676] wlan2: send auth to <redacted> (try 1/3)
[ 185.006749] wlan2: authenticated
[ 185.007144] wlan2: associate with <redacted> (try 1/3)
[ 185.020672] wlan2: RX AssocResp from <redacted> (capab=0x11 status=0 aid=2)
[ 185.047869] wlan2: associated
Same issue here, with Archlinux 6.7.4-arch1-1.
My dance after hibernation is: Enable flight mode, wait 1-2 secs, disable flight mode. If the Wifi won’t connect then, I’ll restart iwd and NetworkManager (NM is configured to use iwd as backend). Works 9 out of 10 times, my guess.
Sometimes, NetworkManager fails to connect but iwd still can. Connecting directly via iwctl often fixes this. Some helpful commands in iwctl are:
device wlan0 set-property Powered off
device wlan0 set-property Powered on
station wlan0 scan on
station wlan0 get-networks
station wlan0 connect <insertyouressidhere>
When all this fails, instead of a reboot, it’s still possible to reload the kernel module (as root):
modprobe -r mt7921e
modprobe mt7921e
Then restart iwd and NM again. The device name will change to the next higher number, e.g. from wlan0 to wlan1. This seems to confuse autoconnect but it’s possible to get a connection with iwctl.
1 Like
Oh, and seems like this will be fixed with 6.8, see here: [Framework 13 AMD] Issues with wireless after resume - #5 by mxsc
Sadly not fixed in 6.8.2.
True, I still have issues, too. But for a while now, somewhene after 6.8, just entering flight mode, waiting a few seconds and leaving flight mode again did the trick for me.
Sometimes I have to do it twice.
1 Like
I see really high power draw until I reboot. It seems to be related to bluetooth. Do you mean rfkill? I’ll give that a try.
I meant by enabling and disabling flight mode via Fn+F10.
I haven’t monitored power consumption, though. (How) did you measure it?
I use powertop. It’s not 100% accurate but pretty good on total power draw. I use sway so I would have to bind fn+10 to whatever your DE provides by default, my guess is it’s rfkill behind the scenes.
I’m on sway as well. Running grep -iR rfkill /etc/sway and grep -iR ~/.config/sway gave me nothing so I assume there is nothing configured (when I press the button, I get XF86RFkill from wev so the keybinding should be in there if it’s configured for sway.
In journalctl I only see messages from systemd, maybe that’s handling it directly. Anyway, pushing the button only triggers a soft block according to rfkill list.
I see quite some draw from btusb as well with powertop (689mW) so I guess that confirms that.
Yeah, assume you’re not using bluetooth, it should be ~0.
I’ve looked into this a bit more and I’ve found this section in the Arch wiki that might be of interest to you:
https://wiki.archlinux.org/title/Bluetooth#Default_adapter_power_state
Apparently, blueZ enables power for all Bluetooth adapters after suspend by default and this can be disabled.
In my case, after changing this, Bluetooth was still on after resume but I’m not sure if I haven’t set up some script somewhere that did it. Anyway, after running power off in bluetoothctl, my powertop device stats soon showed 0mW for btusb.
I had the same issue, what I did is to uninstall LXQt and install Plasma KDE. IDK why this fixed it.
I still have this issue on NixOS 24.05 using the latest kernel and disabling power to the bluetooth chipset.
Linux trystero 6.9.6 #1-NixOS SMP PREEMPT_DYNAMIC Fri Jun 21 12:40:40 UTC 2024 x86_64 GNU/Linux
Have you tried kernel 6.6? That worked for me until I swapped out my wifi card.
This is now fixed as of kernel 6.10.x