Thank you @genosensor ! Testing this and it does feel more consistent
My setup:
Arch linux: 6.9.1-arch1-1
linux-firmware 20240510.b9d2bf23-1
Observing that on resume, wifi can take anywhere from ~5-30 seconds to reconnect.
If I try to systemctl hibernate during this period before wifi reconnects, hibernate tends to fail in the same manner as before adding the radios script.
Just adding my version (forum formatting, logger call)
❯ cat /lib/systemd/system-sleep/radios
#!/bin/sh
if [ "$1" == "pre" ]; then
logger "$0 - radios pre"
rfkill block all
sleep 1
modprobe -r $wifi
fi
if [ "$1" == "post" ]; then
logger "$0 - radios post"
modprobe $wifi
sleep 1
rfkill unblock all
fi
For anyone giving this a shot also make sure to sudo chmod +x /lib/systemd/system-sleep/radios
I haven’t tested hibernating while WiFi is connecting.
You might try replacing the first ‘sleep 1’ in the script with ‘sleep 5’.
This might ensure that the WiFi driver was inactive before removing it.
Also confirming that hibernate has continued to be consistent after a few days of having HandleLidSwitch=hibernate set with the /lib/systemd/system-sleep/radios script installed.
Interested in root cause because I have to imagine this will keep affecting people that enable hibernate.
Just realized a dumb mistake I made. The original script from @genosensor has a $wifi var that is not defined. Me the user should be providing it (found/tested by dumping $wifi in the logger debug string)
So effectively i’ve just been using this script from the beginning:
#!/bin/sh
if [ "$1" == "pre" ]; then
rfkill block all
sleep 1
fi
if [ "$1" == "post" ]; then
sleep 1
rfkill unblock all
fi
And it was still effective at making hibernate consistent!
Here is my final version with $wifi defined - and robust if you want to run with empty var.
#!/bin/sh
# grab this from lspci or lshw (driver=$wifi)
wifi="mt7921e"
logger "$0 - radios $1. wifi: $wifi"
if [ "$1" == "pre" ]; then
rfkill block all
sleep 1
[ -n "$wifi" ] && modprobe -r $wifi
fi
if [ "$1" == "post" ]; then
[ -n "$wifi" ] && modprobe $wifi
sleep 1
rfkill unblock all
fi
Lastly, there are two other related threads that seem to cover same issue.
I was not seeing the CTRL-EVENT-SIGNAL-CHANGE messages on 6.9.12 but they started appearing when I upgraded to 6.10.3. Although I do not have any issues with hibernation and my wifi connection appears to be stable.
It was working as of 6.10. Anyone know of a good way to get debug logs for resume, or is that not technically feasible (outside of having a serial port, does the FW AMD 13 have one?)
Another day, another time I’ve pulled my Framework out of my backpack to find it hot to the touch and at 2% battery. For $1400, this is extremely disappointing.
Given that over 30 days have elapsed since staff’s last comment on a BIOS update, I think customers are owed a clear, prompt answer on when this is going to be released.
I’m in the same place as you. Both CachyOS (with either arch or cachyos kernel) and NixOS don’t hibernate/resume properly when running a 6.11 kernel, but resume fine with a 6.10 kernel
Elaborating somewhat - using a swapfile on a LUKS encrypted btrfs partition, systemd initrd instead of busybox, and letting systemd detect and write the HibernateLocation EFI var (meaning no kernel parameters for resume+resume_offset)
I’m using ext4 and lvm on luks with a swap file and grub boot. Hibernation works very reliable here on 6.11.1. Maybe the systemd-boot cause this problem?
(found/tested by dumping