oh duh right! So there’s none for Intel?
I re-ran the s2idle script, just for fun.
Previous time (as mentioned in my replies earlier in this thread) it worked fine.
Now it does not, and complains about a tainted kernel and problems with s2idle.
My simple question is: does this mean that I have a powermanagement issue now?
Or is that not the case.
Previous time I ran this, and it indicated I should add a kernel paramter. Which I did, and it solved my suspend-then-sleep issue.
But now, a few months later, rerunning this script I get worried something is wrong.
The only thing that might be different is that I installed an Intel ax210 which replaces the stock Mediatek.
If it’s complaining your kernel is tainted, look at the logs for why it got tainted and cross reference to tainted kernel documentation:
Tainted kernels — The Linux Kernel documentation
It doesn’t necessarily mean there is a problem with power management, but if you have one then it’s the first thing you should look at solving.
1 Like
Does it install from the jammy repo?
sudo apt install powertop
This thread is very long with lots of different info, and hard to sift through. Is there a concise guide to fixing the fast battery drain in Ubuntu on the Framework? I am on the AMD 7040 13 inch.
4 Likes
I’ve been doing a refresh of my battery saving tweaks now that the new BIOS has included some improvements, and thanks to that handy script of yours I’ve fixed a few issues preventing proper s2idle. Unfortunately, I currently can’t remedy the warning it gives me about suspend needing root permission:
Debugging script for s2idle on AMD systems
💻 Framework Laptop 13 (AMD Ryzen 7040Series) (Laptop) running BIOS 3.5 (03.05) released 03/29/2024 and EC unknown
🐧 Fedora Linux 39 (Workstation Edition)
🐧 Kernel 6.8.4-200.fc39.x86_64
🔋 Battery BAT1 (NVT FRANGWA) is operating at 102.89% of design
Checking prerequisites for s2idle
✅ Logs are provided via systemd
✅ AMD Ryzen 7 7840U w/ Radeon 780M Graphics (family 19 model 74)
✅ LPS0 _DSM enabled
✅ ACPI FADT supports Low-power S0 idle
✅ HSMP driver `amd_hsmp` not detected (blocked: False)
✅ PMC driver `amd_pmc` loaded (Program 0 Firmware 76.82.0)
✅ USB4 driver `thunderbolt` loaded
✅ GPU driver `amdgpu` available
✅ System is configured for s2idle
✅ NVME SK hynix Platinum P41/PC801 NVMe Solid State Drive is configured for s2idle in BIOS
✅ GPIO driver `pinctrl_amd` available
MSR checks unavailable
👀 Suspend must be initiated by root user
Your system does not meet s2idle prerequisites!
I haven’t been able to nail down exactly what’s causing this error, and before I write a hacky script to lower the permissions on the /sys/power/state/mem on every reboot, I wanted to see if you or anyone else here might know what to look for.
stupid question, but you are running the script with root privileges, right?
3 Likes
Whoo boy, that was actually a really good question. I totally forgot that it needed to be run via sudo and does suspend tests, I should’ve re-read things a bit more. Good catch, looks like I do finally have everything tidied up, thanks for setting me straight!
2 Likes
no problem!
1 Like
Are you running the script with sudo?
The script wants to be run as root and will print those types of warnings when it is not.
If you are running the script with sudo then I am as lost as you are.
That turned out to be the issue, the guy just above helped get my head straight. Everything’s going as it should now!
1 Like
Hey everyone. I own a very similar laptop, the Xiaomi RedmiBook Pro 15 2023 and documented most of my tricks to fix bugs and optimize the battery life in my notes [1]. Many of these tricks actually come from this thread, so I thought you could be interested. Thanks for the help.
6 Likes
Hi, I just tried to run @Mario_Limonciello 's script but can’t figure out if anything’s wrong with the results.
I see what looks like a failure:
Did not reach hardware sleep state
And also a warning:
Kernel ringbuffer has wrapped
Here’s the full log:
Thanks!
Try installing the systemd journal python module and it might give you better information. But I’m pretty sure the issue is your USB4 controller. What did you do? Were you messing with anything pre-boot like Smokeless? The timeout on this controller can cause the issue.
2024-05-18 23:05:44,046 DEBUG: [ T815] thunderbolt: probe of 0000:c3:00.5 failed with error -110
Hi again, thanks so much for your help 
I’ve installed the python module for systemd and now I get this:
I wonder if the laptop lid should be closed for this test?
Thanks
I wonder if the laptop lid should be closed for this test?
It doesn’t need to be.
Hi again, thanks so much for your help
I’ve installed the python module for systemd and now I get this:
Unfortunately the script doesn’t decode the idle mask for you, but I can tell you what’s wrong. It’s this line:
2024-05-19 09:36:15,000 DEBUG: amd_pmc: SMU idlemask s0i3: 0x15fb3ebd
This means that USB4 router 1 isn’t in D3 at suspend. So you should fixate on whatever you have done to your system that could be preventing that. I would suggest two things.
- Try a Ubuntu 24.04 live media and see if it works. If it works, then you are doing something in your install to cause this problem with the USB4 router.
- If Ubuntu 24.04 live media is also broken I would suggest going into the BIOS and doing a reset BIOS default settings.
I was testing with an Anker USB-C dongle attached to one of the USB-C ports, maybe that’s why. I use this to connect my external mouse, keyboard, monitor as well as a power source since it acts as a bypass (USB-C cable enters the dongle which then powers/charges the laptop)
So I disconnected the dongle and now the results seem ok
Then I tried again with the dongle connected, but unplugged from AC, still results ok:
And finally I tested again with the initial conditions (dongle connected to laptop AND plugged into AC), but surprisingly results were still ok:
So on the positive side it seems like it’s sleeping now, but on the negative I don’t know what was preventing it to do so earlier.
I haven’t really changed anything on my system, so unless my distro/kernel is doing things, I wouldn’t even know what to change.
I’ll keep an eye on this and run the script again if this problem comes back.
Meanwhile thanks - feel free to share any remarks
so unless my distro/kernel is doing things, I wouldn’t even know what to change.
I don’t think it’s your distro/kernel doing anything. The most notable thing I noticed from your very first report is that whatever was going on caused the router to fail to probe.
I’ll keep an eye on this and run the script again if this problem comes back.
Maybe you could do some experiments where you try with various permutations of things plugged in while booting up the system and see if you can get any of them to fail again and narrow it down.
I’d like to adjust the script to catch your condition too. If you get the state of the system like that again can you please capture udevadm info --export-db output?
1 Like
@fw13amd I’ve made a few changes to the script that I think should be able to catch your case better. If you happen to trigger it again, pull an updated snapshot of the script and let me know if it flags it.