[RESOLVED] Systemd suspend-then-hibernate wakes up after 5 minutes

So to be clear, if you run systemctl suspend-then-hibernate, it doesn’t turn back on after 5 minutes?

Is your HibernateDelaySec set to less than 5 minutes?

Well, I swapped out the mt7922 with AX210 and it still wakes up after 5 minutes, so maybe it’s something else. I’ll go through what’s in /proc/acpi/wakeup one by one and see if one of them is the issue.

Went through all the /proc/acpi/wakeup and disabled all of them, still wakes up after 5 minutes.

I’m beginning to suspect that the RTC wakeup alarm isn’t working properly (that’s what gets set during suspend-then-hibernate), and is being set to 5 minutes every time.

Digging into the systemd code and looking at the debug log (by adding Environment=SYSTEMD_LOG_LEVEL=debug to /lib/systemd/system/systemd-suspend-then-hibernate.service , it appears it uses timerfd_create with CLOCK_BOOTTIME_ALARM, which does appear to be set to the correct value (1 hour, in my case), so something else is setting some type of alarm after 5 minutes, but regular suspend doesn’t cause this alarm for some reason.

Sorry, just caught back up to this. Please let me know if there is any info that I can provide that will help.

systemd 254.5.1-Manjaro
HibernateDelaySec=720min
IdleActionSec=15min

I typically have the machine sleep from being idle, or by closing the lid. I did set the automatic suspend parameters in the gnome gui to 30 and 45 minutes on battery and power, respectively, as it seemed to be conflicting with what I have set in logind.conf

try adding rtc_cmos.use_acpi_alarm=1 on your kernel command line

3 Likes

Just tested, still woke up after 5 minutes. I’ll boot up a fresh Fedora ISO to test next, probably.

Can you please double check it took by looking at /sys/module/rtc_cmos/parameters/use_acpi_alarm

I reproduced something like this and it seemed to help.

2 Likes

Holy crap it stayed in suspend for more than 5 minutes. Yeah I forgot to re-sign my EFI image with the new kernel commandline (using secure boot).

I’ll test this some more to see if other things break, and if actual suspend-then-hibernate works.

2 Likes

@Mario_Limonciello Is there some type of explanation for what this kernel param does, or how you found that this helps? (or a bug report somewhere?)

Or some type of indication what the bug may be (in hardware?), or perhaps why this doesn’t affect everyone, since this is the first I’m hearing of it, not related to the wifi card.

There was a really similar bug on Intel systems. I need to do some testing and I’ll send out a patch to set that by default if everything looks good.

2 Likes

So far it’s working great (I tested it a couple of cycles and it works as expected).

I’ve posted a patch for it to the mailing lists. It does the same thing as the module parameter. If that’s accepted, you can drop it when upgrading to a kernel that includes it.

[PATCH] rtc: cmos: Use ACPI alarm for non-Intel x86 systems too - Mario Limonciello (kernel.org)

3 Likes

Fedora 39 users, can you please help us test.

Please sudo dnf update

We’re wanting to test [kernel-6.5.12-300.fc39](https://bodhi.fedoraproject.org/updates/FEDORA-2023-03b11e7dcf) so merely updating should get you there.

Now:

sudo grubby --update-kernel=ALL --remove-args="rtc_cmos.use_acpi_alarm=1"

Then reboot.

Please try suspending, does it wake after 5 minutes with the parameter removed?
CC @Mario_Limonciello

Just tested this on my system.

  • 3.03 BIOS
  • sudo dnf update to 6.5.12-300.fc39
sudo grubby --update-kernel=ALL --remove-args="rtc_cmos.use_acpi_alarm=1"
  • Rebooted

Tested, success. This is working. Also passed the AMD_s2idle script test as well.

1 Like

Same here; BIOS 3.03, 10+ minutes of sound s2idle sleep.

1 Like

Fantastic!

This working really well on Fedora. Patched. All we need now is Ubuntu 22.04 OEM C and we’re on the right path.

Any luck on an Ubuntu patch or instructions on how to set the kernel flag on a 22.04 system? I’m seeing the same behavior with a sleep-then-shutdown script using rtcwake.

edit: just used the basic instructions from ubuntu here – Kernel/KernelBootParameters - Ubuntu Wiki and can confirm that on my 22.04 system running 6.2.0 AMD Framework 13 the rtc_cmos.use_acpi_alarm=1 kernel parmeter does seem to fix the interrupted suspend issue!

Also, for the benefit of anyone who finds this thread in the future, it seems this is a quick/easy way to test if the parameter is set correctly, it should return “Y”

$ cat /sys/module/rtc_cmos/parameters/use_acpi_alarm
Y
1 Like

Just as an update, the kernel parameter is not needed anymore after the linux kernel 6.8, which includes a fix for this.

Ubuntu 24.04 comes with this kernel