Display freezes on display blank — KMS thread blocked on semaphore held by nvidia-modeset stuck in nvDIFRPrefetchSurfaces (610.57.04, still present)

[Awin-G]

NVIDIA Open GPU Kernel Modules Version

610.57.04 (git tag 610.57.04, commit e4a5faa), installed via Arch nvidia-open-dkms.

Confirm not proprietary driver

⚠️ NOT confirmed. This was observed with the open kernel driver only. The deadlock is in nvidia_modeset (nvkms) / nvidia_drm, code shared with the proprietary driver, so it likely affects the proprietary driver as well. I have not been able to test the proprietary driver on this machine.

OS / Kernel

• OS: Arch Linux (rolling)
• Kernel: 7.1.6-zen1-1-zen (freeze reproduced on 7.1.5-zen1-2-zen)
• Stable release kernel (zen flavor, not a -rc)
• Display server: GNOME Wayland

Hardware

• GPU: NVIDIA GeForce RTX 4060 Laptop GPU (nvidia-smi -L)
• Hybrid laptop: AMD Radeon 680M iGPU drives the internal panel (fbcon primary); the NVIDIA GPU drives an external HDMI monitor
• CPU: AMD Ryzen 7 7735HS

Describe the bug

The display freezes during normal use; the desktop becomes unresponsive and never recovers — only a hard reboot (or SysRq) recovers. The system itself stays alive (SSH/background services keep running). First observed 2026-07-13, recurring across driver versions, and still present on the latest 610.57.04.

Kernel hung-task watchdog output, identical every occurrence:

INFO: task KMS thread:9236 blocked for more than 122 seconds.
      Tainted: G           OE       7.1.5-zen1-2-zen #1
task:KMS thread      state:D
  nvkms_ioctl_from_kapi_try_pmlock+0x4a/0xa0 [nvidia_modeset]
  ApplyModeSetConfig+0x169/0xda0 [nvidia_modeset]
  nv_drm_atomic_apply_modeset_config+0x7fb/0x920 [nvidia_drm]
  drm_atomic_check_only+0x5c4/0x9f0
  drm_atomic_commit+0x71/0xe0
  drm_mode_atomic_ioctl+0xdb8/0x1070
INFO: task KMS thread:9236 blocked on a semaphore likely last held by task nvidia-modeset/:591
task:nvidia-modeset/ state:R  running
  nvWriteGpEntry+0x10c/0x3e0 [nvidia_modeset]
  nvPushKickoff+0x2c/0x50
  PrefetchHelperSurfaceEvo+0x4df/0x6f0
  nvDIFRPrefetchSurfaces+0x158/0x240
  DifrPrefetchEventDeferredWork+0x16/0x30
  nvkms_kthread_q_callback+0xe6/0x170
  _main_loop+0x10e/0x160

The nvidia-modeset kthread spins (state R) holding the nvkms pmlock while the KMS thread waits forever on it → display deadlock.

To Reproduce

1. Hybrid AMD+NVIDIA laptop, external monitor connected to the NVIDIA output (HDMI).
2. Let the display auto-blank (GNOME PowerSaveMode / DPMS off).
3. Freeze within ~minutes (sometimes immediately on blank/unblank).
4. Also observed with screen-content capture (GNOME screenshot/screencast) and with several concurrent display clients (e.g. multiple terminal AI agents doing screen reads).
5. Only a hard reboot recovers.

Bug Incidence

Sometimes (usually on display blank)

nvidia-bug-report.log.gz

Generated with nvidia-bug-report.sh for 610.57.04. I could not attach it through this form/API; the stack trace and environment above are the essential content. I can provide the file on request.

More Info

• Workaround that fully avoids it: disable the display auto-blank (e.g. GNOME "Caffeine" extension always on). The freeze only occurs when a display modeset (blank) is performed on an NVIDIA-owned output.
• The internal laptop panel is driven by the AMD iGPU; only the external HDMI monitor is NVIDIA-owned. Before switching the internal panel MUX away from the dGPU (独显直连 / discrete-direct), the freeze also occurred when the internal panel blanked.

[Awin-G]

Clarification on the symptom: the screen does not go blank/black — the last rendered frame stays frozen on the display, the desktop is fully unresponsive (no input, no cursor), and only a hard reboot (or SysRq) recovers. "Blank" in the title refers to the trigger (DPMS off / PowerSaveMode modeset), not the symptom. This is consistent with the display-pipeline deadlock shown in the hung-task stack (KMS thread blocked on the pmlock while nvidia-modeset spins in nvWriteGpEntry).

[Awin-G]

Update: stable reproduction + verified local mitigation

Two follow-ups — this turned out to be reliably reproducible, and locally mitigable.

Corrected reproduction recipe (my earlier "display blank" description was a misdiagnosis; the reliable trigger is resume-time display activity):

1. Disable any idle inhibitor (e.g. the GNOME Caffeine extension).
2. Connect an external monitor to the NVIDIA output (hybrid AMD+NVIDIA laptop: internal panel on AMD iGPU, external monitor on NVIDIA HDMI).
3. Manually suspend → immediately resume → log back in.
4. Within ~1–2 minutes of resume, perform display activity (e.g. drag a window onto the external monitor).
5. Repeat. The freeze lands within a few rounds.

Confirmed hung-task stack (identical every occurrence):

KMS thread  state:D
  nvkms_ioctl_from_kapi_try_pmlock+0x4a/0xa0 [nvidia_modeset]
  ApplyModeSetConfig+0x169/0xda0 [nvidia_modeset]
  nv_drm_atomic_apply_modeset_config+0x7fb/0x920 [nvidia_drm]
nvidia-modeset/  state:R
  nvWriteGpEntry+0x10c/0x3e0 [nvidia_modeset]
  nvPushSetObject+0xb1/0x170
  nvPushKickoff+0x2c/0x50
  PrefetchHelperSurfaceEvo+0x4df/0x6f0
  nvDIFRPrefetchSurfaces+0x158/0x240
  DifrPrefetchEventDeferredWork+0x16/0x30
  _main_loop+0x10e/0x160

Root cause in code: nvWriteGpEntry() in src/common/unix/nvidia-push/src/nvidia-push.c contains an unbounded busy-wait:

while (nextGpPut == ReadGpGetOffset(push_buffer)) {
    if (nvPushCheckChannelError(push_buffer)) { ... return FALSE; }
}

When the DIFR prefetch CE channel stalls (GET never advances, e.g. while the display engine re-initializes after resume), this spins forever holding the nvkms pmlock, so the KMS thread's modeset blocks → permanent display freeze (system otherwise alive; only hard reboot recovers).

Local mitigation verified: I built a patch that bounds this wait to 1s only on the DIFR prefetch channel — added a boundedKickoff flag to NvPushChannelRec, set it in AllocDIFRPushChannel, and in nvWriteGpEntry time out (and return FALSE) only when boundedKickoff && !noTimeout. On timeout the prefetch fails and DIFR stays disabled, so the display no longer deadlocks. Result: the stall now logs nvWriteGpEntry: timed out waiting for GPFIFO space and the screen does not freeze — reproduced and caught 4/4 times, zero KMS thread blocked this boot. The change is scoped so the 3D/flip channels keep their original unbounded semantics.

This is a workaround, not a proper fix: the CE channel should not be left in a state where nvWriteGpEntry can wait forever. A proper fix would bound the wait with channel recovery on timeout, or fix the DIFR CE stall after resume.

Minor, possibly related: occasional 1–2 frame rendering artifacts (white→purple lines) while dragging windows, not the core issue.

Disclosure: The reproduction, root-cause analysis, and local mitigation patch for this report were produced almost entirely by an AI coding agent (DeepSeek V4 Flash model, running via the Claude Code harness) on the reporter's machine; the reporter performed the manual reproduction steps and hardware testing.

[Awin-G]

Correction: the diff in my previous comment had a rendering artifact from the diff tool (a pre-existing return FALSE showed as inserted). Here is the clean, validated patch — it applies cleanly to pristine 610.57.04 (patch -p1) and produces byte-identical results to the tested build.

diff --git a/src/common/unix/nvidia-push/interface/nvidia-push-types.h b/src/common/unix/nvidia-push/interface/nvidia-push-types.h
--- a/src/common/unix/nvidia-push/interface/nvidia-push-types.h
+++ b/src/common/unix/nvidia-push/interface/nvidia-push-types.h
@@ -135,6 +135,7 @@
     NvBool          noTimeout                : 1;
     NvBool          ignoreChannelErrors      : 1;
     NvBool          channelErrorOccurred     : 1;
+    NvBool          boundedKickoff           : 1;
 
     NvU32           channelHandle[NV_MAX_SUBDEVICES];
     NvU32           pushbufferHandle;
diff --git a/src/nvidia-modeset/src/nvkms-difr.c b/src/nvidia-modeset/src/nvkms-difr.c
--- a/src/nvidia-modeset/src/nvkms-difr.c
+++ b/src/nvidia-modeset/src/nvkms-difr.c
@@ -434,6 +434,8 @@
         return FALSE;
     }
 
+    /* DIFR prefetch is best-effort; never let it hang the display stack. */
+    pDifr->prefetchPushChannel.boundedKickoff = TRUE;
 
     return TRUE;
 }
diff --git a/src/common/unix/nvidia-push/src/nvidia-push.c b/src/common/unix/nvidia-push/src/nvidia-push.c
--- a/src/common/unix/nvidia-push/src/nvidia-push.c
+++ b/src/common/unix/nvidia-push/src/nvidia-push.c
@@ -349,6 +349,7 @@
     NvU32 *gpPointer;
     const NvU32 entriesNeeded = NV_PUSH_NUM_GPFIFO_ENTRIES_PER_KICKOFF;
     NvPushDevicePtr pDevice = push_buffer->pDevice;
+    NvU64 kickoffDeadline;
 
     FillGpEntry(&push_buffer->main, putOffset, &gpEntry0, &gpEntry1);
 
@@ -358,12 +359,27 @@
 
     nvAssert((nextGpPut % 2) == 0);
 
-    // Wait for a free entry in the buffer
+    // Wait for a free entry in the buffer.  Channels flagged with
+    // boundedKickoff (currently only the DIFR prefetch channel) give up
+    // after 1s instead of waiting forever, so a stalled channel fails the
+    // kickoff rather than deadlocking the display stack.  All other
+    // channels keep the original unbounded semantics.
+    if (push_buffer->boundedKickoff && !push_buffer->noTimeout) {
+        kickoffDeadline = nvPushImportGetMilliSeconds(pDevice) + 1000;
+    }
     while (nextGpPut == ReadGpGetOffset(push_buffer)) {
         if (nvPushCheckChannelError(push_buffer)) {
             nvAssert(!"A channel error occurred in nvWriteGpEntry()");
             return FALSE;
         }
+        if (push_buffer->boundedKickoff && !push_buffer->noTimeout &&
+            nvPushImportGetMilliSeconds(pDevice) > kickoffDeadline) {
+            nvPushImportLogError(pDevice,
+                "nvWriteGpEntry: timed out waiting for GPFIFO space "
+                "(get=%u put=%u); aborting kickoff",
+                ReadGpGetOffset(push_buffer), push_buffer->gpPutOffset);
+            return FALSE;
+        }
     }
     gpPointer[0] = gpEntry0;
     gpPointer[1] = gpEntry1;

[Awin-G]

Confirmed same bug family as these reports:

• DIFR Prefetch causes a freeze in pop_os #1177 (Pop!_OS, RTX 5070, 580.159) — identical stack (nvWriteGpEntry → nvPushKickoff → PrefetchHelperSurfaceEvo → nvDIFRPrefetchSurfaces → DifrPrefetchEventDeferredWork), DPMS-triggered
• [595.71.05 open] CPU soft lockup in nvDIFRPrefetchSurfaces on S3 resume — Blackwell mobile (10de:2c59), kernel 6.17 #1205 (S3 resume, Blackwell mobile, 595.71) — soft lockup in the same DIFR prefetch path, "Always" on suspend/resume
• Display freezes requiring reboot usually shortly after resuming from suspend #1167 (Arch, RTX 4090 Laptop, 595.71) — identical full stack (nvWriteGpEntry → nvPushSetObject/nvPushKickoff → PrefetchHelperSurfaceEvo → nvDIFRPrefetchSurfaces), freeze ~minutes after resume on hybrid dGPU external monitor
• Wayland: kwin_wayland 6.7 hangs (hung task / deadlock) after waking monitors from power-saving mode with hybrid AMD/NVIDIA (nvidia open driver) #1231 (KDE, AMD iGPU + RTX 4060 Laptop, 610.43) — hardware nearly identical to this report, DPMS wake deadlock

Common thread: nvidia-modeset spins in the unbounded while (nextGpPut == ReadGpGetOffset(...)) of nvWriteGpEntry during a DIFR prefetch, holding the nvkms pmlock → display deadlock. Spans GPUs RTX 4060 Laptop → RTX 5070/4090 and drivers 580→610, all triggered by resume/DPMS-wake display activity on hybrid setups.

The mitigation patch in this issue is scoped to the DIFR channel and verified locally (4/4 stalls caught, 0 KMS thread blocked). It should apply to the others if their hang is the nvWriteGpEntry path (confirmed for #1177/#1167; pending stack confirmation for #1205/#1231).

[broscr]

Confirming this on 610.57.04, RTX 5070 Ti Mobile — identical stack, same trigger pattern (hybrid + external monitor + lock/unlock)

Version / OS

• nvidia-driver-open 610.57.04-1ubuntu1 (Ubuntu CUDA repo, apt install nvidia-open)
• OS: Ubuntu 26.04 LTS
• Kernel: 7.0.0-29-generic (also reproduced on 7.0.0-14-generic)
• Stable release kernel, not -rc

Hardware

• GPU 0 (dGPU): NVIDIA GeForce RTX 5070 Ti Mobile (GB205M, 10de:2f58)
• iGPU: Intel Arrow Lake-S (8086:7d67)
• Hybrid laptop, internal panel (eDP-2) + external monitor on HDMI-1 connected to the NVIDIA output — same topology as this issue and Wayland: kwin_wayland 6.7 hangs (hung task / deadlock) after waking monitors from power-saving mode with hybrid AMD/NVIDIA (nvidia open driver) #1231.

Describe the bug

Full desktop freeze (GNOME Wayland), no input, no cursor, only recoverable via hard power-off — SysRq unavailable. Two occurrences so far, both shortly after unlocking the session:

• 2026-08-13 14:57 (first occurrence)
• 2026-08-14 13:38–13:41 (second occurrence)

Both boots only started happening after the driver was auto-upgraded from 595.91.07 to 610.57.04 via the nvidia-open meta-package on 2026-08-13 — never observed on 595.91.07 before that.

Reproduction pattern

Matches the recipe in this issue almost exactly:

1. Session locked (screen idle / gdm-password keyring lock).
2. Unlock (gkr-pam: unlocked login keyring at 13:35:35).
3. Freeze within ~3 minutes of unlock (13:38:49), with a second hung-task report at 13:40:52 as the same thread is still stuck.

Hung-task log (identical signature to the reports above)

INFO: task KMS thread:7872 blocked for more than 122 seconds.
      Tainted: G           OE       7.0.0-29-generic #29-Ubuntu
task:KMS thread      state:D
  nvkms_ioctl_from_kapi_try_pmlock+... [nvidia_modeset]
  ...
INFO: task KMS thread:7872 blocked on a semaphore likely last held by task nvidia-modeset/:536
task:nvidia-modeset/ state:R  running
  RIP: 0010:nvWriteGpEntry+0xf9/0x370 [nvidia_modeset]
  ...
  nvPushKickoff+0x28/0x50 [nvidia_modeset]
  PrefetchHelperSurfaceEvo+0x45c/0x650 [nvidia_modeset]
  nvDIFRPrefetchSurfaces+0x135/0x1f0 [nvidia_modeset]
  DifrPrefetchEventDeferredWork+0x16/0x30 [nvidia_modeset]
  nvkms_kthread_q_callback+0xe9/0x190 [nvidia_modeset]

Second report ~2 minutes later, same PID, same nvWriteGpEntry RIP (different offset — still spinning), confirming it's a livelock, not a one-off stall:

INFO: task KMS thread:7872 blocked for more than 245 seconds.
task:nvidia-modeset/ state:R  running
  RIP: 0010:nvWriteGpEntry+0x58/0x370 [nvidia_modeset]

gnome-shell also logged Could not release device '/dev/input/event0' (13,64): Timeout was reached while the KMS thread was stuck, consistent with the compositor being unable to proceed at all.

Notes

• Checked NVIDIA's data-center release notes for 610.57.04 — no mention of this issue in "Known Issues," so it appears undocumented there (this is a GeForce/laptop hybrid config, may not be covered by that doc).
• Ubuntu's nvidia-driver-open DKMS package ships nvidia-modeset/nv-modeset-kernel.o_binary as a precompiled blob (Kbuild symlinks it straight into nvidia-modeset.ko), so the source-level mitigation patch posted above can't be applied on top of the distro package without building the full open-gpu-kernel-modules tree from source ourselves — noting this in case it's useful context for anyone else on a distro-packaged build hitting the same wall.

Happy to test the patch from this thread against a from-source build if that would help narrow this down further, or to pull any additional logs.

[handkerchief333]

I can confirm what appears to be the same nvidia_modeset / DIFR deadlock on a different hybrid laptop configuration.

System

• Laptop: Acer Predator PHN16-71
• iGPU: Intel UHD Graphics 770 (Alder Lake-HX, i915)
• dGPU: NVIDIA GeForce RTX 4060 Laptop GPU
• OS: Fedora 44 KDE
• Session: KDE Plasma / KWin Wayland
• Kernel at time of freeze: 7.1.8-200.fc44.x86_64
• NVIDIA driver / open kernel module: 610.57.04
• Suspend mode: s2idle [deep], with deep selected
• NVIDIA Runtime D3: enabled, fine-grained
• nvidia-suspend.service, nvidia-resume.service and nvidia-hibernate.service: enabled

Trigger / behaviour

In my case the problem is strongly correlated with suspend/resume rather than only display blanking.

It has occurred multiple times, typically after approximately 2–3 deep suspend/resume cycles followed by continued normal desktop use with multiple applications open.

The resume itself succeeds and the system can continue working normally for some time. Eventually the entire graphical session freezes:

• display stops updating
• mouse and normal keyboard input stop working
• Ctrl+Alt+F3 does not switch to a TTY
• fans ramp up
• Magic SysRq remains functional

On the latest occurrence I used SysRq w and l before rebooting with REISUB.

SysRq w: KWin blocked inside NVIDIA modesetting

The blocked task was kwin_wayland in uninterruptible sleep:

task:kwin_wayland    state:D

__schedule
schedule
schedule_timeout
___down_common
__down
down
nvkms_ioctl_from_kapi_try_pmlock [nvidia_modeset]
ApplyModeSetConfig [nvidia_modeset]
nv_drm_atomic_apply_modeset_config [nvidia_drm]
drm_atomic_check_only
drm_mode_atomic_ioctl
drm_ioctl_kernel
drm_ioctl

SysRq l: NVIDIA modeset thread stuck in DIFR prefetch

At the same time an nvidia-modeset/ kernel thread was active in:

nvWriteGpEntry [nvidia_modeset]
nvPushKickoff [nvidia_modeset]
PrefetchHelperSurfaceEvo [nvidia_modeset]
nvDIFRPrefetchSurfaces [nvidia_modeset]
DifrPrefetchEventDeferredWork [nvidia_modeset]
nvkms_kthread_q_callback [nvidia_modeset]
_main_loop [nvidia_modeset]

This looks essentially identical to the deadlock reported in this issue: KWin waits for the NVIDIA KMS lock while the nvidia-modeset thread is stuck in the DIFR prefetch path.

The rest of the CPUs were mostly idle according to the SysRq backtrace, and Magic SysRq remained fully responsive. REISUB successfully rebooted the machine.

I did not observe an NVIDIA Xid, OOM condition, thermal critical event or kernel panic preceding the freeze.

I have attached a sanitized kernel SysRq log containing the complete blocked-task and CPU backtraces:

nvidia-freeze-sysrq-public.log

I also generated a full nvidia-bug-report.log.gz immediately after reproducing the problem. I am not attaching that publicly for privacy reasons, but I can provide it privately to NVIDIA if useful.

The interesting additional data point here is that this reproduces the same apparent nvDIFRPrefetchSurfaces / nvWriteGpEntry deadlock on:

• Intel + NVIDIA hybrid graphics instead of AMD + NVIDIA
• Fedora 44 instead of Arch Linux
• KDE/KWin Wayland instead of GNOME Wayland
• repeated S3/deep suspend-resume cycles as the apparent trigger

Please let me know if there are additional traces, module parameters or debug data I can collect during another occurrence.

[albanD]

EDIT: The patch at #1286 fixes this for me locally.

Confirming the same DIFR-path livelock on another RTX 4090 Laptop system, with both the spinning lock holder and blocked KMS thread captured.

System

• Lenovo ThinkPad P1 Gen 6
• NVIDIA GeForce RTX 4090 Laptop GPU, Ada AD103M (10de:2717)
• Fedora 44, GNOME Wayland
• NVIDIA open kernel module 595.71.05
• Kernel 7.1.8-200.fc44

Timeline

• 10:59:01 — dock USB devices enumerated
• 10:59:04 — PFM_REQ_HNDLR_STATE_SYNC_CALLBACK assertion
• 10:59:05 — GNOME Shell recreated its GBM renderer for /dev/dri/card0
• 10:59:40 — local CPU watcher detected nvidia-modeset PID 1426 in state R at 99% of one core
• ~11:00:20 — display froze
• 11:03:20–11:03:50 — SysRq W/L traces captured

Blocked KMS thread

task:KMS thread  state:D  pid:2308  tgid:2261
  __schedule
  schedule
  schedule_timeout
  ___down_common
  __down
  down
  nvkms_ioctl_from_kapi_try_pmlock+0x4a/0xa0 [nvidia_modeset]
  ApplyModeSetConfig+0x59e/0xba0 [nvidia_modeset]
  nv_drm_atomic_apply_modeset_config+0x49b/0x550 [nvidia_drm]
  drm_atomic_check_only
  drm_atomic_nonblocking_commit
  drm_mode_atomic_ioctl

Spinning NVIDIA modeset thread

CPU: 1  PID: 1426  Comm: nvidia-modeset/
RIP: nvWriteGpEntry+0xf0/0x370 [nvidia_modeset]
  nvPushKickoff+0x28/0x50
  PrefetchHelperSurfaceEvo+0x45c/0x650
  nvDIFRPrefetchSurfaces+0xb1/0x1f0
  DifrPrefetchEventDeferredWork+0x16/0x30
  nvkms_kthread_q_callback+0xdb/0x160
  _main_loop+0x112/0x170

A second SysRq L dump 27 seconds later captured the same PID in
nvWriteGpEntry+0xa4/0x370, now on CPU 7, with the same stack pointer and
relevant register values. This confirms sustained execution inside the
nvWriteGpEntry() loop rather than a transient sample.

Released source indicates that the deferred callback holds the global
nvkms_lock. Despite the nvkms_ioctl_from_kapi_try_pmlock name, the KMS
thread successfully takes the shared PM read lock and then blocks in
nvkms_ioctl_common() on down(&nvkms_lock).

This conclusively matches the livelock/deadlock signature reported here. It is
also consistent with the GPFIFO-exhaustion theory in PR #1286, although these
traces do not directly measure GP_GET/PUT or independently prove the preceding
per-timeout ring leak.

CONFIG_DETECT_HUNG_TASK is disabled in Fedora’s kernel, so no automatic
122-second hung-task report was available. SysRq W/L/S/U remained functional;
SysRq B did not reboot this machine during the hang.

I can provide a sanitized complete SysRq/kernel log if useful.