Unexpected wake up when using suspend-then-hibernate #24279

AlvinZhu · 2022-08-11T11:23:43Z

systemd version the issue has been seen with

251.4-1

Used distribution

Arch Linux

Linux kernel version used

5.18.16-arch1-1

CPU architectures issue was seen on

x86_64

Component

systemctl, systemd

Expected behaviour you didn't see

After systemctl suspend-then-hibernate, system suspend(s2idle), after HibernateDelaySec=180min, system hibernate.

Unexpected behaviour you saw

After systemctl suspend-then-hibernate, system automatically wakes up after 5minutes
Problem doesn't occur on regular suspend but only on suspend-then-hibernate

others has same issues:
https://bbs.archlinux.org/viewtopic.php?id=275965
https://unix.stackexchange.com/questions/705416/the-computer-wakes-up-every-5-minutes

my laptop is HP 845 G9
CPU: AMD Ryzen 6850HS
S3 Sleep State is not support. Only Modern Standby(s2idle) and Hibernate works.

Steps to reproduce the problem

run systemctl suspend-then-hibernate
then wait for 5 minutes. system automatically wakes up

Additional program output to the terminal or log subsystem illustrating the issue

$ journalctl --no-pager -b 0 | grep -E "(systemd|kernel)"
Aug 11 18:54:52 Alvin-Laptop systemd[1]: Starting Network Manager Script Dispatcher Service...
Aug 11 18:54:52 Alvin-Laptop systemd[1]: Started Network Manager Script Dispatcher Service.
Aug 11 18:54:52 Alvin-Laptop kernel: wlp1s0: deauthenticating from ... by local choice (Reason: 3=DEAUTH_LEAVING)
Aug 11 18:54:52 Alvin-Laptop systemd-resolved[1039]: wlp1s0: Bus client reset search domain list.
Aug 11 18:54:52 Alvin-Laptop systemd-resolved[1039]: wlp1s0: Bus client set default route setting: no
Aug 11 18:54:52 Alvin-Laptop systemd-resolved[1039]: wlp1s0: Bus client reset DNS server list.
Aug 11 18:54:52 Alvin-Laptop systemd[1]: Reached target Sleep.
Aug 11 18:54:52 Alvin-Laptop systemd[1]: Starting RyzenAdj Service...
Aug 11 18:54:52 Alvin-Laptop systemd[1]: Starting Suspend; Hibernate if not used for a period of time...
Aug 11 18:54:52 Alvin-Laptop systemd[1]: ryzenadj.service: Deactivated successfully.
Aug 11 18:54:52 Alvin-Laptop systemd[1]: Finished RyzenAdj Service.
Aug 11 18:54:53 Alvin-Laptop systemd-sleep[9569]: bluetooth = off (software)
Aug 11 18:54:53 Alvin-Laptop systemd-sleep[9563]: Entering sleep state 'suspend'...
Aug 11 18:54:53 Alvin-Laptop kernel: PM: suspend entry (s2idle)
Aug 11 18:54:53 Alvin-Laptop kernel: Filesystems sync: 0.028 seconds
Aug 11 18:59:54 Alvin-Laptop kernel: Freezing user space processes ... (elapsed 0.002 seconds) done.
Aug 11 18:59:54 Alvin-Laptop kernel: OOM killer disabled.
Aug 11 18:59:54 Alvin-Laptop kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Aug 11 18:59:54 Alvin-Laptop kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Aug 11 18:59:54 Alvin-Laptop kernel: ACPI: EC: interrupt blocked
Aug 11 18:59:54 Alvin-Laptop kernel: ACPI: EC: interrupt unblocked
Aug 11 18:59:54 Alvin-Laptop kernel: hpet_rtc_timer_reinit: 1039 callbacks suppressed
Aug 11 18:59:54 Alvin-Laptop kernel: hpet: Lost 9448 RTC interrupts
Aug 11 18:59:54 Alvin-Laptop kernel: [drm] PCIE GART of 512M enabled (table at 0x000000F4008CA000).
Aug 11 18:59:54 Alvin-Laptop kernel: amdgpu 0000:63:00.0: amdgpu: SMU is resuming...
Aug 11 18:59:54 Alvin-Laptop kernel: amdgpu 0000:63:00.0: amdgpu: dpm has been enabled
Aug 11 18:59:54 Alvin-Laptop kernel: amdgpu 0000:63:00.0: amdgpu: SMU is resumed successfully!
Aug 11 18:59:54 Alvin-Laptop kernel: i2c_hid_acpi i2c-ELAN0767:00: i2c_hid_get_input: incomplete report (14/65280)
Aug 11 18:59:54 Alvin-Laptop kernel: nvme nvme0: Shutdown timeout set to 10 seconds
Aug 11 18:59:54 Alvin-Laptop kernel: [drm] Watermarks table not configured properly by SMU
Aug 11 18:59:54 Alvin-Laptop kernel: nvme nvme0: 16/0/0 default/read/poll queues
Aug 11 18:59:54 Alvin-Laptop kernel: [drm] VCN decode and encode initialized successfully(under DPG Mode).
Aug 11 18:59:54 Alvin-Laptop kernel: [drm] JPEG decode initialized successfully.
Aug 11 18:59:54 Alvin-Laptop kernel: amdgpu 0000:63:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on hub 0
Aug 11 18:59:54 Alvin-Laptop kernel: amdgpu 0000:63:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0
Aug 11 18:59:54 Alvin-Laptop kernel: amdgpu 0000:63:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0
Aug 11 18:59:54 Alvin-Laptop kernel: amdgpu 0000:63:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 5 on hub 0
Aug 11 18:59:54 Alvin-Laptop kernel: amdgpu 0000:63:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 6 on hub 0
Aug 11 18:59:54 Alvin-Laptop kernel: amdgpu 0000:63:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 7 on hub 0
Aug 11 18:59:54 Alvin-Laptop kernel: amdgpu 0000:63:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 8 on hub 0
Aug 11 18:59:54 Alvin-Laptop kernel: amdgpu 0000:63:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 9 on hub 0
Aug 11 18:59:54 Alvin-Laptop kernel: amdgpu 0000:63:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 10 on hub 0
Aug 11 18:59:54 Alvin-Laptop kernel: amdgpu 0000:63:00.0: amdgpu: ring kiq_2.1.0 uses VM inv eng 11 on hub 0
Aug 11 18:59:54 Alvin-Laptop kernel: amdgpu 0000:63:00.0: amdgpu: ring sdma0 uses VM inv eng 12 on hub 0
Aug 11 18:59:54 Alvin-Laptop kernel: amdgpu 0000:63:00.0: amdgpu: ring vcn_dec_0 uses VM inv eng 0 on hub 1
Aug 11 18:59:54 Alvin-Laptop kernel: amdgpu 0000:63:00.0: amdgpu: ring vcn_enc_0.0 uses VM inv eng 1 on hub 1
Aug 11 18:59:54 Alvin-Laptop kernel: amdgpu 0000:63:00.0: amdgpu: ring vcn_enc_0.1 uses VM inv eng 4 on hub 1
Aug 11 18:59:54 Alvin-Laptop kernel: amdgpu 0000:63:00.0: amdgpu: ring jpeg_dec uses VM inv eng 5 on hub 1
Aug 11 18:59:54 Alvin-Laptop kernel: OOM killer enabled.
Aug 11 18:59:54 Alvin-Laptop kernel: Restarting tasks ... done.
Aug 11 18:59:54 Alvin-Laptop systemd-resolved[1039]: Clock change detected. Flushing caches.
Aug 11 18:59:54 Alvin-Laptop systemd-resolved[1039]: Switching to fallback DNS server 1.1.1.1#cloudflare-dns.com.
Aug 11 18:59:54 Alvin-Laptop systemd-sleep[9563]: System returned from sleep state.
Aug 11 18:59:54 Alvin-Laptop kernel: PM: suspend exit
Aug 11 18:59:54 Alvin-Laptop systemd[1]: Starting autorandr execution hook...
Aug 11 18:59:54 Alvin-Laptop systemd[1]: autorandr.service: Deactivated successfully.
Aug 11 18:59:54 Alvin-Laptop systemd[1]: Finished autorandr execution hook.
Aug 11 18:59:57 Alvin-Laptop systemd-sleep[9898]: bluetooth = on
Aug 11 18:59:57 Alvin-Laptop systemd[1]: systemd-suspend-then-hibernate.service: Deactivated successfully.
Aug 11 18:59:57 Alvin-Laptop systemd[1]: Finished Suspend; Hibernate if not used for a period of time.
Aug 11 18:59:57 Alvin-Laptop systemd[1]: Stopped target Sleep.
Aug 11 18:59:57 Alvin-Laptop systemd[1]: Reached target Suspend; Hibernate if not used for a period of time.
Aug 11 18:59:57 Alvin-Laptop systemd[1]: Stopped target Suspend; Hibernate if not used for a period of time.
Aug 11 18:59:57 Alvin-Laptop systemd-logind[1089]: Operation 'sleep' finished.
Aug 11 19:00:02 Alvin-Laptop systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.

$ cat /sys/power/mem_sleep   
[s2idle]

The text was updated successfully, but these errors were encountered:

AlvinZhu · 2022-08-12T09:58:35Z

I fix this issue by replace the Qualcomm FastConnect 6900 WiFi card with Intel AX210.
and I also disabled WWAN(Fibocom L860-GL Intel XMM 7560) in BIOS, since it break suspend.

renzhamin · 2022-08-14T17:30:50Z

Yet another mediatek driver issue, suspend-then-hibernate works properly if we unload the driver beforehand hence a quick workaround with a systemd service file

echo \
"[Unit]
Before=suspend-then-hibernate.target
StopWhenUnneeded=yes

[Service]
Type=oneshot
StandardOutput=syslog
RemainAfterExit=yes
ExecStart=/bin/modprobe -r mt7921e
ExecStop=/bin/modprobe mt7921e

[Install]
WantedBy=suspend-then-hibernate.target" | \
sudo tee /etc/systemd/system/hack-suspend-then-hibernate.service &&
sudo systemctl enable hack-suspend-then-hibernate.service

superm1 · 2023-11-05T04:24:34Z

Sorry to necro bump this bug, but I might know what's going on and I'd like if you guys can confirm it.

Those of you guys affected by this issue can you please experiment with rtc_cmos.use_acpi_alarm=1 on the kernel command line? Does it fix the issue?

kishorviswanathan · 2023-11-05T09:39:28Z

@superm1 Thank you so much. You are a lifesaver. That works perfectly fine. I recently upgraded my laptop and I was so annoyed that laptop manufacturers got rid of s3 standby and the s2idle was a real pain for me. On top of that suspend-then-hibernate was also waking up every 5 mins draining the battery significantly. With this kernel parameter, it's fixed.

Could you please tell us what it does and how it fixed the issue ?

Intel systems > 2015 have been configured to use ACPI alarm instead of HPET to avoid s2idle issues. Having HPET programmed for wakeup causes problems on AMD systems with s2idle as well. One particular case is that the systemd "SuspendThenHibernate" feature doesn't work properly on the Framework 13" AMD model. Switching to using ACPI alarm fixes the issue. Adjust the quirk to apply to AMD/Hygon systems from 2021 onwards. This matches what has been tested and is specifically to avoid potential risk to older systems. Cc: stable@vger.kernel.org # 6.1+ Reported-by: alvin.zhuge@gmail.com Reported-by: renzhamin@gmail.com Closes: systemd/systemd#24279 Reported-by: Kelvie Wong <kelvie@kelvie.ca> Closes: https://community.frame.work/t/systemd-suspend-then-hibernate-wakes-up-after-5-minutes/39392 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>

superm1 · 2023-11-06T17:01:16Z

Thanks for confirming! I've posted a patch up to the mailing list for review to set this policy by default.

https://lore.kernel.org/linux-kernel/20231106162310.85711-1-mario.limonciello@amd.com/

Intel systems > 2015 have been configured to use ACPI alarm instead of HPET to avoid s2idle issues. Having HPET programmed for wakeup causes problems on AMD systems with s2idle as well. One particular case is that the systemd "SuspendThenHibernate" feature doesn't work properly on the Framework 13" AMD model. Switching to using ACPI alarm fixes the issue. Adjust the quirk to apply to AMD/Hygon systems from 2021 onwards. This matches what has been tested and is specifically to avoid potential risk to older systems. Cc: <stable@vger.kernel.org> # 6.1+ Reported-by: <alvin.zhuge@gmail.com> Reported-by: <renzhamin@gmail.com> Closes: systemd/systemd#24279 Reported-by: Kelvie Wong <kelvie@kelvie.ca> Closes: https://community.frame.work/t/systemd-suspend-then-hibernate-wakes-up-after-5-minutes/39392 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20231106162310.85711-1-mario.limonciello@amd.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>

commit 3d762e2 upstream. Intel systems > 2015 have been configured to use ACPI alarm instead of HPET to avoid s2idle issues. Having HPET programmed for wakeup causes problems on AMD systems with s2idle as well. One particular case is that the systemd "SuspendThenHibernate" feature doesn't work properly on the Framework 13" AMD model. Switching to using ACPI alarm fixes the issue. Adjust the quirk to apply to AMD/Hygon systems from 2021 onwards. This matches what has been tested and is specifically to avoid potential risk to older systems. Cc: <stable@vger.kernel.org> # 6.1+ Reported-by: <alvin.zhuge@gmail.com> Reported-by: <renzhamin@gmail.com> Closes: systemd/systemd#24279 Reported-by: Kelvie Wong <kelvie@kelvie.ca> Closes: https://community.frame.work/t/systemd-suspend-then-hibernate-wakes-up-after-5-minutes/39392 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20231106162310.85711-1-mario.limonciello@amd.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

BugLink: https://bugs.launchpad.net/bugs/2059068 commit 3d762e2 upstream. Intel systems > 2015 have been configured to use ACPI alarm instead of HPET to avoid s2idle issues. Having HPET programmed for wakeup causes problems on AMD systems with s2idle as well. One particular case is that the systemd "SuspendThenHibernate" feature doesn't work properly on the Framework 13" AMD model. Switching to using ACPI alarm fixes the issue. Adjust the quirk to apply to AMD/Hygon systems from 2021 onwards. This matches what has been tested and is specifically to avoid potential risk to older systems. Cc: <stable@vger.kernel.org> # 6.1+ Reported-by: <alvin.zhuge@gmail.com> Reported-by: <renzhamin@gmail.com> Closes: systemd/systemd#24279 Reported-by: Kelvie Wong <kelvie@kelvie.ca> Closes: https://community.frame.work/t/systemd-suspend-then-hibernate-wakes-up-after-5-minutes/39392 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20231106162310.85711-1-mario.limonciello@amd.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Portia Stephens <portia.stephens@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

JIRA: https://issues.redhat.com/browse/RHEL-19606 commit 3d762e21d56370a43478b55e604b4a83dd85aafc Author: Mario Limonciello <mario.limonciello@amd.com> Date: Mon Nov 6 10:23:10 2023 -0600 rtc: cmos: Use ACPI alarm for non-Intel x86 systems too Intel systems > 2015 have been configured to use ACPI alarm instead of HPET to avoid s2idle issues. Having HPET programmed for wakeup causes problems on AMD systems with s2idle as well. One particular case is that the systemd "SuspendThenHibernate" feature doesn't work properly on the Framework 13" AMD model. Switching to using ACPI alarm fixes the issue. Adjust the quirk to apply to AMD/Hygon systems from 2021 onwards. This matches what has been tested and is specifically to avoid potential risk to older systems. Cc: <stable@vger.kernel.org> # 6.1+ Reported-by: <alvin.zhuge@gmail.com> Reported-by: <renzhamin@gmail.com> Closes: systemd/systemd#24279 Reported-by: Kelvie Wong <kelvie@kelvie.ca> Closes: https://community.frame.work/t/systemd-suspend-then-hibernate-wakes-up-after-5-minutes/39392 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20231106162310.85711-1-mario.limonciello@amd.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Čestmír Kalina <ckalina@redhat.com>

MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/3725 JIRA: https://issues.redhat.com/browse/RHEL-19606 ``` commit 3d762e21d56370a43478b55e604b4a83dd85aafc Author: Mario Limonciello <mario.limonciello@amd.com> Date: Mon Nov 6 10:23:10 2023 -0600 rtc: cmos: Use ACPI alarm for non-Intel x86 systems too Intel systems > 2015 have been configured to use ACPI alarm instead of HPET to avoid s2idle issues. Having HPET programmed for wakeup causes problems on AMD systems with s2idle as well. One particular case is that the systemd "SuspendThenHibernate" feature doesn't work properly on the Framework 13" AMD model. Switching to using ACPI alarm fixes the issue. Adjust the quirk to apply to AMD/Hygon systems from 2021 onwards. This matches what has been tested and is specifically to avoid potential risk to older systems. Cc: <stable@vger.kernel.org> # 6.1+ Reported-by: <alvin.zhuge@gmail.com> Reported-by: <renzhamin@gmail.com> Closes: systemd/systemd#24279 Reported-by: Kelvie Wong <kelvie@kelvie.ca> Closes: https://community.frame.work/t/systemd-suspend-then-hibernate-wakes-up-after-5-minutes/39392 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20231106162310.85711-1-mario.limonciello@amd.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> ``` Signed-off-by: Čestmír Kalina <ckalina@redhat.com> Approved-by: Waiman Long <longman@redhat.com> Approved-by: Michael Petlan <mpetlan@redhat.com> Merged-by: Čestmír Kalina <ckalina@redhat.com>

AlvinZhu added the bug 🐛 Programming errors, that need preferential fixing label Aug 11, 2022

github-actions bot added pid1 systemctl labels Aug 11, 2022

AlvinZhu closed this as completed Aug 12, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Unexpected wake up when using suspend-then-hibernate #24279

Unexpected wake up when using suspend-then-hibernate #24279

AlvinZhu commented Aug 11, 2022 •

edited

AlvinZhu commented Aug 12, 2022

renzhamin commented Aug 14, 2022

superm1 commented Nov 5, 2023

kishorviswanathan commented Nov 5, 2023 •

edited

superm1 commented Nov 6, 2023

Unexpected wake up when using suspend-then-hibernate #24279

Unexpected wake up when using suspend-then-hibernate #24279

Comments

AlvinZhu commented Aug 11, 2022 • edited

systemd version the issue has been seen with

Used distribution

Linux kernel version used

CPU architectures issue was seen on

Component

Expected behaviour you didn't see

Unexpected behaviour you saw

Steps to reproduce the problem

Additional program output to the terminal or log subsystem illustrating the issue

AlvinZhu commented Aug 12, 2022

renzhamin commented Aug 14, 2022

superm1 commented Nov 5, 2023

kishorviswanathan commented Nov 5, 2023 • edited

superm1 commented Nov 6, 2023

AlvinZhu commented Aug 11, 2022 •

edited

kishorviswanathan commented Nov 5, 2023 •

edited