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

Framework Laptop 13 Linux
1

Final edit (2023-11-05):

It was solved by @Mario_Limonciello’s suggestion below, to set rtc_cmos.use_acpi_alarm=1 in the kernel settings. Not sure why, maybe they can explain, but I had it sleep for one hour, wake up, then hibernate last night perfectly.

Old text:

I just ran into this – If you’re using the AMD-specific wifi module (not AX210), and you happen to use suspend-then-hibernate (this makes it so your laptop after sleeping for e.g. 60 minutes, will hibernate instead, like a macbook does), there seems to be a bug that causes your computer to wake up after 5 minutes.

The workaround is here: Unexpected wake up when using suspend-then-hibernate · Issue #24279 · systemd/systemd · GitHub

To basically unload the mt7921e module before suspending (and reloading it after resume).

I’m sort of tempted to just swap the intel wifi card back in instead.

Edit: it appears to fix the supsend problem, but now the wifi doesn’t come back up. I’ll test more things…

Edit: so far, setting rtc_cmos.use_acpi_alarm=1 on the kernel seems to keep it sleeping more than 5 minutes.

1 Like
2

I am and have been using an mt7922 in my 11th gen for several months with suspend-then hibernate and the machine is operating properly. Currently running manjaro (yeah, I know. I am not motivated enough to set up and configure everything manually in order to run arch) with gnome, 6.6.0-1-Manjaro.

3

Hmm interesting, yeah it looks like the workaround isn’t great either, as the wifi doesn’t actually come back after a sleep. I’ll edit the post.

4

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?

5

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.

6

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.

7

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.

8

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

9

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

3 Likes
10

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

11

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
12

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
13

@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.

14

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
15

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

16

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
17

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

18

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
19

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

1 Like
20

Fantastic!