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=1000I 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
Yes, I am using a swap partition (encrypted with the keys in a TPM)
Some more attempts to narrow things down:
Tried my nixos config on my old 11th-gen Intel Zenbook (barring the Framework/AMD specific bits). That resumed with no issues.
Tried udev based HOOKS=, resume didn’t work
Just tested 6.11.2 and I see the same behaviour. Using 6.10.12 for now.
1 Like
This is also what I was experiencing and downgrading to 6.10 worked for me as well
Anyone have any idea how to debug this? Or which kernel mailing list to post this to? I’ve built many kernels in my lifetime so I’m more than happy to help debug.
6.11.3 had some interesting patch notes, so I gave it a try. With both the arch version in core-testing, and the cachyos-znver4 version from cachyos, I get exactly 1 successful resume. After that, black screen every time, including after a fresh hibernate.
I’ve also had that same behaviour once by stopping fprintd.service before hibernating, but again, I’m completely unable to reproduce this.
FWIW ubuntu 24.10 (kernel 6.11.0) also freezes on resume from hibernate for me. I’ve never had that working though, so can’t rule out the possibility that I just set it up wrong
I did two test hibernates
# echo test_resume > /sys/power/disk
# echo disk > /sys/power/state
in a row and it seems to work on arch 6.11.3, going to try a real one now.
Edit: Did an actual systemctl hibernate on 6.11.3 and it did not come back up. I’ll just revert back rather than test it some more.