RTX 4080 / nvidia-open 615.78.08: black screens after suspend

Lukasas · 2026-11-02 12:18:17

Hi,

I am looking for help with intermittent black screens after suspend on Arch Linux. I have collected logs from a failed resume and would appreciate a check of my NVIDIA suspend configuration and advice on the next controlled test.

The PC sometimes resumes normally with all three monitors working. Other times, the fans and motherboard wake but all monitors stay black. Power-cycling the monitors does not reliably recover them, and I have needed a forced restart.

Hardware and session

NVIDIA GeForce RTX 4080, with three monitors connected through DisplayPort.
AMD Ryzen 9 9950X3D, with the integrated AMD GPU also present.
ASUS ROG STRIX X870E-E GAMING WIFI, BIOS 2503.
Arch Linux, KDE Plasma on Wayland.

Versions recorded during the failed test

Kernel: 7.2.14-arch1-1

linux 7.2.14.arch1-1
nvidia-open 615.78.08-4
nvidia-utils 615.78.08-1
lib32-nvidia-utils 615.78.08-1
systemd 262.1-1

Reproduction

From the normal Plasma session, I run:

systemctl suspend

Then I wake the PC. The failure is intermittent rather than occurring on every attempt. Both short and longer sleeps have failed.

Current suspend configuration

The captured failure used deep/S3:

s2idle [deep]

During earlier troubleshooting, I added the following to /etc/modprobe.d/99-nvidia-suspend-workaround.conf:

options nvidia NVreg_UseKernelSuspendNotifiers=0 NVreg_PreserveVideoMemoryAllocations=1 NVreg_TemporaryFilePath=/var/tmp

The loaded values were verified:

PreserveVideoMemoryAllocations: 1
UseKernelSuspendNotifiers: 0
TemporaryFilePath: "/var/tmp"

/var/tmp is disk-backed. nvidia-suspend.service and nvidia-resume.service are enabled.

The installed systemd-suspend.service drop-in at /usr/lib/systemd/system/systemd-suspend.service.d/10-nvidia-no-freeze-session.conf contains:

[Service]
Environment="SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false"

The installed /usr/lib/systemd/system-sleep/nvidia hook invokes nvidia-sleep.sh resume in its post phase. The separate nvidia-resume.service is ordered after systemd-suspend.service.

What the failed capture shows

I used temporary diagnostic scripts prepared with AI assistance: Bash tracing of the resume script and a separate system.slice recorder that sampled process state and collected kernel backtraces. The linked excerpts contain actual machine output.

The kernel returns from sleep, and the independent recorder continues running. However, the NVIDIA post-sleep invocation remains outstanding and systemd-suspend.service does not finish normally. The separate nvidia-resume.service remains queued.

The resume trace ends at:

+ time=1793616417.808490 pid=6084 /usr/bin/nvidia-sleep.sh:56: echo resume

PID 6084's output descriptor points to /proc/driver/nvidia/suspend. An NMI backtrace captures the same process inside nv_procfs_write_suspend on the write syscall path. The trace does not reach the later RestoreVT command.

Selected function names from the recorded backtrace are:

kgspRecvPoll_IMPL
_issueRpcAndWait
rpcRmApiControl_GSP
nvDPPostSetMode
nv_drm_atomic_commit
drm_fb_helper_set_suspend_unlocked
nv_drm_suspend_resume
nv_procfs_write_suspend

This list is only an extract of function names; the complete recorded backtrace is in the linked logs.

The same resume process accumulates approximately 242 seconds of kernel CPU time over approximately 243 seconds of observation. Systemd subsequently logs a stop timeout and sends SIGKILL, but the process is still present in the final sample.

Ping and SSH are unavailable after failed wakes, but the local recorder continues working. I therefore do not think the network symptoms alone establish a complete machine freeze.

Already tested

Both deep and s2idle have produced failures. Updating the BIOS from 1804 to 2503 did not resolve the issue. The NVIDIA parameters above are active but have not made resume reliable.

Windows on the same hardware suspends and resumes reliably.

I have not completed a comparison with another NVIDIA driver version or with the proprietary kernel-module flavor. I do not have a result from an nvidia_drm.fbdev=0 test.

Logs and related report

Selected original log excerpts, including the full resume-process backtrace:
https://pastebin.com/P1dLyjqL

NVIDIA forum report:
https://forums.developer.nvidia.com/t/6 … ath/387776

Question

Does anything in this NVIDIA sleep-hook/service configuration look wrong for these Arch package versions?

What would be the most useful single next test to distinguish a configuration issue from a driver problem? I would prefer to change one variable at a time rather than apply several more workarounds together.

seth · 2026-11-03 08:20:06

Windows on the same hardware suspends and resumes reliably.

3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.

The failure is intermittent rather than occurring on every attempt.

Roughly how frequent? Is there another discernible pattern (external power supply)?

AMD Ryzen 9 9950X3D, with the integrated AMD GPU also present.

Can you run one of the outputs (or an extra one) there?

I have needed a forced restart.

https://wiki.archlinux.org/title/Keyboa … el_(SysRq) - resp.

Nov 02 11:49:57.826859 lukas-arch systemd[1]: systemd-suspend.service: State 'stop sigterm' timed out. Killing.

Switching to a different VT doesn't work either?

https://pastebin.com/P1dLyjqL

Please don't copy and paste from a terminal (or in this case it looks like you tracked the journal w/ script) - you're logging stray line breaks what makes the log a complete PITA

sudo journalctl -b -1 | nc termbin.com 9999

will upload the journal of the previous boot.

I used temporary diagnostic scripts prepared with AI assistance

Thanks for confirming that clankers are stupid, btw

Did you manually run /usr/bin/nvidia-sleep.sh at some random time?
That's not supposed to work, also see https://wiki.archlinux.org/title/NVIDIA … er_suspend - you don't have to (nor should) enable the services.
Resp. w/ the kernel parameter attempts you would have to

I do not have a result from an nvidia_drm.fbdev=0

Don't bother - fbdev is required to take over from the simpledrm device.

Ping and SSH are unavailable after failed wakes, but the local recorder continues working.

Wired or wifi connection?

Lukasas · 2026-11-04 19:22:35

3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.

Disabled it. I never really used the hibernation feature but now I understand that Windows could have been using that without my knowledge.

Roughly how frequent? Is there another discernible pattern (external power supply)?

I'd say in 5 attempts 4 times. Can't see any patterns. This happens fresh booted or after few hours.

Can you run one of the outputs (or an extra one) there?

I tried disabling it in BIOS so the integrated AMD GPU is out, but not even that helped.

https://wiki.archlinux.org/title/Keyboa … el_(SysRq) - resp.

I did not know about all of these commands, the only thing I knew was the Alt + SysRq + W but when the blackscreen happend it did not work - did not log anything.

Switching to a different VT doesn't work either?

Unfortunatelly no, I always tried to switch just to make sure just the desktop did not hang up but it was like the whole system.

Did you manually run /usr/bin/nvidia-sleep.sh at some random time?
That's not supposed to work, also see https://wiki.archlinux.org/title/NVIDIA … er_suspend - you don't have to (nor should) enable the services.
Resp. w/ the kernel parameter attempts you would have to

I might have tried that once or twice, but always trying systemctl suspend or from the taskbar using the Sleep button.

Wired or wifi connection?

Wired.

It's all like stuck.
Sometimes when I woke the PC up, the desktop was messed up meaning the monitors were out of order and one of the monitor had bad resolution.

I tried disconnecting that monitor and ran the suspend again but then it got stuck.

One thing I've noticed by many tries and errors is that when I turn off all monitors but one, the system reliably wakes up fine. I also tried combinations but only when there is one active monitor it wakes up.
I have three monitors and all of them are connected with DP.

Lukasas · 2026-11-04 19:46:00

I suspended the PC, woke it up, it went to black screen.

I tried many of the SysRq and now I see that it registers the commands.

I uploaded the journal to the termbin, can I bother you of taking a look at it?

https://termbin.com/0w0le

seth · 2026-11-04 20:02:01

Nov 04 20:27:06 lukas-arch kernel: sysrq: This sysrq operation is disabled.

Nov 04 19:58:00 lukas-arch kernel: usb 8-9: Product: Wireless_Device
Nov 04 19:58:00 lukas-arch kernel: usb 8-9: Manufacturer: MediaTek Inc.
Nov 04 19:58:00 lukas-arch kernel: usb 8-9: SerialNumber: 000000000
Nov 04 20:24:13 lukas-arch kernel: usb 8-9: reset high-speed USB device number 4 using xhci-pci-prom21
Nov 04 20:24:37 lukas-arch kernel: usb 8-9: reset high-speed USB device number 4 using xhci-pci-prom21
Nov 04 20:24:42 lukas-arch kernel: usb 8-9: device descriptor read/64, error -110
Nov 04 20:24:58 lukas-arch kernel: usb 8-9: device descriptor read/64, error -110

Oh, look - MTK radio… is that a dongle or can you disable the wifi/bluetooth device?

Also try to completely cut power from the system for a couple of minutes - mediatek frequently sullies its nvrm even w/o the dual-boot problem and requires a power cycle for a reset.

Lukasas · 2026-11-04 20:21:50

Also try to completely cut power from the system for a couple of minutes - mediatek frequently sullies its nvrm even w/o the dual-boot problem and requires a power cycle for a reset.

Yea, that one I learned, for that wifi/bluetooth device to work properly I have to do the power cycle, because sometimes when I switch to windows it gets like stuck or what.
It's not a dongle but its integrated in the motherboard. I did the power cut and now it's working fine without these error messages.

But now I have no intentions to switch back to Windows, also planning to remove the dualboot in the future.

seth · 2026-11-04 20:30:12

I did the power cut and now it's working fine without these error messages.

And what's the impact on the S3?
The usb device certainly acts up quite a bit during the wakeup.

Lukasas · 2026-11-04 20:34:01

It still behaves the same.
I did the suspend and wake up again with the SysRq enabled so I could reboot the system instead of hard reseting it.

This is journal from that attempt

https://termbin.com/hzh5o

seth · 2026-11-04 20:45:29

Nov 04 21:22:21 lukas-arch kernel: [drm:__nv_drm_semsurf_wait_fence_work_cb [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to register auto-value-update on pre-wait value for sync FD semaphore surface

https://github.com/NVIDIA/open-gpu-kern … ssues/1125
https://github.com/hyprwm/hyprlock/issues/1030

Can you try to suspend/wake the system from some random X11 session (openbox, maybe w/ picom just to add some GL client)?

Lukasas · 2026-11-04 21:03:43

I tried the OpenBox and got stuck too. It took like 4 tries but at the 4th black screen, no cursor, waited a little longer but still nothing, rebooted with SysRq

//edit

I do not have hyprland but I can see the similarities. I waited for like 5 minutes nothing, once I waited for like 1 hour and the system stayed the same - black screen. Could not switch to TTY, could not do anything.

Last edited by Lukasas (2026-11-04 21:11:12)

seth · 2026-11-04 21:27:28

__nv_drm_semsurf_wait_fence_work_cb should™ be gone though?
If not, it's maybe coming from the DM (plasma-login-greeter)?

Lukasas · 2026-11-04 21:35:29

yes, the message

[drm:__nv_drm_semsurf_wait_fence_work_cb [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to register auto-value-update on pre-wait value for sync FD semaphore surface

is gone, in my last journal it does not appeared yet still got stuck at black screen
even tried to disable my display manager (plasmalogin) and tried this

cat > ~/.xinitrc <<'EOF'
picom --backend glx &
xterm &
exec openbox
EOF
startx

but still stuck and the black screen, while it was there, I also tried to plug one monitor into the igpu, but it was black screen too..

seth · Yesterday 08:27:52

Can you post the journal for that (we're eliminating noise to figure what actually matters)

Lukasas · Yesterday 14:55:55

This is from the openbox session.

https://termbin.com/ydz0

Can't find anything useful or anything that would cause the hang.

seth · Yesterday 16:00:03

Nov 04 21:57:59 lukas-arch kernel: PM: suspend exit
Nov 04 21:58:04 lukas-arch kernel: [drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Flip event timeout on head 0
Nov 04 21:58:07 lukas-arch kernel: [drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Flip event timeout on head 1
Nov 04 21:58:10 lukas-arch kernel: [drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Flip event timeout on head 2
Nov 04 21:59:05 lukas-arch kernel: PM: suspend exit
Nov 04 21:59:09 lukas-arch kernel: [drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Flip event timeout on head 0
Nov 04 21:59:12 lukas-arch kernel: [drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Flip event timeout on head 1
Nov 04 21:59:15 lukas-arch kernel: [drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Flip event timeout on head 2
Nov 04 21:59:59 lukas-arch kernel: PM: suspend exit
Nov 04 22:00:24 lukas-arch kernel: PM: suspend exit
Nov 04 22:00:46 lukas-arch kernel: PM: suspend exit
Nov 04 22:00:50 lukas-arch kernel: nvidia-modeset: WARNING: GPU:0: Lost display notification (0:0x00000000); continuing.

Only the last one has "Lost display notification", I assume that's the failing one?
Shows up in https://forums.linuxmint.com/viewtopic.php?t=368325

On a limb, what if you ditch zram in favor of zswap (and a swap file)?
https://wiki.archlinux.org/title/Zswap

Lukasas · Yesterday 17:18:00

So, I tried the exit 0 in nvidia-sleep.sh, the system did not want to go to sleep, still redirecting to lock... I just noticed some messages so I took a picture of it

usb 10-5.3.3: device descriptor read/64, error -71
nvidia 0000:01:00.0: PM: pci_pm_suspend(): nv_pmops_suspend [nvidia] returns -5
nvidia 0000:01:00.0: PM: dpm_run_callback(): pci_pm_suspend returns -5
nvidia 0000:01:00.0: PM: failed to suspend async: error -5
PM: Some devices failed to suspend, or early wake event detected

So I disconnected everything except mouse and keyboard.
Same problem
I ran sleep 10 && systemctl suspend
and it went to "sleep" but not actually sleeping, the PC was still on except all screens went black.
When I connected mouse and keyboard and did something it went to lock screen and I could log back in.

I removed the exit 0 and tried the same thing sleep 10...
The PC went to sleep but when I connected peripherals, I could not wake it up.
I rebooted with SysRq commands.

//edit

I also see in the mesages this:

amdgpu 0000:79:00.0: Power consumption will be higher as BIOS has not been configured for suspend-to-idle.
To suspend-to-idle change the sleep mode in BIOS setup.

I believe that explains, why the PC stayed on instead of going into the sleep mode with the "exit 0" in nvidia-sleep.sh

I tried disabling the zram, enabling the zswap, rebooted, checked if the zswap is enabled and zram disabled and tried suspending the system and again, could not wake it up so I rebooted with SysRq.

Last edited by Lukasas (Yesterday 18:50:12)

seth · Yesterday 20:44:40

Sorry, the idea of the link was only to convey the significance of the symptom, not attempt the approach taken there (which as you figured isn't a good idea and kinda nonsensical - you'd just disable preservation altogether)

You could try to set "nvidia.NVreg_UseKernelSuspendNotifiers=0" and generally make sure the services are disabled so no VRAM preservation is attempted.

amdgpu 0000:79:00.0: Power consumption will be higher as BIOS has not been configured for suspend-to-idle.
To suspend-to-idle change the sleep mode in BIOS setup.

That's weird but how does the system behave on s2idle?
https://wiki.archlinux.org/title/Power_ … end_method

Arch Linux

#1 2026-11-02 12:18:17

RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#2 2026-11-03 08:20:06

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#3 2026-11-04 19:22:35

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#4 2026-11-04 19:46:00

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#5 2026-11-04 20:02:01

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#6 2026-11-04 20:21:50

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#7 2026-11-04 20:30:12

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#8 2026-11-04 20:34:01

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#9 2026-11-04 20:45:29

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#10 2026-11-04 21:03:43

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#11 2026-11-04 21:27:28

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#12 2026-11-04 21:35:29

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#13 Yesterday 08:27:52

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#14 Yesterday 14:55:55

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#15 Yesterday 16:00:03

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#16 Yesterday 17:18:00

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#17 Yesterday 20:44:40

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

Board footer