Which release version?
(if rolling release without a release version, skip this question)
(If rolling release, last date updated?) 2025-06-08
Which kernel are you using? 6.14.6
Which BIOS version are you using? 3.03
Which Framework Laptop 13 model are you using?
AMD Ryzen™ AI 300 Series
I noticed that my laptop continues to consume power even when I close the lid. I want to switch from S0 suspend to S3 suspend, but I found that “deep” is not listed as an option:
cat /sys/power/mem_sleep
[s2idle]
Is this because AMD CPUs don’t support it? I couldn’t find a CPU datasheet on AMD’s website — unlike Intel, which provides them.
If S3 suspend isn’t possible, what’s the recommended approach? Hibernate on Linux seems to have some issues and is generally not recommended.
Yes. Modern CPUs, especially the mobile ones no longer support S3. Even Intel has long removed that support, they just did not strip it out of their firmware, because they still do support it officially for desktop CPUs. But since its no longer maintained and not officially supported it also has been severely broken even with the oldest FW13.
But also, if the hardware is built right and the software supports it, Modern Standby will not waste more power than S3, it is just a lot more flexible. The actual ACPI bit that tells Windows for example to use Modern Standby is actually defined as “Modern Standby is at least as power efficient as S3”. That is how the CPUs were built. All the rest is down to the components on the mainboard and which of them the OS actually powered down how much and how often it wakes back up for maintenance.
From reports, Modern Standby support is better on Linux for AMD, because there has been no more choice for people to hack them back to halfway broken S3 as with Intel systems.
S2Idle was more efficient under Linux than under Windows with the 7040 / Phoenix boards, because Linux does not understand Modern Standby and cannot wake back up in the background, while Windows actually wakes up for maintenance and checks, which consume power.
And still, nobody cares to invest enough money into Linux desktop to support what Modern Standby enables. Even though it has been clear for over 3 years.
If you have problems with s2idle on AMD; please use Client Challenge to generate a report and share it somewhere. It will catch “common” problems for you and tell you about them and what to do.
And still, nobody cares to invest enough money into Linux desktop to support what Modern Standby enables. Even though it has been clear for over 3 years.
I disagree with you. The biggest advantage modern standby enables is a faster wakeup. All the devices are put into states that they can quickly resume. There are specifications requiring specific wakeup times from Microsoft and Linux often excels above Windows in this area.
In terms of supporting ‘maintenance’ wakeup, from the kernel there is no problem. You can program a timer wakeup and the kernel will wake you up. It’s the same thing that script I linked above does.
It’s really that no userspace chooses to do anything with it. For that matter - systemd now freezes user.slice and so even if the kernel did wake it up, systemd controls what could be operational at that time.
I did start a discussion a few years back with systemd to start supporting dark resume but got a lukewarm response. I’ve also got a few systemd patches that push it in that direction that i’ve linked here.
On my 11th gen system, the battery (degraded to 48kWh) charged to 80% would last 3 days suspended.
I upgraded the mainboard to 7840u and on s2idle it lasts 15h (consumes 2.5W, whereas I would expect 0.5W and lower). amd_s2idle isn’t reporting any problems, and the system spends 99% properly suspended per the report. I’ve also had occasional cases with the laptop not going to sleep and getting hot while lid is closed even though it was supposed to be suspended. This never happened with s3. While the system wakes up a lot faster , I’d rather wait 10s for a system to wake up than have an abysmal sleep power consumption…
That said, MacBooks clearly worked out their equivalent of s2idle as my MacBook can stay suspended for more than 10 days (also charged to 80%)
FTR “Idle” and “s2idle” are different and will consume different power.
That s2idle number sounds high. If you remove all cards and USB devices does it improve? If so you should narrow down which card/device is causing it.
Yes, I meant suspended (S3/deep or s2idle) whenever I said idle.
All my ports are usb-c with nothing connected to them, I turned off wifi and bluetooth, that didn’t make a difference, I haven’t tried removing the wifi card though. I do have 96gb of ram, which may be consuming more than usual.
Is there any estimation how much should framework 13 with HX370 and 96GB RAM draw in sleep from battery? I have mine for few days and I’m having same issues. At first tries it sucked all battery during one night. I’ve played with amd-s2idle, did some recommendations, placed USB-A modules to the right positions and the result is here:
It’s better but it stills used almost 20% battery in 8 hours… Previously I had Lenovo with 5850U+32GB RAM and regular S3 sleep which took ~10% overnight and below 50% on whole weekend (from Friday evening to Monday morning).
According to report, I didn’t have issue with tainted kernel. I have may issue with hardware sleep (it’s around 90% every attempt, sometimes below) but how to find what is awakening it? Is this consumption normal with this CPU and RAM or have I some other issue?
In your case you’re getting a wakeup every 50-55s in that test run that the battery is reporting a status change. That’s quite excessive and is likely part of the problem. I don’t observe this in my testing, but I’m not really sure why. I’m on the same BIOS, a bit newer of a kernel (6.16-rc1) but I don’t expect this code changed.
Can you try to repeat with acpi.ec_no_wakeup=1 on kernel command line? This will block all EC wakeups. See if that gets you closer to the consumption you are looking for.
Sure, I’ll try that with kernel cmd option. Just one question - where do you see 50-55s wakeups? Because if it’s “PM: Triggering wakeup from IRQ 9” line in dmesg I see it even more often (below 10 secs).
Strange is that in dmesg now I have no mentions about wakeup. So there are two options: one that it’s not happening when I sleep system using logind. Or - I’ve change amd_pstate driver to active mode. But it still seems that it doesn’t affect battery consumption… Another thing is it seems that not every suspend goes well - yesterday evening when I transported laptop in bag I pull it out quite warm. Today morning was cold. But no hard data for this yet; I’ll probably start doing regular sleep with amd-s2idle script to get some stats if it’s doing everytime or not (I suppose that if I select very long sleeptime in amd-s2idle script and then wake it up manually it should work).
Report data from script seems good. What is not good that I don’t know what cause wakening laptop. In that time it was closed in the bag, I pull it out 3 hours later and it was clearly visible that display is turned on. So maybe sleep itself was now good or better but something is resuming it…
In timestamps I see what happened - I’ve rebooted laptop (with patched kernel and new cmdline option), I’ve suspended it, it stays suspended for ~3 hours, then it resumes and after several hours I’ve opened lid. In dmesg I only see “Triggering wakeup from IRQ 7” - any idea what it is?
I’ve find out that the wakeup from IRQ 7 comes probably from touchpad. At least when I suspend it and wake it using touchpad, I have same messages in dmesg. I’ve tried to disable wake up from touchpad… but main issue is that acpi.ec_no_wakeup=1 cause that lid and power button stops wakening laptop, so when I disable touchpad I have no way to resume it again
I’ll try some measurements without transporting laptop (I think that wakening was caused by some movement with bag…) to see if battery life will be good. If yes, I guess that after the way will be remove acpi.ec_no_wakeup=1 arg and finding what is the thing which is wakening it…
Irq 7 is the GPIO controller. There is a GPIO for the touchpad waking it when you press it and if hasn’t been disabled from wakeup.
The every 50-55s wakeup from hardware sleep I was talking about was from the EC SCI indicating there is something it wants to notify to the OS. It “feels” like battery level notifications, but I have no idea why your system it’s notifying so frequently but I have never seen this on my side.
Ok, one more try. Yesterday I’ve suspended laptop with amd-s2idle script, acpi.ec_no_wakeup=1 kernel cmdline option and applied patch. And leave it on the table to keep it in sleep without unwanted wakeup from touchpad ghost clik. Report is here:
Overall result is 20,3% battery in 11,5 hours, which is slightly above 2% per hour. Script also reports that system was 99,99% time in hardware sleep and I didn’t see any wakeups or errors in dmesg log. So I guess this is the best result what I can achieve (and this consumption will be related to high system memory) - is that right?
(Still is something to do as I need to remove kernel cmd option because with it it’s not possible to wakeup laptop using power button or lid… but I want to know what is the best I can achieve when I start again enabling things ).
Yeah; from Linux side I don’t expect there is any other software improvement to do. Any future savings over this should be by firmware or hardware changes.
I’ve made some other changes to keep this consumption and have working power button / lid. I didn’t find the way how to disable wakeups about notifying battery as this probably comes from EC controller and every attempt to disable wake up on this results also in disabled power button lid. I ended with udev rules (maybe it will be useful for someone):
This basically disable wakeups from touchpad, keyboard and other things (which probably in my case leads to the highest consumption) and keep working powerbtn and lid. With this setup notify messages about battery change still appears, sometimes. But according to amd-s2idle report it still achieves 98+ % hardware sleep and it seems that the consumption remain on same level like with acpi.ec_no_wakeup=1 kernel cmd option (about 2% per hour on system with 96GB RAM).
