I am unable to reconnect to my wifi after hibernating, even if I cycle the card completely (e.g. turn it off and on using nmcli). The logs seem to be stuck in auth timeout cycle. Rebooting works and everything starts up ok so it’s really odd.
IWD seems to have the same issue, works first time / over reboots but fails after hibernation. Is anything known about this issue?
Do we have a distro release and kernel version? Looks like you’re on the latest firmware for the Mediatek card, but I’d like to understand what distro you’re on.
Arch Linux running 6.7.4-arch1-1 #1 SMP PREEMPT_DYNAMIC x86_64 GNU/Linux
Nothing custom about it (e.g. stock Arch kernel). I played around with IWD a bit more and I can get network working with iwd after hibernation, using iwd as the NetworkManager backend, BUT only if I manually “disanble and reenable” wifi and connect again.
Understood. I am not on Arch and have not tested it against it (as it’s purely community support), however is this happening with the new firmware? Looks like you have a 20231120183441 build which is newer and correct.
In a pinch, while kludgy, you could roll a systemd service to look for a resume state, rfkill disable and enable your wifi. I’ve done this in the past when connecting or disconnecting from AC power (this was sometime ago).
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…
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.
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:
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.
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.
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.
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.