Clean install fails to resume from suspend / wake from sleep

General
1

Hello! I’m new around here – am trying to make the jump from Windows to Linux.

Have installed Bazzite on my desktop and am not able to get it to resume from suspend. The machine goes to sleep properly and will power on when I attempt to wake it by clicking the mouse (the fans spin up, the display wakes and searches for signal, only to then go to sleep because it fails to find one). I have to hard reset to get back into the system.

I know that it’s not a problem with the monitor because the system isn’t responding: I cannot SSH into it (or ping it for that matter).

Putting my PC to sleep is a crucial part of my workflow and not being able to wake it is a hard dealbreaker for me. Please help me fix it.

Operating System: Bazzite 42
KDE Plasma Version: 6.3.5
KDE Frameworks Version: 6.14.0
Qt Version: 6.9.0
Kernel Version: 6.14.6-105.bazzite.fc42.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 24 × 13th Gen Intel® Core™ i7-13700K
Memory: 31.1 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 4090
Manufacturer: ASRock
Product Name: Z790 PG-ITX/TB4

ujust device-info UNTITLED - Pastebin Service

Successfully sleeps, but no record of wake:

journalctl -u sleep.target

May 27 22:12:15 Iridium systemd[1]: Reached target sleep.target - Sleep.
-- Boot a5b55e0fd29f482cb72d7dcfa2b6f8d2 --
May 27 22:29:48 Iridium systemd[1]: Reached target sleep.target - Sleep.
-- Boot a6aa5e1cdd7b4325bda14c391ef31eb4 --
May 27 22:41:05 Iridium systemd[1]: Reached target sleep.target - Sleep.

From a different angle:

journalctl -r -b -1

May 27 22:46:28 Iridium kernel: PM: suspend entry (deep)
May 27 22:46:28 Iridium systemd-sleep[4441]: Performing sleep operation 'suspend'...
May 27 22:46:28 Iridium (sd-exec-strv)[4442]: /usr/lib/systemd/system-sleep/fw-fanctrl-suspend failed with ex>
May 27 22:46:28 Iridium systemd-sleep[4445]: [Error] > An error occurred: [Errno 2] No such file or directory
May 27 22:46:28 Iridium systemd-sleep[4441]: Successfully froze unit 'user.slice'.
May 27 22:46:28 Iridium systemd[1]: user.slice: Unit now frozen.
May 27 22:46:28 Iridium systemd[1]: user@1000.service: Unit now frozen-by-parent.
May 27 22:46:28 Iridium systemd[1]: user-1000.slice: Unit now frozen-by-parent.
May 27 22:46:28 Iridium systemd[1]: session-2.scope: Unit now frozen-by-parent.
May 27 22:46:28 Iridium systemd[1]: user@0.service: Unit now frozen-by-parent.
May 27 22:46:28 Iridium systemd[1]: user-0.slice: Unit now frozen-by-parent.
May 27 22:46:28 Iridium systemd[1]: Starting systemd-suspend.service - System Suspend...
May 27 22:46:28 Iridium systemd[1]: nvidia-suspend.service: Consumed 1.091s CPU time, 1.2G memory peak.
May 27 22:46:28 Iridium audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:syste>
May 27 22:46:28 Iridium audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:syst>
May 27 22:46:28 Iridium systemd[1]: Finished nvidia-suspend.service - NVIDIA system suspend actions.
May 27 22:46:28 Iridium systemd[1]: nvidia-suspend.service: Deactivated successfully.
... [truncated]

I have tried the following (which are the only ideas I can seem to find via Google):

  • Disabling bluetooth using the system tray widget in KDE as well as rfkill block bluetooth
  • Using flatseal to ensure that Wayland Windowing System is enabled by default for all packages
  • Ensuring that the Display Color Profile is not set to “None”
  • Explicitly enabling wake on USB / Keyboard / Mouse in BIOS
  • Updating the BIOS
  • Enabling/disabling support for different CPU C-Levels in the BIOS
  • Ctrl+Alt+f3 tty switching (doesn’t work because the OS hasn’t resumed yet)

None of these have had any positive effect. It seems to me as if the OS isn’t capturing some kind of interrupt to know that is has to wake up, which is why there are no logs after suspend other than those of a cold-boot after I had to hard reset the machine.

Please let me know if there is any other debug information that would help. I’m rather desperate to migrate to Linux and willing to adapt to different idiosyncrasies that come with the change, but lack of suspend is a deal breaker. :frowning:

Thank you!!

EDIT:

cat /proc/acpi/wakeup 
Device	S-state	  Status   Sysfs node
PEG1	  S4	*enabled   pci:0000:00:01.0
PEGP	  S4	*disabled  pci:0000:01:00.0
PEG2	  S4	*disabled
PEGP	  S4	*disabled
PEG0	  S4	*enabled   pci:0000:00:06.0
PEGP	  S4	*disabled  pci:0000:02:00.0
SIO1	  S3	*disabled  pnp:00:00
RP09	  S4	*disabled
RP10	  S4	*disabled
RP11	  S4	*disabled
RP12	  S4	*disabled
RP13	  S4	*enabled   pci:0000:00:1d.0
RP14	  S4	*disabled
RP15	  S4	*disabled
RP16	  S4	*disabled
RP01	  S4	*disabled
RP02	  S4	*disabled
RP03	  S4	*enabled   pci:0000:00:1c.0
RP04	  S4	*enabled   pci:0000:00:1c.3
RP05	  S4	*disabled
RP06	  S4	*disabled
RP07	  S4	*disabled
RP08	  S4	*disabled
RP17	  S4	*disabled
RP18	  S4	*disabled
RP19	  S4	*disabled
RP20	  S4	*disabled
RP22	  S4	*disabled
RP23	  S4	*disabled
RP24	  S4	*disabled
RP25	  S4	*enabled   pci:0000:00:1a.0
RP26	  S4	*disabled
RP27	  S4	*disabled
RP28	  S4	*disabled
XHCI	  S4	*enabled   pci:0000:00:14.0
XDCI	  S4	*disabled
HDAS	  S4	*disabled  pci:0000:00:1f.3
CNVW	  S4	*disabled  pci:0000:00:14.3
AWAC	  S4	*enabled   platform:ACPI000E:00
2

I feel your frustration. About four months ago, I switched my Asus gaming laptop with the older gaming PC my son was using (not a bad trade for him :wink: ) so I could upgrade to an affordable GPU (and more recent CPU) that allows me to run bigger local LLM models (AI). I bought an RTX 3060 12 GB ― while the GPU in my laptop was also an RTX 3060 but with 6 GB.

While I had had no problem with suspend on my laptop, I did with my PC: it would not wake up (the screen would stay black), or it would freeze when trying to suspend. Or one screen (the primary one) would be mostly black on wake, with parts of the screen still partially rendered.

Of course, the main difference between the 2 computers is that the laptop has 2 GPUs (discrete NVIDIA RTX 3060 and the AMD Ryzen 9 internal GPU), and the PC only has 1: the NVIDIA RTX. The laptop was always in hybrid mode and the default GPU was the AMD iGPU.

I tried for months to fix this. I tried looking at logs, I did lots of searches, I tried changing APM settings in BIOS/UEFI, I did a lot of experiments. I tried workarounds found in searches.

Nothing worked. Not only did I have issues with the NVIDIA card, but also with the BlueTooth of a new WiFi/BlueTooth PCI card (disabled on wake), AND the motherboard’s Ethernet card (it would be disabled on wake, BEFORE changing the GPU).

It all went away 2 weeks ago when I installed Aurora. I’m pretty sure that it’s because of the recent Linux kernel and recent NVIDIA drivers (NVIDIA Linux drivers are really, really problematic and I guarantee that my next GPU upgrade will be an AMD). My PC was running Ubuntu 24.04 LTS, which has an older kernel and older NVIDIA drivers (even the drivers in the Graphics Team’s PPA did not fix my problem). So are other components, but it often depends on the Linux distribution and its kernel version.

One thing I can suggest: probe your computer on the Linux Hardware Database (I recently rediscovered it, I wish I had remembered before the switch of computers), then look at the details of its components. There are comments on some components that may be of help. For example, here is my PC’s probe. The NVIDIA card is listed as known to have problems.

At the minimum, this tool makes it easier to identify components and the corresponding drivers, and the possible problems.

1 Like
3

A few other things I’ve tried that didn’t work:

4

There are multiple reports of NVIDIA breaking resume from suspend, so I could imagine that being the case. It could also be your motherboard. There’s this Reddit thread and the Universal Blue Discord also had people talk about the exact same motherboard model a few days back.

1 Like
5

Thank you for taking the time to write up and share your experience. Although it didn’t solve my problem, it gave me something to think about that may have triggered an epiphany that helped me make progress.

See my reply further down the thread.

1 Like
6

Thanks for the comment! I don’t think it is an issue with nvidia – see my comment further down the thread.

I will log into discord and see if I can find the discussion about my motherboard that you mentioned. That’s a good tip, thanks!

7

More things I’ve tried that didn’t work (for the record):

  • “Stock” Fedora 42 (i.e. non-atomic) which ships with the Nouveau nvidia drivers
  • Kubuntu 25.01 which I think also ships with the Nouveau drivers

This leads me to believe it’s not the nvidia drivers that are the issue. Nevertheless, I was disconnecting my PC to remove the nvidia graphics card from it and use only the integrated intel graphics to continue testing the theory when an idea hit me: try removing one of these devices plugged into the machine and see if that works.

I have a Thunderbolt 3 attached 10GbE network adapter connected to my computer. I unplugged it, booted up and suspended the computer then hit a key to wake it – lo and behold: the machine was able to resume from suspend as expected! I tried it twice and it resumed without issue.

I’m not sure if it’s the presence of a thunderbolt device that prevents the kernel from resuming, or the network adapter itself.

Here is my hardware probe, by the way. The network adapter (AQtion AQC100S NBase-T/IEEE 802.3an Ethernet Controller [Atlantic 10G]) and the TB3 interface (JHL6240 Thunderbolt 3 Bridge (Low Power) [Alpine Ridge LP 2016]) are both tagged as “works” but the TB4 interface is not. I’m not sure what that means or if it’s of significance.

This is progress! It doesn’t solve my issue, however, as I need my network running to use the machine… :innocent:

I have seen some folks compose system services that will kill/restart bluetooth back when that was causing resume issues due to a kernel bug. Can anyone help me compose a similar service that will terminate/resume the network adapter or thunderbolt interface before/after suspending?

Thank you!

Here’s an update of my ujust device-info as the previous one expired: UNTITLED - Pastebin Service

1 Like
8

Thanks for the detailed writeup. I do use a system service to disable GPP0, which is the entry that “breaks” suspend on my B550 board as documented on the Arch wiki. Following this method, I believe you can run lspci and cat /proc/acpi/wakeup | grep enabled, noting the corresponding entry for the relevant device. Then, test it by running echo [4-digit-device-ID] > /proc/acpi/wakeup and see if it helps - if it does, you can create the systemd service unit as documented on the wiki with the necessary adjustments.

Even if this doesn’t work immediately I hope this can help you find a working solution!

9

Because of those NVIDIA issues, I’m reminded almost daily of Linus’ message to NVIDIA in court, years ago. :rofl:

The worst of it is, I made the choice to upgrade my PC to an NVIDIA GPU knowingly. I’m still kicking myself. I soooo wanted CUDA/NVIDIA container toolkit because I didn’t trust AMD ROCm (yet)…

10

Antioch wrote:

I have seen some folks compose system services that will kill/restart bluetooth back when that was causing resume issues due to a kernel bug. Can anyone help me compose a similar service that will terminate/resume the network adapter or thunderbolt interface before/after suspending?

Since we’re on an immutable system, you’ll have to look into Podman Quadlet (Bazzite docs) if you want to add systemd services. But I have no idea if they fit the requirements.

11

You absolutely don’t need Quadlet to make a systemd service. It essentially uses systemd service to run, but systemd does not need Quadlets.

All you need to do is sudo nano -w /etc/systemd/system/service-name.service, run sudo systemctl daemon-reload as an extra measure, and run sudo systemctl enable service-name.service. User services can be written to ~/.config/systemd/... instead, and enabled with enable --user ....

2 Likes
12

Thanks!

This isn’t quite what was needed. I believe the steps you took removed the device GPP0 from the set of device interrupts the system will wake from. In my case, I simply need to disable a device before sleep and have it reenabled after wake.

I did some web searching and determined that the following command would “disable” the ethernet adapter. I say disable, but the device is still powered on – the kernel unbinds the device from its driver thereby allowing it to be effectively ignored.

sudo sh -c "echo 0000:09:00.0 > /sys/bus/pci/drivers/atlantic/unbind"
(the device ID was determined by looking at lspci)

After manually running the command, I put the machine to sleep, and it resumed without issue. The network was also automatically reenabled and connected. Success!

Next, I needed to craft a system service to run the command every time the machine goes to sleep. I did so by making the creating the following file named suspend-disable_ACQ100S.service:

[Unit]
Description=Disable ACQ100S ethernet adapter before going to sleep
Before=sleep.target
StopWhenUnneeded=yes

[Service]
Type=oneshot
RemainAfterExit=yes

ExecStart=/bin/bash -c "echo 0000:09:00.0 > /sys/bus/pci/drivers/atlantic/unbind"

[Install]
WantedBy=sleep.target

I placed it in /etc/systemd/system/, ran chmod 644 on it, and then called sudo systemctl enable suspend-disable_ACQ100S.service.

I put the machine to sleep and was able to wake it as expected. Success again!

This is my solution to this issue. I hope it is useful to someone else in the future.

I wonder, however, if I have discovered a bug in the driver and should report it (perhaps the driver assumed the device would be directly attached to the PCIe bus and thus has an issue when it’s connected through Thunderbolt)? If so, where should it be reported?

13

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.