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_ioctlThe 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:4120Another GPU client exiting blocks behind the same lock:
task:vesktop state:D pid:4819
down
nvkms_close
__fput
task_work_run
do_exitAbout 16 minutes later:
[drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000600] Flip event timeout on head 0No 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.058KDE 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 returnsEIO.07:24:27.587Chrome's GPU process reportsGPU state invalid after WaitForGetOffsetInRange.~07:24:28deadlock begins (first hung-task report at07:26:30, "blocked for more than 122 seconds").07:40:31Flip 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
- 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).
- Let the displays blank on idle (15 minutes), leave the machine for a while, then wake the displays.
- 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-modesetspins innvDIFRPrefetchSurfaces; here the modeset path holding the nvkms lock waits on the RM API lock inDisplayPort::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=1andPOWERDEVIL_NO_DDCUTIL=1(stops powerdevil's DDC/CI traffic). I will report back whether the hang recurs.
Source: NVIDIA/open-gpu-kernel-modules