[Bug] System suspend fails on RTX 4050 Mobile with GSP unload failed 0x62 → kernel WARNING in nv_suspend_devices, leaving system unresponsive (driver 595.71.05, kernel 7.0.4)

[reugenio]

NVIDIA Open GPU Kernel Modules Version

595.71.05

Operating System and Version

Fedora 44 (kernel 7.0.4-200.fc44.x86_64)

Kernel Release

7.0.4-200.fc44.x86_64

Hardware

• Laptop: Lenovo LOQ 15ARP9 (BIOS PQCN23WW 03/25/2025)
• GPU: NVIDIA GeForce RTX 4050 Max-Q / Mobile (AD107M, PCI ID 10de:28e1, rev a1)
• CPU: AMD Ryzen 7 7435HS (note: this Ryzen variant has no integrated GPU, so the RTX 4050 is the sole display device)
• RAM: 24 GB
• Display setup at time of crash: laptop panel only (external HDMI monitor had been disconnected ~7s before the lid was closed)

Driver Source

akmod-nvidia-open-595.71.05-1.fc44.x86_64 from RPM Fusion (rpmfusion-nonfree-updates)

Reproduction Steps

1. Boot system normally; GPU operates fine (verified with nvidia-smi, no errors in journalctl).
2. Use the system for any productive task (in our case: web browsers + a Node.js app + a terminal).
3. Disconnect external HDMI monitor (if connected).
4. Close laptop lid.
5. KDE Plasma's PowerDevil daemon triggers a system suspend via D-Bus (logind.Suspend()), independent of systemd-logind's own HandleLidSwitch=ignore setting if configured.
6. Approximately 1 minute later: kernel emits _threadNodeCheckTimeout followed by a fatal suspend failure (see stack trace below).
7. System becomes unresponsive; fan stays at high RPM with screen off. Opening the lid does not recover the system. A hard reset is required.

Bug Incidence

Reproduces consistently. Two confirmed cuelgues in single day (oficina → casa, casa → oficina) under same conditions. Verified across multiple boots.

Expected behavior

System should suspend cleanly to S3 (or fail gracefully and stay awake), as it did under earlier kernel branches (we don't have exact pre-7.x data but pre-Fedora 44 upgrade the issue did not manifest in the same way).

Observed behavior

GSP firmware fails to unload, leaving the GPU in an invalid state. Subsequent userspace MMU operations trigger ~38 consecutive NV_ERR_INVALID_STATE assertions, after which the system hangs entirely.

Kernel log (relevant excerpt from journalctl boot -1)

May 12 20:29:38 Cello sddm-helper-start-x11user: NVIDIA(GPU-0): DFP-2: disconnected
May 12 20:29:45 Cello systemd-logind[1274]: Lid closed.
May 12 20:29:45 Cello systemd-logind[1274]: The system will suspend now!
May 12 20:30:47 Cello systemd-udevd[915]: card1: Worker [116243] processing SEQNUM=5304 is taking a long time.
May 12 20:30:47 Cello kernel: NVRM: _threadNodeCheckTimeout: _threadNodeCheckTimeout: currentTime: f498b8471eb80 >= f498b8471eb80
May 12 20:30:47 Cello kernel: NVRM: _threadNodeCheckTimeout: _threadNodeCheckTimeout: Timeout was set to: 30000 msecs!
May 12 20:30:48 Cello kernel: NVRM: gpuPowerManagementEnter: GSP unload failed at suspend (bootMode 0x1, newLevel 0x3): 0x62
May 12 20:30:48 Cello kernel: NVRM: Xid (PCI:0000:01:00): 154, GPU recovery action changed from 0x0 (None) to 0x1 (GPU Reset Required)
May 12 20:30:48 Cello kernel: NVRM: RmHandleDNotifierEvent: RmHandleDNotifierEvent: Failed to handle ACPI D-Notifier event, status=0x11
May 12 20:30:48 Cello kernel: WARNING: nvidia/nv.c:4925 at nv_suspend_devices+0x284/0x3b0 [nvidia], CPU#1: systemd-sleep/116225
May 12 20:30:48 Cello kernel: CPU: 1 UID: 0 PID: 116225 Comm: systemd-sleep Tainted: G           OE       7.0.4-200.fc44.x86_64 #1 PREEMPT(lazy)
May 12 20:30:48 Cello kernel: Hardware name: LENOVO 83JC/LNVNB161216, BIOS PQCN23WW 03/25/2025
May 12 20:30:48 Cello kernel: RIP: 0010:nv_suspend_devices+0x284/0x3b0 [nvidia]
May 12 20:30:48 Cello kernel: Call Trace:
May 12 20:30:48 Cello kernel:  <TASK>
May 12 20:30:48 Cello kernel:  nv_set_system_power_state.part.0+0x72/0x1d0 [nvidia]
May 12 20:30:48 Cello kernel:  nv_pm_notifier+0x35/0xa0 [nvidia]
May 12 20:30:48 Cello kernel:  notifier_call_chain+0x70/0x110
May 12 20:30:48 Cello kernel:  blocking_notifier_call_chain_robust+0x73/0xf0
May 12 20:30:48 Cello kernel:  pm_notifier_call_chain_robust+0x1d/0x40
May 12 20:30:48 Cello kernel:  enter_state+0x9e/0x5d0
May 12 20:30:48 Cello kernel:  pm_suspend+0x4a/0xa0
May 12 20:30:48 Cello kernel:  state_store+0x2e/0x60
May 12 20:30:48 Cello kernel:  kernfs_fop_write_iter+0x171/0x220
May 12 20:30:48 Cello kernel:  vfs_write+0x281/0x570
May 12 20:30:48 Cello kernel:  ksys_write+0x7b/0x110
May 12 20:30:48 Cello kernel:  do_syscall_64+0x109/0x6e0
May 12 20:30:50 Cello kernel: NVRM: GPU0 nvAssertOkFailedNoLog: Assertion failed: Generic Error: Invalid state [NV_ERR_INVALID_STATE] (0x00000040) returned from mmuWalkUnmap(userCtx.pGpuState->pWalk, vaLo, vaHi) @ gpu_vaspace.c:2084
[... ~38 repetitions of the above NVRM mmuWalkUnmap assertion ...]
[system unresponsive thereafter; hard reset required]

Workaround

Mask all systemd suspend-related targets so the suspend code path is never invoked:

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

After this, attempts to suspend (whether via lid close, idle timeout, PowerDevil, or manual systemctl suspend) return Call to Suspend failed: Access denied and the system stays awake. This avoids the bug entirely at the cost of losing low-power states (battery drain with the lid closed is approximately equivalent to active use).

Note: configuring HandleLidSwitch=ignore in /etc/systemd/logind.conf.d/ is not sufficient on KDE Plasma, because PowerDevil triggers suspend via D-Bus independently of systemd-logind's lid handling policy.

Comparison with proprietary (non-open) driver on the same kernel

The proprietary akmod-nvidia package (same upstream version 595.71.05) also crashes during suspend on this exact kernel/hardware, but with a different signature:

nvidia-modeset: ERROR: GPU:0: Failed to determine display capabilities
nvidia-modeset: ERROR: GPU:0: Failed to tear down Disp
BUG: unable to handle page fault for address: 00000000000026b0
RIP: nvEvoDisableVblankSemControl+0x34/0xd0 [nvidia_modeset]
systemd-suspend.service: Main process exited, code=killed, status=9/KILL

Swapping from akmod-nvidia to akmod-nvidia-open changes the failure mode (display tear-down failure → GSP unload failure) but does not fix the underlying suspend incompatibility. This suggests the regression is in shared code paths used by both driver flavors during the kernel 7.0.4 suspend sequence on Ada Lovelace mobile GPUs with no fallback iGPU.

Additional context

The user's CPU (Ryzen 7 7435HS) has no integrated GPU, so the NVIDIA discrete card is the sole display device. We mention this because it eliminates the common workaround of disabling the discrete GPU and falling back to integrated graphics — that option isn't available on this hardware. For users in this situation, masking the suspend targets is currently the only viable mitigation we've found.

We are happy to provide any additional logs, run debug builds, or test patches. Thank you for the work you do on the open driver — switching to it was a significant improvement in confidence even before this issue is resolved.

---

[reugenio]

Update: root cause identified and mitigated (not a driver bug)

After 3 days of investigation including the official NVreg workaround from the NVIDIA Developer Forums (NVreg_DynamicPowerManagement=0x01 + NVreg_EnableS0ixPowerManagement=0), which did not resolve the crash on my hardware, I found the real root cause: SELinux on Fedora 44 is blocking the temporary file write that the driver performs during suspend to preserve VRAM.

Confirmation

When suspend is attempted (sudo systemctl suspend), the following SELinux denials appear in the audit log microseconds before the GSP CrashCat report:

AVC denied { write open } comm="systemd-sleep"
  path=/var/tmp/#6419357 (deleted)
  scontext=system_u:system_r:systemd_sleep_t:s0
  tcontext=system_u:object_r:tmp_t:s0
  tclass=file permissive=0

AVC denied { perfmon } comm="systemd-sleep" capability=38
  scontext=system_u:system_r:systemd_sleep_t:s0
  tclass=capability2 permissive=0

The path matches NVreg_TemporaryFilePath=/var/tmp from my kernel cmdline (where the driver preserves VRAM). The denial happens ~2 seconds after PM: suspend entry (s2idle) and triggers the visible cascade:

NVRM: nvAssertFailedNoLog: listCount(&pKernelBus->virtualBar2[gfid].usedMapList) == 0 @ kern_bus_vbar2.c:346
NVRM: Xid (PCI:0000:01:00): 120, GSP task exception: load access page fault @ pc:0x134deee
NVRM: gpuPowerManagementEnter: GSP unload failed at suspend: 0x62
NVRM: Xid (PCI:0000:01:00): 154, GPU Reset Required
WARNING: nvidia/nv.c:4925 at nv_suspend_devices+0x284/0x3b0 [nvidia]

This matches the SELinux/NVIDIA interaction discussed in Fedora selinux-policy PR #3087 (proposed by Aaron Plattner, NVIDIA), which is still open and unmerged.

Working mitigation

Three changes, fully reversible:

# 1) Generate and install a local SELinux policy from real denials
sudo bash -c "journalctl -b -1 | grep 'AVC.*systemd-sleep' | audit2allow -M my-systemdsleep"
sudo semodule -X 300 -i my-systemdsleep.pp

# 2) Mask nvidia-powerd (interferes with GSP unload on some configurations)
sudo systemctl stop nvidia-powerd && sudo systemctl mask nvidia-powerd

# 3) Reload systemd-logind if you previously masked suspend targets / set lid=ignore
sudo systemctl reload systemd-logind

The generated policy adds exactly two rules:

allow systemd_sleep_t self:capability2 perfmon;
allow systemd_sleep_t tmp_t:file { open write };

Validation

After applying the mitigation, I ran three suspend tests on the same hardware (Lenovo LOQ 15ARP9, Ryzen 7 7435HS, RTX 4050 Max-Q, no iGPU):

Test	Trigger	Duration	Result
Manual short	sudo systemctl suspend	1:12 min	PASS, clean PM exit
Manual long	sudo systemctl suspend	21:52 min	PASS, clean PM exit, zero NVIDIA errors
Real lid switch	Lid close (battery, no external monitor)	3:28 min	PASS, suspend triggered automatically, clean wake on lid open

All three: zero Xid 120/154, zero nvAssertFailedNoLog, zero gpuPowerManagementEnter failures, zero nv_suspend_devices WARNINGs, journalctl -p err empty.

Suggestion

If reproducible on other Fedora systems with the same symptoms (Xid 120 + kern_bus_vbar2.c:346 + GSP unload fail 0x62), this looks like a SELinux policy issue affecting systemd_sleep_t, not a driver bug per se. Coordination with the Fedora SELinux policy maintainers around PR #3087 might be the fastest path to a permanent fix for affected users.

Happy to provide additional logs or test patches if helpful.

[aaronp24]

Yes, this does look like the SELinux interaction problem. There's a bit of nuance there though:

• The problem only occurs when the suspend is triggered by systemd-sleep writing to /sys/power/state, which happens when the driver is loaded with NVreg_UseKernelSuspendNotifiers=1. You can avoid the problem by disabling kernel suspend notifiers and using the older NVreg_PreserveVideoMemoryAllocations=1 suspend path.
• We're making improvements to future drivers to fail more gracefully when SELinux denies access to the temporary files (or in other failure cases such as running out of space).
• Future drivers will default to using shmem_file_setup() rather than opening a file in /tmp. That uses the SELinux tmpfs_t context rather than the tmp_t one you see in your AVC log message. That's what Allow fs_write_tmpfs_files for systemd_sleep_t fedora-selinux/selinux-policy#3087 targets, so it won't actually help with current drivers unless you also apply the shmem_file_setup() patch.

[reugenio]

Follow-up: a second issue surfaced once the GSP crash was fixed (and how Wayland resolved it)

@aaronp24, thanks for the clarification on the NVreg_UseKernelSuspendNotifiers=1 / NVreg_PreserveVideoMemoryAllocations=1 distinction, and for the shmem_file_setup() work targeting tmpfs_t rather than tmp_t — very helpful for understanding the long-term fix path.

Posting a follow-up because, after the SELinux mitigation removed the GSP crash, a second issue surfaced on the same hardware. It turned out to be unrelated to the driver itself, but anyone reaching the SELinux fix on Fedora 44 / NVIDIA Open 595 / Plasma X11 may hit it next, so documenting in case it helps.

Symptom 2: input devices unresponsive after long s2idle (lid-close transport scenario)

After the GSP fix, short suspend cycles worked cleanly. But in a real "laptop closed in a backpack" scenario (lid closed for ~3 hours), the system would resume visually fine (display, browsers, network reconnecting), yet internal keyboard (i8042) and trackpad (ELAN i2c-hid) were completely unresponsive. Force-reset was the only recovery.

journalctl showed the kernel freezer aborting at suspend entry:

Freezing user space processes aborted after 0.001 seconds
(761 tasks refusing to freeze, wq_busy=0)
OOM killer enabled
Restarting tasks: Done
PM: suspend exit
PM: suspend entry (s2idle)     ← immediate retry, then silence for hours

The system entered partial s2idle. On long wake, the kernel attempted to reconcile state in one pass and i8042 / i2c-hid ELAN never completed coherent resume. Xorg logged:

[dix] couldn't enable device 13
[dix] couldn't enable device 11
[dix] couldn't enable device 8

Root cause of the freezer abort

NVIDIA ships a systemd drop-in (/usr/lib/systemd/system/systemd-suspend.service.d/nvidia-suspend-nofreeze.conf) that sets SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false to avoid the historical Xorg deadlock during VT switch. With user sessions not frozen, ~761 threads from FUSE (pCloud), conmon/podman (distrobox), kitty, syncthing, etc. stay alive and the kernel freezer aborts in 1 ms because some are in non-interruptible D state.

I tested overriding the drop-in to true — that produced a hard deadlock pre-suspend (Xorg frozen in user.slice while the NVIDIA driver waits on Xorg for a VT-switch response). So the drop-in's comment is still current, not legacy: on X11 + Plasma, it's a genuine bind.

Resolution: Plasma Wayland session + PowerDevil LidAction=1

Switching the session from X11 to Wayland resolved both halves:

• Freezer no longer aborts. With Wayland, freezing completes in 0.002 s versus aborting at 0.001 s on X11. kwin_wayland replacing Xorg, plus the absence of X11-specific daemons, eliminates the non-freezable threads. NVIDIA's FREEZE_USER_SESSIONS=false drop-in becomes irrelevant on Wayland because no Xorg VT switch is needed.
• PowerDevil intercepts lid-switch. Under KDE 6 + Wayland, PowerDevil registers a block inhibitor on handle-lid-switch, so systemd-logind never evaluates lid policy — PowerDevil applies its own. The default LidAction is "Do nothing" (DPMS off only), so closing the lid did not actually trigger suspend.

Fix:

kwriteconfig6 --file powerdevilrc --group "AC"      --group "SuspendAndShutdown" --key "LidAction" 1
kwriteconfig6 --file powerdevilrc --group "Battery" --group "SuspendAndShutdown" --key "LidAction" 1
systemctl --user restart plasma-powerdevil.service   # ← refreshStatus via D-Bus is NOT enough

(LidAction=1 = Sleep. dbus-send refreshStatus refreshes runtime state but does not reload the lid plugin config — a full service restart is required.)

Validation

Real lid-switch test with external monitor connected (most demanding scenario):

Lid closed
systemd-logind: The system will suspend now!         ← PowerDevil triggered via LidAction=1
PM: suspend entry (s2idle)
[1 min 45 sec real s2idle]
Lid opened
Freezing user space processes completed (elapsed 0.002 seconds)   ✓
PM: suspend devices took 0.128 seconds                            ✓
PM: resume devices took 0.149 seconds                             ✓
PM: suspend exit                                                  ✓

Zero errors in journalctl -p err across the suspend window. Inputs alive on resume. Wayland session intact.

Summary of full fix on Fedora 44 + NVIDIA Open 595 + Plasma + Lenovo LOQ 15ARP9

1. SELinux: custom policy my-systemdsleep (priority 300) generated via audit2allow on the AVC denials.
2. Mask nvidia-powerd: avoids interference with GSP unload on some configurations.
3. Session: Plasma Wayland (X11 has the freezer-abort / VT-switch double-bind documented above).
4. PowerDevil: LidAction=1 on AC + Battery, then restart plasma-powerdevil.service.

Posting in case it helps anyone else who reaches the SELinux/GSP fix and then runs into the freezer issue underneath. Happy to provide more logs if useful.