Probably over 100 is enough for a normal use-case for hibernate unless you don’t reboot your laptop for months on end.
Honestly I never had it happen in normal use before
no comment XD
Is anyone else still having issues with hibernate specifically and only after suspending?
I have suspend-then-hibernate configured, and am frequently coming back to an empty battery after suspending the system and then walking away. The system suspends properly, but locks up after waking and then attempting to hibernate.
On arch 6.8.7, bios 3.05, and I can reproduce/demonstrate the problem the following way:
- Boot cleanly, run the aforementioned hibernate stress test for some cycles to vet that the behavior discussed previously is fixed.
- Suspend by running
systemctl suspend
. Alternatively, use something like amd_s2idle.py to easily wake up automatically after e.g. 10s. Resume. - Run the stress test again. After 1-2 cycles, the system locks up with a black screen, but keyboard and power LEDs are still lit. If not, suspend and resume again, then run the stress test again.
Or
- Set
HibernateDelaySec=30
in/etc/systemd/sleep.conf
. - Run
systemctl suspend-then-hibernate
1-2 times until it locks up.
Anecdotally, this issue also seems to occur more often when the system wakes itself via rtc, but I’ve not done extensive testing of this.
I have the same problem on arch. Maybe it’s not the same problem as discussed here?
I have an luks partition with lvm on it and a swapfile on the lvm-root partition (ext4).
No problems with hibernation on 6.6.x. Work’s very reliable.
With the exact same configuration on 6.8.x or 6.9rc[1-5] after systemctl hibernate
the screen turns black for about 10-15 seconds and then the screensaver screen shows up…
dmesg
shows:
[ 892.144251] PM: Cannot find swap device, try swapon -a
[ 892.144253] PM: Cannot get swap writer
But swapon
shows:
NAME TYPE SIZE USED PRIO
/swapfile file 32G 0B -2
So the reason why hibernation fails is obvious. For some reason hibernate to swapfile is no longer working although nothing in the configuration changed except the kernel.
But sadly I wasn’t able to find any information or bugreport on the net. This error is only known with swapfiles on btrfs-partitions and dracut (i’m using mkinitcpio) but not on ext4.
Maybe someone has a hint for me how to further debug this?
I have ran hibernate to sapfiles on btrfs and ext4 under luks on 6.8.x and both worked (with the crash after a bunch of cycles issue discussed here though).
@Mistral24, you describe exactly the issues I have (including reliable hibernation w/kernel 6.6x and failed hibernation w/ swapfile error messages w/kernel 6.8+) using Manjaro with grub and standard ext4 partitions. Something in kernel 6.8+ is off.
Confirming that I’m still seeing same behavior (hibernate fails intermittently) after updating to 3.05 bios on Arch 6.8.8.
But looks like the upstream bios issue is still in progress
I’m now on 6.9rc6 and hibernation is back working .
On 6.8.8 it’s still broken…
Finally, hibernation works on 6.8.9!
I’m running Arch on 6.8.9 and BIOS 3.05 and still get freezes on every hibernation to a swapfile.
Update: Adding the following to /etc/systemd/sleep.conf
solved my issue:
[Sleep]
HibernateMode=shutdown
After trying almost all the suggestions in this thread to achieve reliable hibernation and resume, this is what worked for me:
Kernel 6.8.11
Linux-firmware 20240513
scripts in /lib/systemd/system-sleep to disable WiFi and Bluetooth before hibernation.
----- /lib/systemd/system-sleep/radios ------
#!/bin/shcase “$1” in
pre)
rfkill block all
sleep 1
modprobe -r $wifi
;;
post)
modprobe $wifi
sleep 1
rfkill unblock all
esac
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.
Switched from kernel 6.8.11 to 6.8.9 after encountering this bug:
[Re: [BUG] Linux 6.8.10 NPE - Linux regression tracking (Thorsten Leemhuis)](https://[BUG] Linux 6.10)
For me, kernel versions >=6.9 output log messages from wpa_supplicant every 3 seconds like this:
`wpa_supplicant[…]: wlanX: CTRL-EVENT-SIGNAL-CHANGE …
Is anyone else running kernel >=6.9 NOT seeing these messages from:
journalctl -f
?
Running Debian12 (Bookworm)
I am on 6.9.3-arch1-1
and do not see these messages constantly appearing while tailling.
Here’s output from lshw
❯ sudo lshw -C network
*-network
description: Wireless interface
product: MT7922 802.11ax PCI Express Wireless Network Adapter
vendor: MEDIATEK Corp.
physical id: 0
bus info: pci@0000:01:00.0
logical name: wlan0
logical name: /dev/fb0
version: 00
serial: REDACT
width: 64 bits
clock: 33MHz
capabilities: pciexpress msi pm bus_master cap_list ethernet physical wireless fb
configuration: broadcast=yes depth=32 driver=mt7921e driverversion=6.9.3-arch1-1 firmware=____000000-20240409163347 ip=192.168.1.101 latency=0 link=yes mode=2256x1504 multicast=yes visual=truecolor wireless=IEEE 802.11 xres=2256 yres=1504
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.
Thanks all, improving on all the above, this works for me:
#!/bin/sh
##
## URL: https://community.frame.work/t/responded-arch-hibernation-woes-on-amd-13/45474/65
## FILE: /lib/systemd/system-sleep/archlinux-fw13-amd-radios.sh
##
# grab this from lspci or lshw (driver=$wifi)
wifi="mt7921e"
/usr/bin/logger "$0 - radios $1. wifi: $wifi"
if [ "$1" == "pre" ]; then
/usr/bin/rfkill block all
/usr/bin/sleep 1
[ -n "$wifi" ] && /usr/bin/modprobe -r $wifi
fi
if [ "$1" == "post" ]; then
[ -n "$wifi" ] && /usr/bin/modprobe $wifi
/usr/bin/sleep 1
/usr/bin/rfkill unblock all
/usr/bin/systemctl restart NetworkManager.service
fi
This script works perfectly as long as $wifi is named properly (framework 13 amd…): mt7921e.
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.
Running Debian sid.