RTX 5090 (GB202): suspend always fails — Xid 120 GSP page fault on UNLOADING_GUEST_DRIVE (deep and s2idle), oops in nvEvoDisableVblankSemControl, hard reset required (610.57.04 open)

NVIDIA Open GPU Kernel Modules Version

610.57.04 (open kernel modules, Dual MIT/GPL)

Package: akmod-nvidia-610.57.04-1.fc44.x86_64 from RPM Fusion (rpmfusion-nonfree-nvidia-driver)

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.

• I confirm that this does not happen with the proprietary driver package.

(Note: RTX 5090 / Blackwell requires the open kernel modules on this platform; proprietary-only is not a viable alternative test here. Happy to retest if NVIDIA provides a specific build.)

Operating System and Version

Fedora Linux 44

Kernel Release

7.1.6-201.fc44.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Aug 4 00:23:39 UTC 2026

Please confirm you are running a stable release kernel (e.g. not a -rc). We do not accept bug reports for unreleased kernels.

• I am running on a stable kernel release.

Hardware: GPU

• NVIDIA GeForce RTX 5090 (GB202)
• GPU UUID: GPU-48fb3f67-0738-e328-511d-0cc393370a19
• PCI: 0000:01:00.0
• VBIOS: 98.02.2E.00.B1
• GPU Firmware (GSP package): 610.57.04
• Board: Zotac (retail RTX 5090), host MB Gigabyte X870E AORUS PRO ICE, BIOS FB1b

Display / session

• GNOME on Wayland (GDM)
• Desktop workstation (not laptop)
• Kernel cmdline includes: nvidia-drm.modeset=1 nvidia.NVreg_PreserveVideoMemoryAllocations=1 nvidia.NVreg_TemporaryFilePath=/var/tmp
• PreserveVideoMemoryAllocations: 1, TemporaryFilePath: /var/tmp
• UseKernelSuspendNotifiers: 1 (so nvidia-suspend.service is correctly skipped; kernel PM notifier path is used)
• nvidia-suspend.service / nvidia-resume.service / nvidia-hibernate.service: enabled

Describe the bug

Every attempt to suspend the system hard-locks the machine. This reproduces for both:

1. PM: suspend entry (deep) (S3)
2. PM: suspend entry (s2idle)

Within ~1 second of suspend entry, GSP crashes during guest driver unload:

NVRM: Xid (PCI:0000:01:00): 120, GSP task exception: load access page fault (cause:0xd) @ pc:0x13636b2
NVRM:     ... UNLOADING_GUEST_DRIVE ... actively_polling
NVRM: gpuPowerManagementEnter: GSP unload failed at suspend (bootMode 0x1, newLevel 0x3): 0x62
NVRM: Xid (PCI:0000:01:00): 154, GPU recovery action changed from 0x0 (None) to 0x1 (PF FLR)

On the deep attempt this is followed by a kernel oops in modeset while systemd-sleep is still in the PM path:

BUG: unable to handle page fault for address: 00000000000025f0
Oops: 0000 [#1] SMP NOPTI
RIP: nvEvoDisableVblankSemControl+0x34/0xd0 [nvidia_modeset]
Call trace (abbrev):
  FreeDeviceReference → nvRevokeDevice → nvResumeDevEvo → nvKmsResume
  → nv_suspend_devices → nv_set_system_power_state → nv_pm_notifier
  → pm_suspend / systemd-sleep
note: systemd-sleep[...] exited with irqs disabled

Afterwards the driver loops:

NVRM: krcWatchdog_IMPL: RC watchdog: GPU is probably locked!

Symptoms: system unresponsive (no SSH), high CPU package temp (~87°C observed), fans/control degraded, physical reset required. Suspend has been unreliable for months and is now 100% reproducible (never recovers).

GSP crash report includes:

NVRM: kgspPrintGspBinBuildId_IMPL: GSP bin buildId: 4f09703c5c7d57baa527d6a189bb6d118bc60e49

To Reproduce

1. Boot Fedora 44 with open NVIDIA 610.57.04 on RTX 5090, normal desktop session.
2. Ensure VRAM preserve is enabled (already on cmdline / params).
3. Suspend:
   • systemctl suspend with mem_sleep = deep, or
   • echo s2idle | tee /sys/power/mem_sleep then systemctl suspend
4. Observe GSP Xid 120 within ~1s of PM: suspend entry (...).
5. System wedges; hard reset required.

Bug Incidence

Always (100% in recent testing; both deep and s2idle).

Related upstream reports

Similar GSP suspend / modeset oops patterns:

• https://github.com/NVIDIA/open-gpu-kernel-modules/issues/1271 (oops in nvEvoDisableVblankSemControl, Xid 154)
• https://github.com/NVIDIA/open-gpu-kernel-modules/issues/1142 (GSP unload failed 0x62 on suspend, Fedora 44)

More Info

Timeline (deep, 2026-08-10):

Time	Event
15:09:15	PM: suspend entry (deep)
15:09:16	Xid 120 GSP page fault during UNLOADING_GUEST_DRIVE
15:10:15	30s timeout; GSP unload failed 0x62; Xid 154 PF FLR
15:10:22	Oops in nvEvoDisableVblankSemControl; IRQs disabled in systemd-sleep
15:10:23+	GPU is probably locked watchdog loop until hard reset

Timeline (s2idle, same day):

Time	Event
15:20:55	PM: suspend entry (s2idle)
15:20:56	Same Xid 120 / GSP CrashCat / UNLOADING_GUEST_DRIVE
15:21:56	GSP unload failed 0x62; Xid 154; partial post-hook then locked GPU

Not a missing nvidia-suspend unit setup: UseKernelSuspendNotifiers: 1 causes nvidia-suspend.service ExecCondition to skip by design; crash is inside kernel PM notifier (nv_pm_notifier → nv_suspend_devices).

Captures: Line-synced dmesg/journal with fdatasync across hard reset (full tarballs attached / linked):

• suspend-debug-20260810-150708-161049.tar.zst (deep)
• suspend-debug-20260810-152022-22969.tar.zst (s2idle)

Each contains dmesg-follow.log, journal-follow.log, sleep-hook.log, heartbeat.log, pre-suspend snapshots.

nvidia-bug-report.log.gz

Will attach nvidia-bug-report.log.gz from a healthy boot (post-reset), plus the two suspend-debug tarballs.

Evidence links

Public gist (issue text + filtered dmesg + sleep hooks):

https://gist.github.com/Coulomb-f/d4800aa80f6652eb648aa8cf5899899c

Full hard-reset-survivable capture tarballs (line-synced dmesg/journal/heartbeat) are on the filing machine at:

• /home/phil/nvidia-suspend-bug/suspend-debug-20260810-150708-161049.tar.zst (deep)
• /home/phil/nvidia-suspend-bug/suspend-debug-20260810-152022-22969.tar.zst (s2idle)

I can attach these (and nvidia-bug-report.log.gz) on request or via the GitHub UI if the tracker allows binary uploads.

Start with the suspend path named in the report: nv_pm_notifier, nv_suspend_devices, nv_set_system_power_state, and nvEvoDisableVblankSemControl. Compare the deep and s2idle logs with related issues 1271 and 1142, then identify where the GSP unload failure leads to the modeset oops. Done means suspend completes or fails safely without the Xid 120 crash, oops, or required hard reset.