615.71.09: display deadlock on DPMS wake — KWin modeset holds nvkms pmlock while blocked on RM API lock in DisplayPort getLinkConfig (Flip event timeout)

NVIDIA Open GPU Kernel Modules Version

615.71.09 (CachyOS linux-cachyos-nvidia-open 7.2.6-1, nvidia-utils 615.71.09-1)

Please confirm this issue does not happen with the proprietary driver (of the same version). This issue tracker is only for bugs specific to the open kernel driver.

Not confirmed: observed with the open kernel modules only; I have not tested the proprietary driver on this machine. The deadlock is in nvidia_modeset / nvidia-drm / RM paths that may be shared.

Operating System and Version

CachyOS (Arch Linux based, rolling)

Kernel Release

7.2.6-1-cachyos (stable release kernel, not an -rc). sched_ext scx_bpfland active.

Hardware: GPU

NVIDIA GeForce RTX 4090 (AD102, PCI 0000:06:00.0). The same system also has an Intel Arc A380 (i915) and the AMD Granite Ridge iGPU (amdgpu) enabled, but both monitors are driven by the RTX 4090 over DisplayPort: DP-1 5120x1440 OLED (VRR-capable, HDR on) and DP-2 3840x2160@144 (VRR-capable, HDR on). Board ASUS ProArt X870E-Creator WiFi, BIOS 2402, CPU Ryzen 9 9950X3D.

Describe the bug

After the displays blank on idle (DPMS) under KDE Plasma 6.7.5 / KWin Wayland, the next display wake deadlocks: both monitors stay black, KWin never recovers, and CUDA clients stop making progress at the same moment. The rest of the system keeps running (background services, journald) until a hard reset. It happened several times in one day; one occurrence was captured with the hung-task watchdog.

KWin is inside an atomic modeset that has taken the nvkms power-management lock, and is blocked acquiring the RM API lock during the DisplayPort post-modeset link query:

task:kwin_wayland    state:D  pid:4120
 rwsem_down_read_slowpath
 down_read
 os_acquire_rwlock_read
 portSyncRwLockAcquireRead
 rmapiLockAcquire
 serverTopLock_Prologue
 serverControl
 rmapiControlWithSecInfo
 rmapiControlWithSecInfoTls
 _nv04Control
 nvkms_call_rm
 nvRmApiControl
 DisplayPort::EvoMainLink::getLinkConfig(unsigned int&, unsigned long long&)
 nvDPLibUpdateDpyLinkConfiguration
 nvDPPostSetMode
 KickoffModesetUpdateState
 nvSetDispModeEvo
 nvKmsIoctl
 nvkms_ioctl_from_kapi_try_pmlock
 ApplyModeSetConfig
 nv_drm_atomic_commit
 drm_atomic_commit
 drm_mode_atomic_ioctl
 drm_ioctl
 __x64_sys_ioctl

The nvidia-modeset kthread then waits on the nvkms lock that KWin holds:

INFO: task nvidia-modeset/:392 blocked for more than 122 seconds.
task:nvidia-modeset/ state:D pid:392
 __down_common
 down
 nvkms_kthread_q_callback [nvidia_modeset]
 _main_loop [nvidia_modeset]
 kthread
INFO: task nvidia-modeset/:392 blocked on a semaphore likely last held by task kwin_wayland:4120

Another GPU client exiting blocks behind the same lock:

task:vesktop state:D pid:4819
 down
 nvkms_close
 __fput
 task_work_run
 do_exit

About 16 minutes later:

[drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000600] Flip event timeout on head 0

No Xid, GSP Timeout or NVRM error is logged in any of the affected boots. The holder of the RM API lock is not reported (it is not in D state).

Timeline of the captured occurrence (2026-09-18, local time):

• 07:24:27.058 KDE powerdevil (libddcutil 3.0.1) reads a monitor VCP value over DDC/CI on /dev/i2c-5, the RTX 4090's DP-2 I2C adapter; ioctl() read returns EIO.
• 07:24:27.587 Chrome's GPU process reports GPU state invalid after WaitForGetOffsetInRange.
• ~07:24:28 deadlock begins (first hung-task report at 07:26:30, "blocked for more than 122 seconds").
• 07:40:31 Flip event timeout on head 0.

A DDC/CI EIO from powerdevil also appears a few minutes before the end of two of the other (untraced) hard-reset boots, but not all of them, so it may be a trigger or an early victim of the held lock.

Driver parameters at the time: NVreg_UseKernelSuspendNotifiers=1, NVreg_TemporaryFilePath=/var/tmp, NVreg_InitializeSystemMemoryAllocations=0, NVreg_DynamicPowerManagement=0x00 (runtime D3 reported Disabled), nvidia_drm modeset=1 fbdev=1. nvidia_modeset conceal_vrr_caps was not set; KWin's VRR policy was "Never", but per the README NVIDIA DRM KMS forces VRR-capable displays into VRR mode regardless.

To Reproduce

1. RTX 4090 driving two DisplayPort monitors (VRR-capable, HDR enabled) under KWin Wayland 6.7.5, with KDE powerdevil's DDC/CI support active (the default).
2. Let the displays blank on idle (15 minutes), leave the machine for a while, then wake the displays.
3. Displays stay black; the hung-task watchdog reports the stacks above after 122 s.

Not deterministic: several occurrences in one day, many blank/wake cycles without it.

Bug Incidence

Sometimes

nvidia-bug-report.log.gz

Not attached yet; the machine has since rebooted. I can generate one with nvidia-bug-report.sh on the next occurrence (the system stays reachable while the displays are deadlocked).

More Info

• Related: #1289 (display freeze on blank; there the KMS thread waits on the nvkms lock while nvidia-modeset spins in nvDIFRPrefetchSurfaces; here the modeset path holding the nvkms lock waits on the RM API lock in DisplayPort::EvoMainLink::getLinkConfig), #713 (DPMS vs Adaptive Sync on KWin), #1361 (615.71.09 flip-timeout regression on compositor exit/suspend).
• Mitigations now applied here: nvidia_modeset conceal_vrr_caps=1 and POWERDEVIL_NO_DDCUTIL=1 (stops powerdevil's DDC/CI traffic). I will report back whether the hang recurs.

Start with the reported stacks around nvkms_ioctl_from_kapi_try_pmlock, nvDPPostSetMode, and DisplayPort::EvoMainLink::getLinkConfig in the nvidia_drm and nvidia_modeset paths. Reproduce the DPMS wake sequence with the stated hardware and collect nvidia-bug-report.sh output, then compare behavior with conceal_vrr_caps=1 and POWERDEVIL_NO_DDCUTIL=1. Done means identifying the lock cycle and a verified driver-side fix or a reliably confirmed trigger.