If automatic suspend to hibernation (when the battery reaches a certain threshold) would work that would make things much better. How can I achieve that in Fedora ?
@Geert_Schuring If you used btrfs you’ll need to setup a subvol for swap set a swapfile of size ram+zram and then set the resume uuid and resume offset of the subvol and add the resume module into dracut and edit the systemd sleep config to enable hyrbid sleep.
I’ve got a reply which links to a fedora gist on how to do all the above.
1 Like
Small correction, per the article you linked to.
PPD (power-profiles-daemon) (AMD ONLY)
For Framework Laptop 13 AMD Ryzen™ 7040 Series configurations, you will absolutely want to use power-profiles-daemon for the absolute best experience. Do NOT use TLP. Without getting too detailed, there are things happening behind the scenes that require PPD for the best experience for our Linux customers.
AMD has expressly indicated we want to have users on PPD.
What is the consensus of splitting this thread by chip?
I am finding the desire to search out solutions for suspend power consumption on AMD yet there is not yet a dedicated general or suspend power consumption thread for AMD Frameworks.
Fair question - dates back to 2022, so it’s more than I have time to deal with atm.
It really boils down to:
AMD = PPD
Intel = TLP
If folks care to vary from this, testing TLP on AMD chips, great, make sure to include said data.
Hrm … So I left my fw13 last night unplugged and let it suspend with the 6.7-rc1 kernel with the cros_ec patch applied.
What is interesting is that from a ~1.6W initial suspend/idle draw - it increased linearly overnight (see pic) to around 3-4W ~ by the time I resumed it in the morning.
See PIC:
I did have an issue with baloo indexer this morning - I’ll repeat tonight and see if I get the same curve.
1 Like
Actually on retrospect; I think this just may be a graphing artifact, and I doubt Energy Centre is smart enough to write out data to non-volitile buffer during sleep. Comparing to the battery use graph over the same time-period ; I don’t see the drain that this would entail.
1 Like
Thanks - got a lot of work on my hands holding up one of the few (if only) amd FW13 in the South Pacific 
1 Like
Matt, I’m reviving this topic because the discussion got into power save/optimizing battery life while the computer is running (all helpful) but not the original topic: The issue around suspending from Linux is still there. (i.e., suspend is in a shallow level of sleep of “s2idle” that depletes the battery within 6-8 hours)
Doing some research, the command of cat /sys/power/mem_sleep should show me the default state of suspend in braces with other available states next to it such as:
[s2idle] deep.
Then I would be able to change to “deep” via
echo deep | sudo tee /sys/power/mem_sleep
and make this change permanent within GRUB with other commands that I won’t bore you with. The core issue is that the deep option is not available. The deep option would solve the battery depletion during suspend for Linux users. I am using Linux Mint 21.3 MATE. It seems that Framework’s BIOS doesn’t yet support it. I just updated to the 3.03 BIOS version and this is still the case.
Running dmesg | grep ACPI to ensure that Advanced Configuration and Power Interface is enabled, I got a bunch of lines but also some lines indicating a firmware bug:
[ 0.440170] ACPI: thermal: [Firmware Bug]: Invalid critical threshold (-274000)
[ 0.440177] ACPI: thermal: [Firmware Bug]: No valid trip points!
[ 0.440232] ACPI: thermal: [Firmware Bug]: Invalid critical threshold (-274000)
[ 0.440239] ACPI: thermal: [Firmware Bug]: No valid trip points!
[ 0.440291] ACPI: thermal: [Firmware Bug]: Invalid critical threshold (-274000)
[ 0.440297] ACPI: thermal: [Firmware Bug]: No valid trip points!
[ 0.440354] ACPI: thermal: [Firmware Bug]: Invalid critical threshold (-274000)
[ 0.440360] ACPI: thermal: [Firmware Bug]: No valid trip points!
This is before and after the new BIOS upgrade. Could you guys poke around and figure out why this is labeled a bug and perhaps this is also why the deep suspend option isn’t available. It would be great for us Linux users to be able to shut the lid and come back to our work still there a few hours later instead of a dead battery.
Rich,
That was helpful about extending battery life for a running Linux laptop even if it wasn’t about saving battery life for a suspended Linux laptop. I learned some cool stuff. After installing the power_profiles_daemon, I learned that I have 3 states available and when I really want to save battery, I can switch to power_saver mode. It was nifty enough that I created a bash script that queries the current power state and offers choices to change it. I saved it as “manage_power_profiles.sh” with chmod +x so that I can run it whenever.
Here it is if anyone finds it useful:
#!/bin/bash
# Function to get the current power profile
get_current_profile() {
current=$(powerprofilesctl list | grep '*' | awk '{print $2}')
echo "Current power profile: $current"
}
# Function to change the power profile
change_profile() {
echo "Available profiles:"
echo "1) performance"
echo "2) balanced"
echo "3) power-saver"
echo -n "Enter the number of the profile you want to switch to: "
read profile_choice
case $profile_choice in
1)
powerprofilesctl set performance
echo "Switched to performance profile."
;;
2)
powerprofilesctl set balanced
echo "Switched to balanced profile."
;;
3)
powerprofilesctl set power-saver
echo "Switched to power-saver profile."
;;
*)
echo "Invalid choice. Exiting."
exit 1
;;
esac
}
# Main script logic
echo "Power Profile Management"
echo "------------------------"
get_current_profile
echo ""
echo "Do you want to change the profile? (yes/no)"
read answer
if [[ "$answer" == "yes" ]]; then
change_profile
else
echo "No changes made."
fi
echo "Operation completed."
1 Like
In my experience it takes at least a day or two for my FW13 AMD to go through he 61Wh battery on s2idle.
1 Like
I have a FW16 AMD.
To continue, I opened up my old Lenovo and got this output:
(base) rthomas@RT-Laptop:~$ cat /sys/power/mem_sleep
s2idle [deep]
I have good suspend battery life because that laptop has the deep option available and has defaulted to it being active. This deep option is missing in my FW16 AMD and is the reason for the short battery life for suspends.
My recollection is that it is not an option on these boards. I have my system set to use suspend-then-hibernate, configured to hibernate after 12 hours in suspend. If you want to preserve more battery, you could shorten the time until switching to hibernation.
1 Like
Would you know where you’re getting this information? Are you with Framework? I’m really hoping that you’re not correct and that some update to the UEFI firmware could come along later to enable this.
I am not affiliated with Framework. I am about to step out, but you likely can dig up more information by searching the internet for the manufacturer (AMD, in this case, but it also may apply to more recent Intel chips), the chip, and the supported sleep modes.
I could be mistaken, but my memory is that deep sleep is not supported. Suspend-then-hibernate works well enough for my situation, but I accept that it may not for yours or others’.
@Randall_Thomas, did you try running Mario’s amd_s2idle.py script, to see whether your system does, in fact, remain in the sleep state, or if it has to go in and out of it, because of some hardware/driver issues (which tend to be the most common cause of high battery consumption during s2idle “sleep”)?
If you haven’t, search this forum for amd_s2idle.py, and see where to get it and how to run it. If you have, what did it show?
1 Like
My understanding is that AMD and Intel are enforcing the S3 deep sleep phase-out on their modern processors.
There has been widespread outrage about this for the past few years:
I’ve had a similar experience where I noticed that suspend power draw was 7x higher on my FW13 with s2idle versus my older Lenovo which has S3/deep sleep. But then I discovered that the RAM modules were responsible for 80% of the drain. Using different RAM reduced the gap to being only 2x as bad as the Lenovo. There’s still room for improvement, but I don’t know if the gap could ever be fully closed, as the Lenovo has soldered LPDDR.
For troubleshooting steps, I’d suggest the following:
- Use the
amd_s2idle.pyscript - Check your RAM’s power consumption. That post also has some notes on using
amd_s2idle.py - Unplug everything except USB-C expansion cards. Those have been known to burn a lot of power during suspend. Not sure if they’ve all been fixed by now. I’d play it safe though and remove them all for initial troubleshooting.
1 Like
Miles,
Thank you for the heads up on the Python script. That’s quite a rabbit hole of information. Going around with ChatGPT on the output, it seems that first, the RAM is not configured for s2idle in the BIOS, specifically because it is missing the ACPI StorageD3Enable attribute. This is apparently what people have figured out already. Instead, a kernel workaround is suggested if no BIOS update is available. The workaround is adding nvme.noacpi=1 to GRUB configuration to force RAM to s2idle. I have not yet tried this.
Secondly, the kernel is labeled as “tainted” because of the use of proprietary AMD GPU drivers. Trying to get the latest firmware via sudo apt install --reinstall linux-firmware did not address the issue. The taint code of 12289 is a combination of the following flags:
1: Proprietary module has been loaded.4096: Debug file system has been used.
This means the kernel is tainted because:
- A proprietary module is loaded (likely
amdgpuor some other out-of-tree driver). - A debug file system (such as
debugfs) has been accessed.
The full output of the Python file is this:
Debugging script for s2idle on AMD systems
💻 Framework Laptop 16 (AMD Ryzen 7040 Series) (16in Laptop) running BIOS 3.3 (03.03) released 03/27/2024 and EC unknown
🐧 Linux Mint 21.3
🐧 Kernel 6.8.0-40-generic
🔋 Battery BAT1 (NVT FRANDBA) is operating at 103.04% of design
Checking prerequisites for s2idle
✅ Logs are provided via systemd
✅ AMD Ryzen 9 7940HS w/ Radeon 780M Graphics (family 19 model 74)
✅ SMT enabled
✅ LPS0 _DSM enabled
✅ HSMP driver `amd_hsmp` not detected (blocked: False)
✅ PMC driver `amd_pmc` loaded (Program 0 Firmware 76.82.0)
✅ USB4 driver `thunderbolt` bound to 0000:c3:00.5
✅ USB4 driver `thunderbolt` bound to 0000:c3:00.6
✅ GPU driver `amdgpu` bound to 0000:c1:00.0
✅ System is configured for s2idle
❌ NVME Sandisk Corp is not configured for s2idle in BIOS
✅ GPIO driver `pinctrl_amd` available
🚦 Device firmware checks unavailable without gobject introspection
🚦 MSR checks unavailable
👀 Suspend must be initiated by root user
❌ Kernel is tainted: 12289
Your system does not meet s2idle prerequisites!
Explanations for your system
🚦 Sandisk Corp missing ACPI attributes
An NVME device was found, but it doesn't specify the StorageD3Enable
attribute in the device specific data (_DSD).
This is a BIOS bug, but it may be possible to work around in the kernel.
For more information on this failure see:
https://bugzilla.kernel.org/show_bug.cgi?id=216440
🚦 Kernel is tainted
A tainted kernel may exhibit unpredictable bugs that are difficult for this script to characterize.
If this is intended behavior run the tool with --force.
For more information on this failure see:
https://gitlab.freedesktop.org/drm/amd/-/issues/3089
So I’ll try that kernel workaround for the RAM and hope that firmware comes out for the AMD GPU eventually.