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)

[lusoris]

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: Display freezes on display blank — KMS thread blocked on semaphore held by nvidia-modeset stuck in nvDIFRPrefetchSurfaces (610.57.04, still present) #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), DPMS breaks Adaptive Sync on KWin Wayland #713 (DPMS vs Adaptive Sync on KWin), 615.71.09 regression: blocking atomic commits wait 3 s per head for their own flip on compositor exit / suspend ("Flip event timeout" + nv_flip == NULL WARN) #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.

[Remi4001]

I have the same issue and managed to get a bug report log:

nvidia-bug-report.log.gz

[opariffazman]

Same deadlock on GA102 (RTX 3090), so this is not AD102-specific. Environment is otherwise near-identical to the original report.

Item	Value
GPU	NVIDIA GeForce RTX 3090 (GA102) 10de:2204
Driver	615.71.09 (open)
Kernel	7.2.6-1-cachyos
Compositor	KWin Wayland 6.7.5
Distro	CachyOS
Board	Gigabyte X570 AORUS ELITE, BIOS F37a
Display	DP-2, 3440x1440@240Hz, VRR-capable, HDR enabled

Minimal reproducer

A bare in-kernel connector probe deadlocks the driver. No DPMS cycle and no userspace DDC needed:

echo detect > /sys/class/drm/card1-DP-2/status

The write never returns. It leaves nvidia-modeset/kthread_q in D state and kwin_wayland spinning at 100% of one core.

INFO: task nvidia-modeset/:461 blocked on a semaphore likely last held by task kwin_wayland:1626
  nvkms_ioctl_from_kapi_try_pmlock+0x4b/0x80  [nvidia_modeset]
  nvkms_call_rm+0x4e/0x80                     [nvidia_modeset]
  rmapiControlWithSecInfoTls+0x6f/0xc0        [nvidia]

This reproduces on demand and removes the wait for an idle timeout.

POWERDEVIL_NO_DDCUTIL is not sufficient

The original report applied POWERDEVIL_NO_DDCUTIL=1 pending results. Reporting back on that.

DDC/CI access was removed at the device level, by dropping the uaccess tag that 60-ddcutil-i2c.rules applies:

# /etc/udev/rules.d/60-ddcutil-i2c.rules
SUBSYSTEM=="dri", KERNEL=="card[0-9]*", TAG+="uaccess"

PowerDevil then logs Could not initialize ddcutil API. Not using DDC for monitor brightness and ddci_init Returning EACCES. Confirmed no process holds any /dev/i2c-* handle.

Result:

• Spontaneous deadlocks during idle stopped.
• The reproducer above still deadlocks.

DDC/CI is a trigger, not the root cause. The fault sits in the driver's connector-probe path.

EDID read fails across a DP power cycle

After the monitor powers off and back on:

• /sys/class/drm/card1-DP-2/status reads connected — HPD asserts correctly.
• /sys/class/drm/card1-DP-2/edid returns 0 bytes.
• No hotplug uevent reaches the compositor, so KWin logs There are no outputs - creating placeholder screen.
• Forcing the probe then deadlocks as above.

Differences from the original report

• No Flip event timeout appears in any of 4 deadlocks here.
• Lost display notification and SLI raster lock timeout exceeded appear instead, once each.
• Triggers on physical monitor power-off, not only on DPMS wake.

Diagnostic note

nvidia_drm.fbdev=Y routes the kernel console through the GPU framebuffer. When the driver deadlocks, printk cannot reach the console and the hung-task detector prints nothing. One of 4 deadlocks here produced no trace for this reason. Set nvidia_drm.fbdev=0 to keep traces during a deadlock.

Recovery

SIGKILL never lands on the D-state tasks. systemctl reboot hangs, because every process holding an /dev/nvidia-modeset fd blocks in nvkms_close() during exit, and the user systemd instance then blocks in cgroup_lock_and_drain_offline holding cgroup_mutex. Only SysRq b or a power cycle recovers.

Full kernel log

Complete kernel log covering the deadlock, with MAC addresses and filesystem UUIDs redacted:

https://gist.github.com/opariffazman/3ebe5faf3a5d1d6afded3fb2df3537a9

[theblop]

exact same issue on fedora 44 kde (x11) with 3080ti (DP cable / 5120 x 2160 x 120Hz) / amd 9950x

repro: turn off monitor, turn back on -> no display, 100% cpu for Xorg, but can still ssh into the box.

remediation: downgrade to nvidia drivers 580 (LTS) from rpm fusion (xorg-x11-drv-nvidia-580xx-*)

[oamost]

Confirmed. Your logs match a specific, still-open upstream bug almost exactly — and I verified the trigger in your own journal.

GitHub correlation — near-exact match to issue #1371

open-gpu-kernel-modules #1371 (OPEN) is your crash: same driver 615.71.09, same kernel 7.2.6, GA102/RTX 3090 confirmed by a commenter ( 10de:2204 , you're the Ti  10de:2203 ), no Xid, identical stack ( nvidia-modeset  blocked on a semaphore held by  kwin_wayland , which is stuck in the RM/GSP API path). Upstream root cause: a DisplayPort connector-probe / EDID-read-after-power-cycle race on the RM API lock, triggered by KDE's DDC/CI polling on display power transitions.

Critically, #1371 confirms that  SLI raster lock timeout exceeded  and  Lost display notification  are alternate log lines of the same deadlock — which unifies every seemingly-separate error in your logs into one bug.

Trigger verified in your logs

 org_kde_powerdevil  is running libddcutil DDC/CI ("Watching for display connection changes", 500 ms poll). And a display-power event ( Lost display notification ) precedes every hang onset by 1–3 min:

┌──────┬───────────────────────────┬────────────────────────────────┐
│ Boot │ Lost display notification │ Hang onset │
├──────┼───────────────────────────┼────────────────────────────────┤
│ -8 │ Sep 13 08:08 │ ~08:05 + SLI raster lock 08:14 │
├──────┼───────────────────────────┼────────────────────────────────┤
│ -5 │ Sep 16 06:45 │ 06:47 │
├──────┼───────────────────────────┼────────────────────────────────┤
│ -4 │ Sep 18 09:40 │ 09:43 │
├──────┼───────────────────────────┼────────────────────────────────┤
│ -2 │ Sep 20 10:58 │ 11:01 │
├──────┼───────────────────────────┼────────────────────────────────┤
│ -1 │ Sep 22 11:41 │ 11:42 │
└──────┴───────────────────────────┴────────────────────────────────┘

So: display sleeps/wakes (or powerdevil probes it via DDC/CI) → DP re-probe deadlocks the RM lock →  nvidia-modeset  kthread hangs → freeze. The GSP  crashcat  frames in your trace (GSP firmware asserted) are a detail no one has posted yet on #1371.

Other 615.71.09-specific confirmations

• #1361 — pageflip/"Flip event timeout" regression, explicitly "not present in 610.57.04".
• #1367 — 615.71.09 "Idling display engine timed out" + "Lost display notification", 610.57.04 works.
• Adjacent family (identical symptom, different lock): DIFR livelock #1289 → unmerged fix PR #1286.

Fastest known-good mitigations (from the issues, pending the buildable patch): downgrade to 610.57.04 (multiple reporters confirm it fixes this), and/or disable KDE DDC/CI + display power-off ( POWERDEVIL_NO_DDCUTIL=1 , though insufficient alone). Note  NVreg_EnableGpuFirmware=0  reportedly no longer works on 615.

[oamost]


7. ✅ Workaround applied (2026-09-22) — stays on 615, no rebuild
Removes the confirmed triggers. All reversible.

a)

~/.config/powerdevilrc (backup: ~/.config/powerdevilrc.bak-nvidia615-20260922) 
[AC][Display]
DimDisplayIdleTimeoutSec=-1 # was 60 → no idle DDC/CI dim/undim
TurnOffDisplayIdleTimeoutSec=-1 # (already) never
TurnOffDisplayIdleTimeoutWhenLockedSec=-1 # was -2 → never (even locked)
TurnOffDisplayWhenIdle=false # (already)


b)

~/.config/environment.d/50-nvidia615-ddc-workaround.conf (new) 
POWERDEVIL_NO_DDCUTIL=1


c)
Applied live (so no re-login needed this session):

systemctl --user set-environment POWERDEVIL_NO_DDCUTIL=1
systemctl --user restart plasma-powerdevil.service

Verified
POWERDEVIL_NO_DDCUTIL=1 present in powerdevil’s /proc//environ.
After restart the libddcutil watch/recheck threads and 500 ms poll loop are gone (log shows only Starting libddcutil. library
built Not set at Not set — stubbed).
Dim idle-timer disabled (KIdleTime: invalid timeout: -1000).

Trade-off & residual risk
KDE can no longer set external-monitor brightness over DDC/CI until reverted.
Removes all automated DP re-probes (caused 100% of observed hangs). A manual re-probe (monitor power button, cable swap, resolution
HDR change, KDE Night Color auto-transition) could still theoretically hit the race → consider disabling Night Color auto-switching.

Revert

rm ~/.config/environment.d/50-nvidia615-ddc-workaround.conf
cp ~/.config/powerdevilrc.bak-nvidia615-20260922 ~/.config/powerdevilrc
systemctl --user unset-environment POWERDEVIL_NO_DDCUTIL
# then log out / back in (or restart plasma-powerdevil.service)