Sure thing, thanks a lot.
Tried just a few minutes ago with the updated script, but I still couldn’t reproduce.
Will take some time later today to try different permutations at boot time as you suggested, and report back with the udevadm capture 
I am also having massive issues with reaching hardware sleep states in suspend, when my AMD Framework 13 is up for more than a day or two. This results in battery drain high enough that it heats up considerably in my backpack.
I don’t know what triggers this behaviour, because it only happens after the device has been used for a while. Suspend works absolutely fine after a fresh reboot. I somehow have the feeling that it is related to docking and undocking from my “HP USB-C Dock G5 Essential”.
I have attached the log output of the amd_s2idle.py script. I don’t know what to look for, when searching for hardware sleep state blockers.
The whole s2idle situation is kind of annoying, as I can not rely on my laptop to still be charged after a few hours in my backpack. This already was a (actually really similar) problem for me with the Dell XPS 9500. In comparison, S3 suspend on all previous laptops was really reliable for me… 
I do think there is likely an issue with Framework’s EC getting triggered by this dock.
Can you please pull a newer version of the script and re-run it? The newer version will check a few other things that this one doesn’t.
Also; is this is tied specifically to suspending with dock connected and then unplugging or anything like that? Need to understand the exact sequence that is reliably causing it.
No, the issue is not directly related. The dock was just a suspicion, because docking and undocking causes many devices to connect or disconnect at once, and it felt like the issue appears less frequently if I have not been using the dock.
As soon as the issue has appeared once, it persists until the system is rebooted.
I sadly have no way of reliably triggering the issue, apart from using the laptop regularly for a few days.
The log output of the newest version of the script, still from the same boot as the previous output: s2idle_report-2024-05-22-2.txt · GitHub
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?