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:
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."
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.
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?
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:
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.
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 amdgpu or 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.
@Mario_Limonciello, who both authored that script and works at AMD, might have an additional insight. But, seeing that you’re using Linux Mint 21.3 with 6.8.0 kernel, I’m not sure you would benefit from new AMD-released firmware anyway - I think, Mint is known for being somewhat behind on new hardware updates.
With the newer versions of Linux kernel, you don’t even need to set that parameter anymore.
Finally had some extra time today to run the script for an hour.
Full log:
Haven’t gone through the log completely and I am not that well versed on these things but atleast quickly going through the log nothing special pops up from it?
2024-09-16 08:59:14,750 INFO: ○ Suspend count: 1
2024-09-16 08:59:14,750 INFO: ○ Hardware sleep cycle count: 1
2024-09-16 08:59:14,751 INFO: ○ Wakeup triggered from IRQ 9: ACPI SCI
2024-09-16 08:59:14,751 DEBUG: Used Microsoft uPEP GUID in LPS0 _DSM
2024-09-16 08:59:14,751 INFO: ○ Woke up from IRQ 9: ACPI SCI
2024-09-16 08:59:14,751 INFO: ○ gpe0B increased from 180 to 198
2024-09-16 08:59:14,752 DEBUG: ACPI Lid (/proc/acpi/button/lid/LID0/state): open
2024-09-16 08:59:14,752 INFO: ✅ Userspace suspended for 1:00:02.311729
2024-09-16 08:59:14,752 DEBUG: Kernel suspended for total of 0:59:58.860000 (99.90%)
2024-09-16 08:59:14,753 INFO: ✅ In a hardware sleep state for 0:59:58.485473 (99.89%)
2024-09-16 08:59:14,755 DEBUG: BAT1 charge level is 3423000 µAh
2024-09-16 08:59:14,755 INFO: 🔋 Battery BAT1 lost 27000 µAh (0.66%) [Average rate: 0.0A]
But is this something to worry about:
Woke up from IRQ 9: ACPI SCI
Nearly the entire thing was spent in the hardware sleep state.
2024-09-16 08:59:14,752 INFO: ✅ Userspace suspended for 1:00:02.311729
2024-09-16 08:59:14,752 DEBUG: Kernel suspended for total of 0:59:58.860000 (99.90%)
2024-09-16 08:59:14,753 INFO: ✅ In a hardware sleep state for 0:59:58.485473 (99.89%)
Details on all the RAM I tested are in this linked post.
How much RAM are you planning to get? I suspect the numbers for 32GB and 64GB kits will have a more reasonable capacity/power tradeoff, and that it’s just the 48GB and 96GB kits that burn a disproportionate amount of power.