NVIDIA Open GPU Kernel Modules Version
610.43.03
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.
Cannot test — proprietary driver does not support RTX 5070 (Blackwell). The open kernel module is mandatory.
Operating System and Version
Fedora 44
Kernel Release
7.1.5-201.fc44.x86_64 (also building 7.1.7 to test)
Please confirm you are running a stable release kernel (e.g. not a -rc). We do not accept bug reports for unreleased kernels.
Confirmed — running Fedora 44 stable kernel 7.1.5-201.
Hardware: GPU
NVIDIA GeForce RTX 5070 (GB205, Blackwell, desktop)
Describe the bug
Summary: After S3 deep suspend/resume, the nvidia_modeset PM lock becomes permanently held, causing any subsequent DRM atomic commit (page flip, wallpaper change, window open) to deadlock the entire compositor and freeze the system. The freeze is intermittent — it does not occur on every resume. In the latest occurrence, the system survived 8 consecutive suspend/resume cycles over 2+ days before deadlocking on the 9th.
Key difference from #1117: This is S3 deep (not s2idle), on a desktop (not laptop), with nvidia-suspend.service running successfully — VRAM is saved and restored. The GSP firmware still enters a degraded state that eventually deadlocks on a DRM commit.
Likely related: NVIDIA Forum: post-resume DIFR prefetch deadlock on RTX 5070 Ti — same symptom, same GPU generation, poster identified DIFR (Display Idle Frame Refresh) as the culprit path where GSP fires a prefetch event into stale pushbuffer state post-resume.
System Details
| Component |
Value |
| GPU |
RTX 5070 (GB205, Blackwell, PCI 01:00.0) |
| Driver |
610.43.03 (Open Kernel Module, RPMFusion akmod) |
| Motherboard |
Gigabyte B650 AORUS ELITE AX V2, BIOS F36 |
| CPU |
AMD Ryzen 7000 (Raphael, AM5) |
| iGPU |
AMD Raphael (renderD128) |
| OS |
Fedora 44, GNOME 50.3 / Mutter 50.3, Wayland |
| Kernel |
7.1.5-201.fc44.x86_64 |
| Sleep mode |
S3 deep (mem_sleep_default=deep) |
| S0ix |
NOT supported on this platform (desktop AM5) |
Power Management Configuration
# /etc/modprobe.d/nvidia-power-management.conf
options nvidia NVreg_PreserveVideoMemoryAllocations=1
options nvidia NVreg_TemporaryFilePath=/var/lib/nvidia
options nvidia NVreg_UseKernelSuspendNotifiers=0
Kernel cmdline: mem_sleep_default=deep nvidia.NVreg_UseKernelSuspendNotifiers=0
SELinux policy module installed to allow systemd_sleep_t writes to /var/lib/nvidia (var_lib_t).
Deadlock Trace (SysRq+W, Aug 9 2026 16:53:54 CST)
task:KMS thread state:D stack:0 pid:3401 tgid:3379 ppid:3077
Call Trace:
<TASK>
__schedule+0x2c2/0x710
schedule+0x27/0xa0
schedule_timeout+0xdc/0x120
___down_common+0xd2/0x1f0
__down+0x26/0xe0
down+0x47/0x60
nvkms_ioctl_from_kapi_try_pmlock+0x4a/0xa0 [nvidia_modeset] ← STUCK HERE
ApplyModeSetConfig+0x60a/0xc70 [nvidia_modeset]
nv_drm_atomic_apply_modeset_config+0x57d/0x640 [nvidia_drm]
nv_drm_plane_atomic_check+0x42d/0x590 [nvidia_drm]
drm_atomic_check_only+0x197/0x400
drm_atomic_nonblocking_commit+0x17/0x70
drm_mode_atomic_ioctl+0x571/0x8b0
drm_ioctl_kernel+0xae/0x100
drm_ioctl+0x2d9/0x560
__x64_sys_ioctl+0xb9/0x100
do_syscall_64+0xe2/0x560
entry_SYSCALL_64_after_hwframe+0x76/0x7e
</TASK>
The Mutter KMS thread (pid 3401) tries to do a DRM atomic commit → enters nvidia_drm → calls nvkms_ioctl_from_kapi_try_pmlock → blocks forever on a semaphore that is never released. This is the nvidia_modeset PM lock that should have been released during resume, but the GSP firmware left it in a held state.
Suspend/Resume History (single boot, Aug 7–9)
The system completed 8 successful S3 deep cycles over 2+ days before deadlocking:
| # |
Suspend |
Resume |
nvidia-suspend |
nvidia-resume |
Result |
| 1 |
Aug 07 20:04 |
Aug 07 21:10 |
✅ Ran |
✅ Ran |
OK |
| 2 |
Aug 07 22:56 |
Aug 08 07:42 |
✅ Ran |
✅ Ran |
OK |
| 3 |
Aug 08 10:32 |
Aug 08 14:55 |
✅ Ran |
✅ Ran |
OK |
| 4 |
Aug 08 17:27 |
Aug 08 19:04 |
✅ Ran |
✅ Ran |
OK |
| 5 |
Aug 08 22:24 |
Aug 09 08:08 |
✅ Ran |
✅ Ran |
OK |
| 6 |
Aug 09 10:42 |
Aug 09 12:54 |
✅ Ran |
✅ Ran |
OK |
| 7 |
Aug 09 13:35 |
Aug 09 14:22 |
✅ Ran |
✅ Ran |
OK → FROZE 2h31m later |
- No SELinux denials (
ausearch -m avc clean)
- No additional suspend between last resume and freeze
- Chrome was active at the time (negative frame latency errors just before freeze, indicating GPU becoming unresponsive)
What was already eliminated
- nvidia-suspend skipping — Fixed by
NVreg_UseKernelSuspendNotifiers=0. Services run every time now.
- SELinux blocking VRAM writes — Fixed by custom policy module + moved to
/var/lib/nvidia.
- s2idle — Platform doesn't support S0ix. GPU stays in D0, fans spin. Not viable.
- VRAM not being saved — Services report success, consume 1-2s CPU, ~1-2GB peak memory (VRAM being written).
Crash History (this system)
| Date |
Trigger |
Post-resume? |
Time after resume |
nvidia-suspend |
| Jul 30 |
mpv pause + wallpaper |
Unknown |
Unknown |
Unknown (old config) |
| Aug 01 |
YouTube + wallpaper cron |
Yes |
~27 min |
SKIPPED |
| Aug 05 |
4chan image in Chrome |
Yes |
<1 min |
SKIPPED |
| Aug 07 |
s2idle testing (multiple) |
Yes |
Various |
RAN (but s2idle) |
| Aug 09 |
Normal use (Chrome) |
Yes |
~2h 31min |
RAN (S3 deep) |
The fix applied on Aug 7 (VRAM path + S3 deep + services enabled) made it much more reliable — survived 2+ days and 8 cycles — but did not eliminate the underlying GSP firmware state corruption.
To Reproduce
- Desktop with RTX 5070 (GB205 Blackwell) as primary display GPU, Wayland session (GNOME/Mutter)
- Configure S3 deep sleep with
nvidia-suspend.service / nvidia-resume.service
- Use the system normally with suspend/resume cycles
- Eventually (probabilistically, after N cycles) the nvidia_modeset PM lock becomes stuck after resume
- The next DRM atomic commit (page flip, wallpaper change, etc.) deadlocks the compositor
Expected behavior
The nvidia_modeset PM lock should always be released after resume, regardless of how many suspend/resume cycles have occurred.
Possible root cause
Based on the NVIDIA Forum analysis, this appears to be the DIFR (Display Idle Frame Refresh) prefetch path where GSP fires a post-resume event into stale pushbuffer state. The variable delay (sometimes <1min, sometimes hours) matches DIFR's idle-triggered engagement — it fires when the display first goes idle after resume.
Bug Incidence
Intermittent — approximately 1 in 5-10 resume cycles on S3 deep (with proper VRAM save). Was nearly every resume when nvidia-suspend was being skipped (VRAM not saved).
nvidia-bug-report.log.gz
Attached.
NVIDIA Open GPU Kernel Modules Version
610.43.03
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.
Cannot test — proprietary driver does not support RTX 5070 (Blackwell). The open kernel module is mandatory.
Operating System and Version
Fedora 44
Kernel Release
7.1.5-201.fc44.x86_64 (also building 7.1.7 to test)
Please confirm you are running a stable release kernel (e.g. not a -rc). We do not accept bug reports for unreleased kernels.
Confirmed — running Fedora 44 stable kernel 7.1.5-201.
Hardware: GPU
NVIDIA GeForce RTX 5070 (GB205, Blackwell, desktop)
Describe the bug
Summary: After S3 deep suspend/resume, the
nvidia_modesetPM lock becomes permanently held, causing any subsequent DRM atomic commit (page flip, wallpaper change, window open) to deadlock the entire compositor and freeze the system. The freeze is intermittent — it does not occur on every resume. In the latest occurrence, the system survived 8 consecutive suspend/resume cycles over 2+ days before deadlocking on the 9th.Key difference from #1117: This is S3 deep (not s2idle), on a desktop (not laptop), with
nvidia-suspend.servicerunning successfully — VRAM is saved and restored. The GSP firmware still enters a degraded state that eventually deadlocks on a DRM commit.Likely related: NVIDIA Forum: post-resume DIFR prefetch deadlock on RTX 5070 Ti — same symptom, same GPU generation, poster identified DIFR (Display Idle Frame Refresh) as the culprit path where GSP fires a prefetch event into stale pushbuffer state post-resume.
System Details
mem_sleep_default=deep)Power Management Configuration
Kernel cmdline:
mem_sleep_default=deep nvidia.NVreg_UseKernelSuspendNotifiers=0SELinux policy module installed to allow
systemd_sleep_twrites to/var/lib/nvidia(var_lib_t).Deadlock Trace (SysRq+W, Aug 9 2026 16:53:54 CST)
The Mutter KMS thread (pid 3401) tries to do a DRM atomic commit → enters
nvidia_drm→ callsnvkms_ioctl_from_kapi_try_pmlock→ blocks forever on a semaphore that is never released. This is thenvidia_modesetPM lock that should have been released during resume, but the GSP firmware left it in a held state.Suspend/Resume History (single boot, Aug 7–9)
The system completed 8 successful S3 deep cycles over 2+ days before deadlocking:
ausearch -m avcclean)What was already eliminated
NVreg_UseKernelSuspendNotifiers=0. Services run every time now./var/lib/nvidia.Crash History (this system)
The fix applied on Aug 7 (VRAM path + S3 deep + services enabled) made it much more reliable — survived 2+ days and 8 cycles — but did not eliminate the underlying GSP firmware state corruption.
To Reproduce
nvidia-suspend.service/nvidia-resume.serviceExpected behavior
The nvidia_modeset PM lock should always be released after resume, regardless of how many suspend/resume cycles have occurred.
Possible root cause
Based on the NVIDIA Forum analysis, this appears to be the DIFR (Display Idle Frame Refresh) prefetch path where GSP fires a post-resume event into stale pushbuffer state. The variable delay (sometimes <1min, sometimes hours) matches DIFR's idle-triggered engagement — it fires when the display first goes idle after resume.
Bug Incidence
Intermittent — approximately 1 in 5-10 resume cycles on S3 deep (with proper VRAM save). Was nearly every resume when nvidia-suspend was being skipped (VRAM not saved).
nvidia-bug-report.log.gz
Attached.