The system was unresponsive during the failure, so I could not run nvidia-bug-report.sh while the machine was stuck. The attached nvidia-bug-report.log.gz was collected after forced power-off and reboot. The actual failure is visible in previous-boot-kernel.log, where nvidia-modeset repeatedly soft-locks in nvWriteGpEntry and the KMS thread is blocked.
previous-boot-kernel.log (1.2 MB)
nvidia-bug-report.log.gz (461.2 KB)
syslog-snippet.txt (4.6 KB)
I have exactly the same problem. RTX 5060 with a Ryzen 7 Linux Mint system.
After some time the system soft-crashes (either directly after waking up from standby or sometimes after the system was running for several hours).
It still reacts to the REISUB sequence.
See the syslog snippet (it is nearly identical to xianchao’s log).
I already tried everything: Using different driver versions (open driver 580 and 595), different kernel versions (6.8, 6.17, etc), downgrading the PCI to Gen4 and Gen2.
The problem persists.
Same soft lockup problem here — adding my data point and a captured stack trace that identifies the culprit as DIFR (Display Idle Frame Refresh).
System:
NVreg_PreserveVideoMemoryAllocations=1, NVreg_UseKernelSuspendNotifiers=1Symptom: Suspend and resume themselves complete perfectly (deep S3 first try, no NVRM errors). Then 20–60 seconds after resume the desktop freezes hard and requires a power-off. Frequency is roughly 1 in every 3–5 resumes; the other resumes are completely clean. Most freezes leave nothing in the journal (journald dies before the watchdog line flushes), but on my latest hit the system stayed half-alive for ~6 minutes and flushed the full trace:
watchdog: BUG: soft lockup - CPU#2 stuck for 365s! [nvidia-modeset/:1002]
RIP: 0010:nvWriteGpEntry+0x100/0x370 [nvidia_modeset]
Call Trace:
nvPushKickoff
PrefetchHelperSurfaceEvo
nvDIFRPrefetchSurfaces
DifrPrefetchEventDeferredWork
nvkms_kthread_q_callback
_main_loop
accompanied by:
INFO: task KMS thread:3440 blocked on a semaphore likely last held by task nvidia-modeset/:1002
So the culprit is the DIFR prefetch: after an S3 resume, GSP raises a DIFR prefetch event (DifrPrefetchEventDeferredWork), and nvWriteGpEntry spins forever waiting for pushbuffer space on a channel the GPU never services. The nvkms kthread soft-locks, the KMS thread blocks on its semaphore, and the whole display stack is dead. DIFR runs fine during normal desktop use — it’s only its first engagement after S3 resume that hits stale state, which explains the variable 20–60s delay (first idle moment after resume) and why silent freezes with no logged stack are the same bug.
What I’ve tried — none of it fixed the lockup:
NVreg_UseKernelSuspendNotifiers=1 (new in 595) instead of the nvidia-suspend/resume services: made suspend fast and clean (also eliminated an NVRM mmuWalkSparsify/VA-space assert storm during eviction) — but the post-resume DIFR lockup still occurs.NVreg_RegistryDwords="RMLpwrMsDifrCgIdleThresholdUs=0xFFFFFFFF;RMLpwrMsDifrSwAsrIdleThresholdUs=0xFFFFFFFF" (found in GSP firmware strings; the idea was to push DIFR idle-entry out to ~71 min so it never engages). Verified active in /proc/driver/nvidia/params at the time of the latest freeze — it locked up anyway. Since the hang enters via a GSP-originated prefetch event, these idle thresholds apparently don’t gate the post-resume prefetch path.Also verified: there is no user-facing way to disable DIFR in 595.71.05 — no nvidia_modeset module parameter, no nvkms config-file key, and RmForceEnableDIFR only forces it on. The Ubuntu/.run DKMS package ships the nvkms core as a precompiled blob (nv-modeset-kernel.o_binary), so patching it out means building the full open-gpu-kernel-modules tree from source (nvDIFRAllocate() in src/nvidia-modeset/src/nvkms-difr.c stubbed to return NULL), which is my next step if switching to s2idle doesn’t avoid it.
NVIDIA folks: this reproduces across Blackwell, Ada, Ampere and Pascal per this thread and GitHub issues #1205/#1177. Could we get either a fix for the post-S3 DIFR prefetch race or a supported regkey/module param to disable DIFR entirely?