[RESPONDED] Arch hibernation woes on AMD 13

So have I, also tried setting the igpu back to game optimized but that doesn’t seem to have completely fixed it.

1 Like

Not hibernating at all is probably a separate issue

1 Like

Now it’s cracked 500 cycles, I don’t get it anymore.

I have changed absolutely nothing.

Edit: and now it froze after 530 cycles. On one hand I am glad I am not crazy and it just suddenly works, on the other hand it doesn’t just suddenly work XD.

1 Like

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

1 Like

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:

  1. Boot cleanly, run the aforementioned hibernate stress test for some cycles to vet that the behavior discussed previously is fixed.
  2. Suspend by running systemctl suspend. Alternatively, use something like amd_s2idle.py to easily wake up automatically after e.g. 10s. Resume.
  3. 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

  1. Set HibernateDelaySec=30 in /etc/systemd/sleep.conf.
  2. 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 :crossed_fingers:

I’m now on 6.9rc6 and hibernation is back working :grinning:.

On 6.8.8 it’s still broken…

1 Like

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
1 Like

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

3 Likes

Thank you @genosensor ! Testing this and it does feel more consistent :tada:

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

1 Like

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.

1 Like

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 :man_facepalming: (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.

1 Like