Linux on Core Ultra: use_acpi_alarm=N breaks suspend-then-hibernate
Opened this issue · 8 comments
Device Information
System Model or SKU
Please select one of the following
- Framework Laptop 13 (11th Gen Intel® Core™)
- Framework Laptop 13 (12th Gen Intel® Core™)
- Framework Laptop 13 (13th Gen Intel® Core™)
- Framework Laptop 13 (AMD Ryzen™ 7040 Series)
- Framework Laptop 13 (Intel® Core™ Ultra Series 1)
- Framework Laptop 16 (AMD Ryzen™ 7040 Series)
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Framework
Product Name: Laptop 13 (Intel Core Ultra Series 1)
Version: A5
Serial Number: <REDACTED>
UUID: <REDACTED>
Wake-up Type: Power Switch
SKU Number: FRANDPCP05
Family: Laptop
BIOS VERSION
Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
Vendor: INSYDE Corp.
Version: 03.04
Release Date: 10/09/2024
Standalone Operation
Are you running your mainboard as a standalone device. Is standalone mode enabled in the BIOS?
- Yes
- No
Describe the bug
The Wake-up Type dmi entry on handle 1 isn't properly set when woken by an APM timer.
Steps To Reproduce
Steps to reproduce the behavior:
- Set
HibernateDelaySecin/etc/systemd/sleep.confto a short value for testing (e.g.1m). - Use
systemctl suspend-then-hibernate. - The system resumes after
HibernateDelaySecelapsed but doesn't hibernate. - Check
dmidecode --handle 1:
$ dmidecode --handle 1
# dmidecode 3.6
Getting SMBIOS data from sysfs.
SMBIOS 3.6 present.
54 structures occupying 4244 bytes.
Table at 0x5EDEE000.
Handle 0x0001, DMI type 1, 27 bytes
System Information
...
Wake-up Type: Power SwitchExpected behavior
The system should hibernate after HibernateDelaySec elapses.
systemd uses an APM timer to wake the system after HibernateDelaySec and uses the DMI "Wake-up Type" to determine whether the resume was caused by the timer set for hibernation or by the user. The framework doesn't indicate the proper Wake-up Type: APM Timer.
Operating System (please complete the following information):
- OS/Distribution: NixOS
- Version: nixos-unstable 2024-12-17
- Linux Kernel Version:
6.12.9
Additional context
-
Section "7.2.2 System -- Wake-up Type" in the SMBIOS Specification
I just closed the issue on the systemd side, since I believe it's a problem with the Framework Laptops firmware or at least with the way that the rtc_cmos driver in linux interprets the Frameworks FADT table. See systemd/systemd#35743 (comment)
This issue can be worked around by adding rtc_cmos.use_acpi_alarm=1 on the kernel commandline or adding a file to /etc/modprobe.d.
# /etc/modprobe.d/framework.conf
options rtc_cmos use_acpi_alarm=1
SMBIOS is generated at boot and doesn't change when waking from sleep, meaning the SMBIOS value is correct.
That's why there was this Linux change to enable use_acpi_alarm not only for Intel, but also modern AMD systems: torvalds/linux@3d762e2
So the key here is to figure out why use_acpi_alarm wasn't set for you.
Linux Kernel Version: 6.5.7
6.5 is quite old. For Intel Core Ultra Series 1 you should be running 6.9 at least.
Any reason you are using a recent NixOS unstable but such an old kernel?
Suspend and other things won't work with <6.9.
For this specific issue though, I also see the same problem as your on 6.13, I'm not sure why:
> cat /sys/module/rtc_cmos/parameters/use_acpi_alarm
N
Ok I found that it's not enabled because if (!is_hpet_enabled()) matches.
See dmesg: hpet: HPET dysfunctional in PC10. Force disabled.
On our AMD systems HPET is enabled (dmesg: clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484873504 ns).
I don't understand why that condition is there, as the function use_acpi_alarm_quirks is supposed to use the ACPI timer instead of HPET.
Linux Kernel Version: 6.5.7
6.5 is quite old. For Intel Core Ultra Series 1 you should be running 6.9 at least. Any reason you are using a recent NixOS unstable but such an old kernel? Suspend and other things won't work with <6.9.
I'm currently tinkering with Linux 6.5.7 for university and messed up. I was actually running Linux 6.12, now 6.12.9.
I don't understand why that condition is there, as the function
use_acpi_alarm_quirksis supposed to use the ACPI timer instead of HPET.
Here are the commit messages for the commit that originally introduced the quirk and the one that extended it to AMD systems for some context.
rtc: cmos: introduce quirks to enable use_acpi_alarm mode
commit 36d91a4d401c284ab21213622c85cd855725f10f
Author: Zhang Rui <rui.zhang@intel.com>
Date: Mon Mar 26 21:58:03 2018 +0800
rtc: cmos: introduce quirks to enable use_acpi_alarm mode
Use ACPI for RTC Alarm only for Intel platforms
1. with Low Power S0 support
2. with HPET RTC emulation enabled
3. no earlier than 2015
Note that, during the test, it is found that this patch
1. works in 4.15-rc kernel
2. hangs the platform after suspend-to-idle for 2 or 3 times, in 4.15.0
3. works again in 4.16-rc3 kernel.
4. works in the latest 4.15.12 stable kernel.
Thus although this patch breaks 4.15.0 kernel for some unknown reason,
still, it is safe for both upstream and backport.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
rtc: cmos: Use ACPI alarm for non-Intel x86 systems too
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: https://github.com/systemd/systemd/issues/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>
But I'm wondering now. I wasn't using ACPI for the boot alarm timer. I wasn't using the HPET (since it's disabled?). What timer was I using? 🤣
No idea 😅