Fedora Workstation 40, Laptop wakes self up immediately after going to sleep

Framework Laptop 13 Linux
1

So after a while, I elected to switch from Fedora KDE 40 to Fedora Workstation 40, although I’ll leave my original post alone in case someone else on Fedora KDE is having similar issues.

As it turns out, my sleep issues are still happening, my laptop seldom goes to sleep. It happens regardless whether I click on the sleep option in GNOME’s control panel, or press on the power button to make the computer suspend.

I tried the provided “suspend with lid while attached to power workaround” but like last time it had no effect. Any advice on troubleshooting this would be great!!

Here’s a fastfetch output for all my system details:

             .',;::::;,'.                 klazo@theseus
         .';:cccccccccccc:;,.             -------------
      .;cccccccccccccccccccccc;.          OS: Fedora Linux 40 (Workstation Edition) x86_64
    .:cccccccccccccccccccccccccc:.        Host: Laptop 13 (AMD Ryzen 7040Series) (A7)
  .;ccccccccccccc;.:dddl:.;ccccccc;.      Kernel: Linux 6.8.11-300.fc40.x86_64
 .:ccccccccccccc;OWMKOOXMWd;ccccccc:.     Uptime: 16 hours, 6 mins
.:ccccccccccccc;KMMc;cc;xMMc;ccccccc:.    Packages: 2269 (rpm), 23 (flatpak)
,cccccccccccccc;MMM.;cc;;WW:;cccccccc,    Shell: bash 5.2.26
:cccccccccccccc;MMM.;cccccccccccccccc:    Display (BOE0BCA): 2256x1504 @ 60Hz (as 1128x752) [Built-in]
:ccccccc;oxOOOo;MMM000k.;cccccccccccc:    DE: GNOME 46.2
cccccc;0MMKxdd:;MMMkddc.;cccccccccccc;    WM: Mutter (Wayland)
ccccc;XMO';cccc;MMM.;cccccccccccccccc'    WM Theme: Adwaita
ccccc;MMo;ccccc;MMW.;ccccccccccccccc;     Theme: Adwaita [GTK2/3/4]
ccccc;0MNc.ccc.xMMd;ccccccccccccccc;      Icons: Adwaita [GTK2/3/4]
cccccc;dNMWXXXWM0:;cccccccccccccc:,       Font: Cantarell (11pt) [GTK2/3/4]
cccccccc;.:odl:.;cccccccccccccc:,.        Cursor: Adwaita (24px)
ccccccccccccccccccccccccccccc:'.          Terminal: GNOME Terminal 3.50.1
:ccccccccccccccccccccccc:;,..             Terminal Font: Source Code Pro (10pt)
 ':cccccccccccccccc::;,.                  CPU: AMD Ryzen 7 7840U w/ Radeon  780M Graphics (16) @ 6.08 GHz
                                          GPU: AMD Radeon 780M @ 0.80 GHz [Integrated]
                                          Memory: 4.59 GiB / 27.21 GiB (17%)
                                          Swap: 0 B / 8.00 GiB (0%)
                                          Disk (/): 61.82 GiB / 3.64 TiB (2%) - btrfs
                                          Local IP (enp193s0f3u2): 192.168.1.20/24 *
                                          Battery: 99% [Discharging]
                                          Locale: en_US.UTF-8
2

Reproduce using scripts/amd_s2idle.py · master · drm / amd · GitLab for hints on where the problem is. It will tell you the wakeup source.

3

Oh hey, thanks!! Right now it says my thunderbolt driver is missing, and that I need to have CONFIG_USB4 enabled in my kernel. Having never touched kernel stuff aside from updates, would you know how to make that change?

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 40 (Workstation Edition)
🐧 Kernel 6.8.11-300.fc40.x86_64
🔋 Battery BAT1 (NVT FRANGWA) is operating at 102.73% 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` bound to 0000:c3:00.5
❌ USB4 controller for 0000:c3:00.6 not using `thunderbolt` driver
✅ GPU driver `amdgpu` bound to 0000:c1:00.0
✅ System is configured for s2idle
✅ NVME Sandisk Corp WD Black SN850X NVMe SSD is configured for s2idle in BIOS
✅ GPIO driver `pinctrl_amd` available
Your system does not meet s2idle prerequisites!
Explanations for your system
🚦 thunderbolt driver is missing
	The thunderbolt driver is required for the USB4 routers included
	with the SOC to enter the proper power states.
	Be sure that you have enabled CONFIG_USB4 in your kernel.
4

It sounds like one of the USB4 routers isn’t binding to the thunderbolt driver for some reason. The driver is definitely there in Fedora though. You can see in the report above that one of them did bind.

You should look at your kernel log for hints at what is wrong.

Some quick ideas though:

  1. If you haven’t already; I would suggset to try to reset BIOS default settings.
  2. If that doesn’t help maybe you can try to “reinstall” the BIOS image. This will reset all the firmware used to initialize this hardware.
5

Also if you can post the whole report text file it saved to a Github gist I can look at that to understand it.

6

Oh yeah! Here’s a link to the gist: amd_s2idle Python Script Output · GitHub

7

Okay I tried using the “Load Optimal Defaults” option in the BIOS settings, but it doesn’t seem to have changed anything about the s2idle scripts output. I’m not sure whether I didn’t actually reset my BIOS or whether I’m gonna have to reinstall the firmware?

8

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.

9

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.

10

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)

11

In slot 1 I had a USB-C passthrough card, and in slot 3 I had a 1 terabyte expansion card.

12

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?

13

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.

14

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.

15

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.

16

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.

17

(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?

18

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: :x: 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.

19

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.

20

For your test you were seeing 30% did you boot with no cards or adapters connected? Or you removed at runtime?