Fedora 44 KDE Wayland failed to sleep on NVIDIA 595.71.05

Ask Fedora
, ,
1

This weekend I upgraded to Fedora 44, and along with the upgrade came a new version of the NVIDA driver from RPM fusion. Works much better and faster! Computer details:

Operating System: Fedora Linux 44
KDE Plasma Version: 6.6.4
KDE Frameworks Version: 6.25.0
Qt Version: 6.10.3
Kernel Version: 6.19.14-300.fc44.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × Intel® Core™ i9-10885H CPU @ 2.40GHz
Memory: 32 GiB of RAM (31,1 GiB usable)
Graphics Processor 1: NVIDIA GeForce GTX 1650 Ti/PCIe/SSE2
Graphics Processor 2: NVIDIA GeForce GTX 1650 Ti/PCIe/SSE2
Manufacturer: Dell Inc.
Product Name: XPS 15 9500

Paradise lost, however, when I tried to put the computer to sleep: It took a nap and woke up from a nightmare with a black screen and the CPU running high and hot. Only the ever more eager fan indicated that the computer was not sleeping, and the only way to cool it down was the long pressed on/off button to switch the computer completely off. When restarting, a crash report was generated for Plasmashell and XWaylandbridge. It is cumbersome to have an insomnia laptop!

The drivers were all correct:

akmod-nvidia.x86_64                        3:595.71.05-1.fc44   rpmfusion-nonfree-updates
kmod-nvidia-6.19.14-300.fc44.x86_64.x86_64 3:595.71.05-1.fc44   @commandline
libva-nvidia-driver.x86_64                 0.0.16-1.fc44        fedora
nvidia-gpu-firmware.noarch                 20260410-1.fc44      updates
nvidia-modprobe.x86_64                     3:595.71.05-1.fc44   rpmfusion-nonfree-updates
nvidia-persistenced.x86_64                 3:595.71.05-1.fc44   rpmfusion-nonfree-updates
nvidia-settings.x86_64                     3:595.71.05-1.fc44   rpmfusion-nonfree-updates
nvidia-xconfig.x86_64                      3:595.71.05-1.fc44   rpmfusion-nonfree-updates
xorg-x11-drv-nvidia.x86_64                 3:595.71.05-1.fc44   rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-cuda.x86_64            3:595.71.05-1.fc44   rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-cuda-libs.x86_64       3:595.71.05-1.fc44   rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-kmodsrc.x86_64         3:595.71.05-1.fc44   rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-libs.x86_64            3:595.71.05-1.fc44   rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-power.x86_64           3:595.71.05-1.fc44   rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-xorg-libs.x86_64       3:595.71.05-1.fc44   rpmfusion-nonfree-updates

The NVIDIA sleep and resume services were enabled

sudo systemctl enable nvidia-{suspend,resume,hibernate}

The logs from journalctl indicated that the NVIDIA driver suspended successfully, yet there was something triggering KDE Plasma to restart on on a sleeping driver, which probably makes it try indefinitely to reconnect to the sleeping screen driver consuming ever more CPU cycles.

Desperately searching various fora for similar cases (and solutions), I came across a NVIDA thread with people reporting similar issues with 595.58.03 driver (close enough), and there was a similar but older thread for Archlinux where the user Seth expressed some doubts about the kernel parameter nvidia_drm fbdev=1. Cudos to Seth who actually got it right: removing the kernel parameter nvidia_drm fbdev=1 leaving nothing actually gave me back a happy sleeping baby that resumed as expected (even directly on a remote monitor). Then is was just to make the change permanent:

sudo grubby --update-kernel=ALL --remove-args="nvidia_drm.fbdev=1"

Hence, this is not a question, but rather an experience report written up hopefully to help others to avoid the profound frustration and debugging.

2

Suspend works fine here on f44 cinnamon, are you sure it isn’t kde to blame.

FTR Seth is just some archlinux user, what does he know about fedora?

Your command does nothing as fbdev is default enabled in 590+ nvidia

3

I am more than happy to blame KDE… however, the problem went away only after I removed the kernel parameter nvidia_drm.fbdev=1, and my credits to Seth, who is rightly just an Archlinux user, was because he is the first (and only) I have seen pointing at this option as a possible issue. I do not think this is a Fedora issue, but a kernel + NVIDIA driver issue on an Optimus laptop (and hence input from any Linux distribution may help).

My machine did suspend/resume nicely on F43, KDE, and NVIDIA 580 so it must have something to do with the update, probably the NVIDIA 595 driver, and so it could well be, as you say, that since fbdev is now enabled by default and then setting the kernel parameter in addition creates some kind of issue.

4

Check it and confirm

leigh@leigh-pc:~$ sudo cat /sys/module/nvidia_drm/parameters/fbdev
Y
leigh@leigh-pc:~$ sudo cat /sys/module/nvidia_drm/parameters/modeset
Y
leigh@leigh-pc:~$
5

Confirmed! Still it was necessary to remove the kernel option to remove the consistently reproducible suspend error… I do not see what that would have to do with KDE and changing its behaviour if KDE is to blame.

6

I don’t see any action in post#1 that fixed the issue.

1: removing unused cmdline options does nothing.

2: Enabling already enabled systemd services does nothing.

The services are preset enabled

and only work if UseKernelSuspendNotifiers isn’t set, it is set for the open modules

590+ open driver doesn’t use the systemd services

leigh@leigh-pc:~$ cat /proc/driver/nvidia/params |grep UseKernelSuspendNotifiers
UseKernelSuspendNotifiers: 1
leigh@leigh-pc:~$
7

OK, I am just doing “empirical science” here, and going through my debugging command logs from yesterday, I also see that I made an SELinux change:

sudo ausearch -c 'systemd-sleep' --raw | audit2allow -M my-systemdsleep
sudo semodule -X 300 -i my-systemdsleep.pp

but you say that the driver does not use systemd services… but perhaps KDE does? I would presume that SELinux was correctly configured for system sleep by default, no?

The reason for (re-)enabling the systemd nvidia services is that I had the experience, prior to the upgrade, that these were somehow disabled by kernel updates in the past.

8

Selinux is still an issue.

We used the /var/lib/systemd/ directory as it only produces selinux warnings, not denials.

9

It still uses systemd, it doesn’t use the nvidia*.service files.

10

Thank you @leigh123linux for all the info.

I had the same issue as described by @sorcerer, Incomplete suspend: screen going black, CPU fan spinning high…

I upgraded a few days ago to Fedora 44 (My setup is ThinkPad X1E with Nvidia 1650Ti-mq).
The DE is GNOME meaning the issue has nothing to do with the DE. The suspend functionality worked just fine before the upgrade.

To confirm that it’s related to nvidia I had removed rd.driver.blacklist=nouveau,nova_core modprobe.blacklist=nouveau,nova_core from GRUB_CMDLINE_LINUX. Which turns out to be the case.

I’m using nvidia open kernel module:

$ cat /proc/driver/nvidia/version
NVRM version: NVIDIA UNIX Open Kernel Module for x86_64 595.71.05 Release Build (dvs-builder@U22-I3-G08-03-1) Fri Apr 24 06:42:30 UTC 2026
GCC version: gcc version 16.1.1 20260501 (Red Hat 16.1.1-1) (GCC)

$ cat /sys/power/mem_sleep
s2idle [deep]

$ cat /proc/driver/nvidia/params |grep UseKernelSuspendNotifiers
UseKernelSuspendNotifiers: 1

$ cat /proc/driver/nvidia/params | grep PreserveVideoMemoryAllocations
PreserveVideoMemoryAllocations: 2

Masking nvidia-powerd.service was more than enough to restore the complete suspend functionality and solve the issue:

$ sudo systemctl mask nvidia-powerd.service

I concluded that it was probably a race condition issue between UseKernelSuspendNotifiers and nvidia-powerd.service, to be confirmed though.