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…
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 
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 
(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
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.