Load optimal defaults is what I meant by reset BIOS settings. So that didn’t help.
From your log here’s the issue:
2024-06-14 20:56:46,554 DEBUG: thunderbolt: probe of 0000:c3:00.6 failed with error -110
-110 is a timeout issue where PCI transactions sent by the thunderbolt driver aren’t responding in time. Do you have anything connected to either of the back ports? If so, try with nothing connected and see if it helps. When I say nothing; I mean nothing, no USB-C card even.
OKAY we’re getting somewhere! Taking out all the expansion cards for good measure, then restarting, generated these results (I just used the default singular 10 second session): s2idle Report Output (No Expansion Cards) · GitHub
I can also say that my laptop also didn’t immediately try waking itself when I suspended GNOME, so anecdotally it seems good too. Though I’m not too sure where to go from here in terms of preventing it from happening after I plug my cards back in.
What cards did you have plugged in? Specifically slots 1 and 3 in this diagram: Expansion Card Functionality on Framework Laptop 13 (AMD Ryzen™ 7040 Series)
In slot 1 I had a USB-C passthrough card, and in slot 3 I had a 1 terabyte expansion card.
I’d say it’s more likely that card in slot 3 causing an issue. Can you try with everything normal but that one card not connected?
Alright here’s the results: s2idle_report-2024-06-14-5.txt · GitHub
Everything seems good still, although I’ll take the time now to also mention that I’ve also used a Displayport card in slot 3 while having the aforementioned symptoms, just in case that changes anything.
DP card in that slot should be fine. Maybe you booted with the 1TB card in the slot and then plugged in DP later?
I guess I’d say put that 1TB card in slot 2 or 4 if you can swing it. If everything looks good in this configuration from a fresh boot I would suggest you contact support, they should reproduce this and see if there is anything they can do about it from BIOS perspective. If they can’t they could at least document it in that page I linked.
Okay so I decided to try out the test with the Displayport expansion card plugged in and it seemed to have failed on the first test? s2idle_report-2024-06-14-6.txt · GitHub
Not sure what’s up with that exactly.
The residency numbers are a little lower, but I think that’s just because of how long it took to get to suspend with the card connected.
2024-06-14 22:06:53,077 INFO: ✅ Userspace suspended for 0:00:13.006219
2024-06-14 22:06:53,077 DEBUG: Kernel suspended for total of 0:00:09.463000 (72.76%)
2024-06-14 22:06:53,077 INFO: ✅ In a hardware sleep state for 0:00:08.973632 (68.99%)
You at least got to a hardware sleep state. If you try a more realistic cycle like 5 or 10 minutes I bet you get most of the time in the hardware sleep state.
(Whoops accidentally edited the post instead of making a new one) OKAY, so I took an hour to do some additional testing. Seems that with the monitor connected, my laptop fails the first test by spending only 1% of its time asleep, and then fails the other 4 of the 5 tests by spending only 30% of its time asleep: s2idle_report-2024-06-14-7.txt · GitHub
Any advice on what this could mean?
OK so let me walk you through how to interpret that result.
2024-06-14 22:27:04,192 INFO: ○ GPIOs active: [‘58’, ‘5’]
2024-06-14 22:27:04,193 ERROR:In a hardware sleep state for 0:00:02.140289 (1.39%)
The first cycle woke from two GPIOs; 58 and 5. All the others woke from only GPIO 5.
| 33: GPIO 58 (ACPI:Event)
GPIO 58 is an ACPI event, so we can look at the ACPI tables. GPIO 58 is 0x3A in hex. Let’s look at what GPIO 58 normally notifies in this design:
2024-06-14 22:21:46,597 DEBUG: Case (0x3A)
2024-06-14 22:21:46,597 DEBUG: {
2024-06-14 22:21:46,597 DEBUG: M000 (0x393A)
2024-06-14 22:21:46,597 DEBUG: M460 (" Notify (\_SB.PCI0.GP17.XHC0, 0x02)\n", Zero, Zero, Zero, Zero, Zero, Zero)
2024-06-14 22:21:46,597 DEBUG: Notify (_SB.PCI0.GP17.XHC0, 0x02) // Device Wake
2024-06-14 22:21:46,597 DEBUG: }
You can see it notifies PCI0.GP17.XHC0.
2024-06-14 22:21:46,357 DEBUG: ├─ 0000:c1:00.3 : Advanced Micro Devices, Inc. [AMD] USB controller [1022:15b9] : _SB_.PCI0.GP17.XHC0
We can see this is an XHCI controller that is notified. So to me this indicates that XHCI controller received an interrupt from a connected device to wake it up.
The script doesn’t collect anything about connected monitors, but I’m guessing this monitor asserted the HPD pin in the DP card around when the system suspended. This caused the card to issue an interrupt.
IIUC confirming this would require a an ossiciliscope on the HPD pin because we don’t log it in software in any way.
But you know it’s caused by the monitor; so I’d say suspend without the monitor connected? In my mind it’s relatively unusual to have a monitor connected but not power connected. Or put the monitor onto a dock that provides power and keep that connected nominally.
Okay so I did some more tests and I have even less of an idea what’s going on.
Firstly, I think after all the tests I did it’s now clear the monitor has nothing to do with my laptop waking up. I tried doing 5, 60 second tests, with 5 minutes in between each test, and with the laptop connected to 0 expansion cards, and the laptop still ended up only being asleep for less than 30% of each test: amd_s2idle.py output with no expansion cards · GitHub
I think in my first tests, I had set the test lengths simply too short, and it wasn’t detected when I tried the tests again because previously, the laptop would immediately wake up, rather than wake up prematurely.
Secondly, the mouse I daily drive (a Logitech GPRO X Superlight) seems to prematurely wake up my laptop before it wakes itself up. I tried moving around the mouse between each test and it was only awake for around 1% of the time it was supposed to be asleep each time: amd_s2idle.py output with logitech gpro x superlight connected · GitHub
It’s this mouse (mouse receiver specifically maybe?) that seems to be immediately waking up my laptop, in any other configuration the laptop will continue to wake up prematurely but not immediately after going to sleep.
For your test you were seeing 30% did you boot with no cards or adapters connected? Or you removed at runtime?
Booted with nothing connected.
Can you please check for an nvme firmware update? Most manufacturer don’t publish nvme updates to LVFS unfortunately, so check their website.
I’m not really sure how to achieve that in Linux? I’d try updating my Western Digital SN850X, but it’s only done through their Windows-only software. Maybe it’d work in WINE? But I’m not totally sure if WINE can access the SSD when it’s a compatibility layer?
It wouldn’t work in WINE, but often they have an EFI updater, or ISO updater you can use. If not; the other option is a Windows USB key to do it (i’ve heard this is possible).
I’m mostly grasping at straws here because the report is otherwise clean; but there have been a lot of people lately that had s2idle issues they claimed were fixed after upgrading NVME firmware.
I’m not really sure how to get a “Windows USB key” myself? Since this involves downloading and running software I’m assuming I’d have to somehow install Windows to a USB drive, as opposed to just creating a drive that lets me install Windows (I don’t think Windows has any history of embracing live install images like Linux has).
Update: I did find an installation method of externally installing Windows to a USB drive… But it involves Windows, because the tutorial uses Rufus, which is Windows only: How to Run Windows 11 on a USB Drive (and Take it With You) | Tom's Hardware
Maybe this will help
