Sometimes when I press the Power button on my PC, the display will blank ✅, but OS is still running (and the Power LED doesn’t start blinking) 🐞.
I have to press a key or the mouse left button twice, then the display wakes up and then when I press the Power button again, suspending is finally successful (the Power LED will start blinking).
Here is a syslog when the issue occurs. syslog.txt (11.2 KB)
# Set value to 0 to disable modesetting
options nvidia-drm modeset=1
options nvidia-drm fbdev=1
# To fix textures when resuming from suspend, see https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1876632
options nvidia NVreg_PreserveVideoMemoryAllocations=1 NVreg_TemporaryFilePath="/var/tmp"
I tried the latest beta 575.51.02 and the issue doesn’t happen.
So it seems to be fixed, maybe within
Fixed a bug that could cause graphics applications to not render correctly after a system suspend/resume cycle, if using the nvidia.ko kernel module parameter NVreg_PreserveVideoMemoryAllocations=1.
I am having the same error on Fedora 42, running `580.82.09`. For me however it doesn’t happen while suspending the OS, but when Brave browser has a video playback on a tab, specifically the Synology Surveillance Station client.
This is the dmesg:
[ 8865.620486] [drm:__nv_drm_gem_nvkms_map [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to map NvKmsKapiMemory 0x00000000a859faf0
[ 8865.630849] traps: ThreadPoolForeg[51219] trap invalid opcode ip:55d253844016 sp:7ff11adfa160 error:0 in brave[b583016,55d24b6bd000+d6ff000]
Thank you, suspend hasn’t worked for me with any driver newer than 550.163.01, your script is the first workaround that actually works. Suspend is also faster than 550.163.01 without the script.
Seems like I celebrated too soon, after several succesful suspend/resume operations I rebooted the machine and suspend is no longer succesful, gnome-shell is not stopped when the script runs:
Nov 16 14:23:07 north root[4848]: gnome-nvidia-fix: Pausing gnome-shell before suspend
Nov 16 14:23:33 north kernel: watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [gnome-shell:3255]
[...]
Nov 16 14:25:17 north kernel: Freezing user space processes failed after 20.007 seconds (2 tasks refusing to freeze, wq_busy=0):
Nov 16 14:25:17 north kernel: task:gnome-shell state:R running task stack:0 pid:3255 tgid:3255 ppid:2871 flags:0x0000400e
[...]
Nov 16 14:25:17 north kernel: task:pkill state:D stack:0 pid:4849 tgid:4849 ppid:4846 flags:0x00000006
[...]
ov 16 14:25:17 north systemd-sleep[4843]: Failed to put system to sleep. System resumed again: Device or resource busy
There seems to be a timing problem between Gnome and the NVIDIA driver during suspend, this post explains the problem and has a solution based on systemd services that pause gnome-shell before suspend and unpauses it after resume.
I have implemented the solution and it looks promising, several suspend/resume operations still working after several reboots. I’ve been searching for a solution for this issue for a long time and I’m cautiously optimistic.
Interesting. For me when the event “Freezing user space processes failed after 20 seconds” happens, then the suspending is repeated (and again and again ..) and finally succeeds, I would say max 1 minute.
When suspending is without errors and it’s done within 5 secs on my station.
suspend mode explicitly set to deep (s2idle [deep])
I previously had consistent resume failures with s2idle. Switching to deep fixed those: deep successfully completed suspend/resume both with GDM stopped and with a normal GNOME/Wayland session.
However, suspend is still intermittently failing before the system actually enters sleep. On the same boot with kernel 7.0.0-30, two deep suspend/resume cycles completed successfully, followed by one failed attempt.
During the failed attempt:
PM: suspend entry (deep)
Freezing user space processes failed after 20.005 seconds (1 tasks refusing to freeze)
task:gnome-shell
The gnome-shell stack is inside the NVIDIA DRM/NVKMS path:
INFO: task nvidia-sleep.sh ... blocked for more than 122 seconds
INFO: task nvidia-sleep.sh ... <writer> blocked on an rw-semaphore likely owned by task gnome-shell
followed by:
[nvidia-drm] Failed to map NvKmsKapiMemory
nvidia-modeset: WARNING: GPU:0: Lost display notification
nvidia-modeset: ERROR: GPU:0: Idling display engine timed out
systemd-suspend.service eventually fails because nvidia-sleep.sh cannot be terminated.
This therefore looks like a race/deadlock between GNOME Shell and the NVIDIA driver during suspend. deep fixes the separate s2idle resume problem on this machine, but does not prevent this intermittent pre-suspend GNOME/NVKMS freeze.
I can provide an nvidia-bug-report.log.gz and the complete journal from the failed attempt if useful.
Thanks for the suggestion. Unfortunately I cannot test driver 595 on this machine because the Quadro P1000 is a Pascal GPU, and NVIDIA 580 is the last driver branch supporting Pascal. So 595 is not an option for this system.
I did, however, test a workaround that directly targets the GNOME/NVIDIA suspend race.
With kernel 7.0.0-30-generic, NVIDIA 580.173.02, GNOME Wayland and deep suspend, the first test completed successfully.
The journal showed:
Pausing gnome-shell before NVIDIA suspend
Starting nvidia-suspend.service
PM: suspend entry (deep)
Freezing user space processes completed (elapsed 0.003 seconds)
PM: suspend exit
Starting nvidia-resume.service
Finished nvidia-resume.service
Resuming gnome-shell after NVIDIA resume
There was no Freezing user space processes failed, no Failed to map NvKmsKapiMemory, and no display-engine timeout in that cycle.
The original problem is intermittent, so I’ll continue testing this workaround. If the underlying issue is fixed in 595, it would be very helpful if the relevant fix could also be backported to the 580 branch for Pascal users.
I am seeing the symptoms reported in the original post, on old hardware. For me the solution seems to be setting PreserveVideoMemoryAllocations to 0, in spite of much advice to the contrary. That change allowed the computer to suspend fully, but I’ve found that resume has required a few additional changes to /usr/bin/nvidia-sleep.sh.
Running driver 580.173.02 on an GeForce GTX 750 adapter in a 2014 Lenovo desktop. Driver was updated about two weeks ago from 535 and I’ve been struggling with suspend/resume ever since. The 535 driver worked fine in all ways except that it required the /usr/bin/nvidia-sleep.sh script to be bypassed by inserting exit 0 on the first non-comment line.