Can you please install python-systemd so that it can use systemd to get some stuff? The newer script should have prompted for this.
I have appended the output of the script with python-systemd installed. The script did not explicitly ask for it.
Weird! It worked for me on arch to prompt. This is the change that causes it.
When journal logger is auto and systemd is used to boot make SURE that systemd… (fbbc4042) · Commits · drm / amd · GitLab
Anyway; nothing notable in that log. All the stuff for the APU is in the right state as I would expect it. If you haven’t already, you should look for a F/W update for NVME.
Whups, sorry! I looks like I have mixed up the scripts. Probably all of the outputs above are from an older version of the script. The latest script version does try to install the package indeed!
Here is the output of the latest script version: s2idle_report-2024-05-22-4.txt · GitHub
Already did. I have the newest available firmware for the SN850x 2TB (version 620361WD) installed.
Can you see if you can reproduce on an untainted kernel?
1 Like
I was indeed able to reproduce the issue after plugging and unplugging the dock a few times. I have ensured to wait a few seconds after each step, so all devices and drivers did have some time to initialize.
(side note: I have removed the amdgpu.sg_display=0 cmdline parameter before disabling the out-of-tree modules. It was accidentally applied to the previous boot.)
When this happens are you by chance seeing a very large number of interrupts in “top” or any other similar tools?
No. I have used irqtop to compare a working and broken state of the laptop. No substantial difference
(s0ix hardware states are working in the first picture, and broken in the second)
This time is was not able to forcefully trigger the issue by plugging and unplugging the laptop from the dock. But after ~15h of normal usage (most of the time in suspend) the issue reappeard.
I’m totally puzzled, this is quite strange!
This “feels” like a pending interrupt isn’t being serviced blocking hardware sleep, but I don’t have any method to give you to prove it at the moment.
What topology are you keeping your yubikey? Is it on the dock or on one of the side ports? If a side port, does it go away when unplugging?
I use the key both directly on the laptop and through the dock. Unplugging it (and everything else) from the laptop does not solve the issue. The only way to get hardware sleep states back seems to be a reboot of the system.
1 Like
Hi Mario, I hope you can help decipher why my FW13 AMD “Did not reach hardware sleep state” 
I saw the suggestion above, so just before this I “load optimal defaults” in the bios, then reboot, then set my usual preferences on top of that: UMA_GAME, low power button brightness, limit battery to 80%.
I have two usb-c cards in the back ports and two usb-a cards in the front ports (though I wouldn’t guess that’s relevant to cpu hardware sleep state, just overall power draw).
Probably nosmt=force
1 Like
Indeed, that was it. Thanks!
1 Like
Great! I’ve added such a check to the script now too.
2 Likes
The issue might not be directly related to docking afterall. In the last few days I have specifically paid attention to when the issue appears. I have written a small script which checks for s0ix residency (/sys/kenrel/debug/amd_pmc/s0ix_stats) after every suspend, and I was able to trigger the issue after only a few suspends without attaching or detaching anything in between.
Is there anything I can do to analyze this behavior further?
Is it possible that this is somehow related to [TRACKING] Framework AMD Ryzen 7040 Series lid wakeup behavior feedback?
Observations:
- Hardware sleep state residency is way smaller if keys are pressed during the 10 second sleep duration of the amd_s2idle.py script (laptop does not wake from sleep due to kernel workaround for spurious IRQs)
- Without any key presses during suspend, the laptop suspends reliably
- Randomly pressing keys during suspend makes it more likely for the issue to appear
- Pressing keys during regular suspend and waking the laptop shortly afterwards sometimes results in weird behavior: Sometimes everything works, sometimes the KDE Plasma Wayland session crashes (back to display manager), and sometimes the whole system crashes (Black Screen → Framework Logo → Bootloader, journald stops after entering s2idle)
Does anyone know whether recent-ish kernels - the 6 series - help with battery life? Thanks.
1 Like
Which patch?
It’s about the same feeling to me. The biggest indicators of battery life are going to be hardware and your tlp profile (disabling turbo boost on bat and throttling to 25% instead of the default 30% on bat made a huge difference for me recently).