[RESPONDED] Arch hibernation woes on AMD 13

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

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.

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.

Looks like resume from hibernate broke again after upgrading to 6.11 and 6.11.1, I’m using the package here on Arch: Arch Linux - linux 6.11.1.arch1-1 (x86_64)

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?)

Looks like 6.11.1 hit stable on arch. Anyone else have their hibernate working on their AMD 13?

I’m on 6.11.1 on Manjaro which is arch based and hibernation is still working on my AMD 13.

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)

Hmm, I too am using systemd-boot and LUKS encrypted btrfs.

I actually see my old screen pre-hibernate (on a test_resume, which apparently bypasses the firmware) but can’t interact with the system.

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?

I wonder if test_resume skips systemd-boot or not, I thought it just uses the same kernel and tests it:

# echo test_resume > /sys/power/disk
# echo disk > /sys/power/state

This fails for me on 6.11.1, this is my kernel cmdline (with linebreaks so it’s easier to read)

rd.luks.name=<redacted>=archroot
rd.luks.options=<redacted>=tpm2-device=auto
root=/dev/mapper/archroot
rootflags=subvol=@archroot
rw
quiet
resume=UUID=<redacted>
rd.luks.uuid=<redacted>
rd.luks.options=<redacted>=tpm2-device=auto
splash
vt.global_cursor_default=0
video=efifb:nobgrt
udev.children-max=1000

I have none of the rd.luks/resume bits in my cmdline, since recent versions of systemd can handle that (see using /etc/crypttab.initramfs for prepping the luks device, and systemd-hibernate-resume(8) — Arch manual pages for systemd automatically setting resume location)

I note you don’t have resume_offset in there, does that mean you’re using a swap partition? I’m using a swapfile

Some of this sounds like [SOLVED] Using Linux QEMU/KVM causes s2idle hard freeze on Arch - Linux 6.10.8 which is a systemd/kernel bug.

Doesn’t look like it’s the same thing, I tried the systemd dropins mentioned in that thread and still get a black screen when resuming from sleep.

Now, the fact that that thread reckons they fixed the issue in 6.11-rc7 makes me wonder if that fix is the source of the regression we’re seeing