[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)

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.

---

Start with nvidia/nv.c at nv_suspend_devices+0x284 and the suspend call path shown in the trace. Reproduce on the listed Lenovo LOQ 15ARP9 hardware with kernel 7.0.4 and inspect the open and proprietary driver logs. Done means suspend completes cleanly or fails gracefully without leaving the system unresponsive.