I’ve had this computer with this configuration for the last 9 months, and for the last 2 or 3, I’ve had complete display freezes after a few days of uptime. The lowest was about 3 days, but usually more like 7-10. I believe it’s a nvidia-open driver regression.
The problem is real, disclaimer that the following was generated by Claude after its investigation of the system. I don’t understand all the details but maybe someone can confirm if they make sense.
# Deadlock in nvidia-modeset DIFR prefetch holds PM lock, hangs all KMS atomic commits (610.x, open kernel modules)
Summary
On an RTX 5080 with the open kernel modules, the `nvidia-modeset` kernel thread intermittently
wedges inside DIFR surface prefetch while holding the NVKMS PM lock. Every subsequent
`DRM_IOCTL_MODE_ATOMIC` from the Wayland compositor then blocks in uninterruptible sleep and
never returns, freezing the desktop permanently. The kernel itself stays healthy — the machine
remains reachable over SSH — but the display session cannot be recovered without a reboot.
I have reproduced this six times since 2026-05-30 across three driver versions
(595.71.05, 610.43.02/03, 610.57.04). The failure interval has shortened from ~38 days to a
consistent ~9 days on 610.57.04.
The documented workaround `NVreg_RegistryDwords=“RMDisableDIFR=1”` does **not** prevent it
(details below).
System
| Driver | `nvidia-open` 610.57.04 (also seen on 610.43.03, 610.43.02, 595.71.05) |
| GPU | NVIDIA GeForce RTX 5080, GB203 `[10de:2c02]` rev a1, PCI `02:00.0` |
| iGPU | Intel Arrow Lake-S `[8086:7d67]` rev 06, PCI `00:02.0`, `i915` |
| CPU | Intel Core Ultra 9 285 |
| Board | MSI PRO B860-VC WIFI (MS-7E41), BIOS 1.A06 |
| OS | Arch Linux |
| Kernel | 7.1.8-arch1-3 at time of last hang (also seen on 7.1.x earlier) |
| Compositor | KWin 6.7.4 (KDE Plasma 6.7.4), Wayland |
Kernel command line:
```
nvidia_drm.modeset=1 nvidia_drm.fbdev=1
```
`/etc/modprobe.d/nvidia.conf`:
```
options nvidia NVreg_RegistryDwords=“RMDisableDIFR=1”
options nvidia NVreg_PreserveVideoMemoryAllocations=1
```
Distribution-supplied `/usr/lib/modprobe.d/nvidia-sleep.conf` additionally sets
`NVreg_UseKernelSuspendNotifiers=1` and `NVreg_TemporaryFilePath=/var/tmp`.
Display topology (relevant)
This is a dual-GPU system. Displays are split across both:
- **NVIDIA `DP-6`**: ASUS PA248, 1920x1200 @ 59.95 Hz — the only head owned by `nvidia-modeset`
- **Intel `DP-1`**: Dell U4025QW, 5120x2160 @ 120 Hz, scale 1.5, connected via Thunderbolt
VRR is disabled on both outputs (`vrrPolicy: Never`), HDR off, no custom modes.
Stack trace
Captured 2026-08-27 13:34:03 (`hung_task` at 122 s). The waiter:
```
INFO: task kwin_wayland:1772 blocked for more than 122 seconds.
task:kwin_wayland state:D stack:0 pid:1772 tgid:1772 ppid:1765
Call Trace:
__schedule+0x459/0x1870
schedule+0x27/0xa0
schedule_timeout+0xdc/0x120
__down_common+0xfe/0x340
down+0x53/0x70
nvkms_ioctl_from_kapi_try_pmlock+0x4a/0xa0 [nvidia_modeset]
ApplyModeSetConfig+0x5ed/0xda0 [nvidia_modeset]
nv_drm_atomic_apply_modeset_config+0x7b0/0x890 [nvidia_drm]
? nv_drm_plane_atomic_check+0x109/0x5a0 [nvidia_drm]
drm_atomic_check_only+0x5c4/0x9f0
drm_mode_atomic_ioctl+0x8f2/0xdb0
drm_ioctl_kernel+0xae/0x100
drm_ioctl+0x2d8/0x570
__x64_sys_ioctl+0xb9/0x100
do_syscall_64+0xaa/0x660
entry_SYSCALL_64_after_hwframe+0x76/0x7e
```
And the lock holder, which the kernel identifies explicitly:
```
INFO: task kwin_wayland:1772 blocked on a semaphore likely last held by task nvidia-modeset/:672
task:nvidia-modeset/ state:R running task stack:0 pid:672 tgid:672 ppid:2
Call Trace:
? __hrtimer_rearm_deferred+0x62/0x160
? raw_spin_rq_lock_nested+0x26/0xb0
? __schedule+0xf0f/0x1870
? clockevents_program_event+0x77/0x230
? asm_sysvec_apic_timer_interrupt+0x1a/0x20
? nvWriteGpEntry+0x115/0x3e0 [nvidia_modeset]
? __schedule+0x461/0x1870
? nvPushSetObject+0xb1/0x170 [nvidia_modeset]
? nvPushKickoff+0x2c/0x50 [nvidia_modeset]
? PrefetchHelperSurfaceEvo+0x4df/0x6f0 [nvidia_modeset]
? nvDIFRPrefetchSurfaces+0x158/0x240 [nvidia_modeset]
? __pfx__main_loop+0x10/0x10 [nvidia_modeset]
? DifrPrefetchEventDeferredWork+0x16/0x30 [nvidia_modeset]
? nvkms_kthread_q_callback+0xe6/0x170 [nvidia_modeset]
? _main_loop+0x10e/0x160 [nvidia_modeset]
? kthread+0xe4/0x120
? ret_from_fork+0x2a7/0x330
? ret_from_fork_asm+0x1a/0x30
```
Note the holder is reported `state:R` (running), not sleeping — it appears to be spinning
inside the DIFR prefetch path rather than blocked on something else, and it never releases the
lock. The `i915` frames in the waiter’s trace are unrelated interrupt context, not part of the
blocking path.
The trace is byte-identical across all six occurrences, differing only in PIDs and module
build IDs. On 2026-07-07 the pile-up extended beyond the compositor: `Xorg`,
`WaylandEventThr`, `chromium`, `firefox`, and eventually `systemd` all entered `D` state
behind the same semaphore.
Occurrences and version history
| Date | Driver | Kernel-visible symptom |
|---|---|---|
| 2026-05-30 07:52 | 595.71.05 | `nvDIFRPrefetchSurfaces` deadlock |
| 2026-07-07 16:31 | 610.43.02 | same, cascaded to Xorg/chromium/firefox/systemd |
| 2026-07-31 20:53 | 610.43.03 | same |
| 2026-08-09 10:26 | 610.43.03 | same |
| 2026-08-18 12:02 | 610.57.04 | same |
| 2026-08-27 13:34 | 610.57.04 | same |
The same machine and display configuration ran from 2025-11-25 to 2026-05-30 with **zero**
hung-task events of any kind, across driver versions 580.105.08, 580.119.02, 590.48.01, and
595.58.03. The first occurrence is on 595.71.05, which suggests a regression introduced in
that release.
I cannot fully isolate the trigger: KWin was also updated (6.6.4 → 6.6.5) eight days before
the first occurrence. However, the deadlock itself is entirely within `nvidia_modeset` — its
own kthread holds its own PM lock — so userspace commit patterns should at most expose the
race, not cause it.
`RMDisableDIFR=1` does not prevent this
I added `NVreg_RegistryDwords=“RMDisableDIFR=1”` on 2026-07-07, immediately after the second
occurrence. The setting is confirmed applied to the running driver:
```
grep RegistryDwords /proc/driver/nvidia/params
RegistryDwords: “RMDisableDIFR=1”
```
Four further DIFR deadlocks occurred after that (2026-07-31, 08-09, 08-18, 08-27), all with
`nvDIFRPrefetchSurfaces` in the holder’s stack. The `modconf` hook is present in my initramfs,
so the option applies to modules loaded early in boot as well.
Either the key does not gate this code path, or it is not being honored.
Additional observation: rate of failed atomic commits
KWin logs `atomic commit failed: Device or resource busy` (EBUSY from
`drmModeAtomicCommit`) throughout normal operation. Two things may be relevant:
- **610.57.04 substantially increased the baseline rate** — median went from 7/hour to
20/hour, and hours exceeding 50 failures went from 4% to 26% of uptime. - On 610.57.04, both hangs were preceded by a steep escalation in that rate over the
final 1–2 hours (to 300–500/hour). On 610.43.03 the hangs occurred with no such
escalation.
This may indicate the same underlying contention becoming more frequent before it becomes
terminal.
Reproduction
I have no deterministic reproducer. It occurs during ordinary desktop use on a ~9-day
interval on 610.57.04, with no correlation I can find to specific applications, suspend/resume
cycles, or display configuration changes. It has never occurred within the first few days of
a boot.
Impact and workaround
The desktop session is unrecoverable; only a reboot restores it. Because the freeze arrives
without warning, unsaved work is lost.
The only mitigation I have found is to disconnect the single display attached to the NVIDIA
GPU, leaving it with no active head. That is what I am now running. It is not a
satisfactory long-term answer on a machine with a discrete GPU installed for display use.
What would help
- Confirmation of whether `RMDisableDIFR=1` is expected to disable the
`DifrPrefetchEventDeferredWork` → `nvDIFRPrefetchSurfaces` path, and if not, the correct
way to disable DIFR entirely. - Whether the dual-GPU topology (NVIDIA driving a single secondary head while an Intel iGPU
drives the primary over Thunderbolt) is a known factor.
I can supply `nvidia-bug-report.sh` output, full journals for any of the six occurrences, or
run instrumented builds on request. The machine reproduces this reliably on roughly a
nine-day cycle.