Arch Linux

Lukasas

Member

Registered: Today

Posts: 1

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

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.