On my AMD framework 13, running systemdctl suspend-then-hibernate only suspends for 5 minutes, then wakes up. It’s consistently 5 minutes, and journalctl shows this happening even if the lid is closed - it suspends for 5 minutes, wakes up, then suspends again because the lid is closed.
In /etc/systemd/sleep.conf, I have
HibernateDelaySec=90min
SuspendEstimationSec=60min
So it should suspend for 60 minutes, wake up to check battery percentage, then go back to sleep for half an hour, then go into hibernate. In practice, it never reaches hibernate - the suspend-wake-suspend cycle evidently interrupts that process.
Here’s log files with dmesg and journalctl entries:
EDIT: Unexpected wake up when using suspend-then-hibernate · Issue #24279 · systemd/systemd · GitHub - this has helped the matter - disabling the wifi driver on suspend-then-hibernate, the laptop now successfully stays in suspend when running suspend-then-hibernate. It has the annoying side-effect of renaming the interface when it comes back up. I’m using MACAddress in the [Match] section of the systemd-networkd configuration and it doesn’t affect anything to have the interface name incrementing each time. Just a bit weird, but it works - It even drops into hibernate correctly.
I’ve found that my system is able to suspend, and it is able to hibernate, but suspend-then-hibernate does not transition to hibernation after the delay period. I have a similar log output, where the system seems to be waking up every five minutes or so. I tried the modprobe script fix but it doesn’t stop the wakeups, and often it gets the wifi chip into a state where I have to fully reboot to get it working again.
A comment from a few hours ago on the linked github issue suggested adding rtc_cmos.use_acpi_alarm=1 to disable HPET for wakeups. this seems to have worked for me (I also removed the hack systemd modprobe script).
Great find. I’ve also added that kernel parameter, and removed the modprobe hack. This seems to have stopped the suspend wakeups, I’ll report back on whether it also lets it go into full hibernation afterwards.
Yep, that’s working here too. Managed to lose 3% over 20 hours with my setup, because it only slept for a couple of hours before entering hibernate. The wireless connection is now stable on wake too.
Confirming with everyone, you’ve tested rtc_cmos.use_acpi_alarm=1 to disable HPET for wakeups as a kernel parameter and this workaround is helping, correct?