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)

[Coulomb-f]

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:

• Resume from suspend fails: Xid 119 (GSP RPC timeout) -> oops in nvEvoDisableVblankSemControl -> Xid 154, hard reset required #1271 (oops in nvEvoDisableVblankSemControl, Xid 154)
• [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) #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.

[Coulomb-f]

Quick summary for triagers

GPU	RTX 5090 (GB202), VBIOS 98.02.2E.00.B1
Driver	open 610.57.04 (UseKernelSuspendNotifiers=1, VRAM preserve on)
OS	Fedora 44, kernel 7.1.6-201.fc44
Repro	100% on both deep and s2idle

First failure (~1s after suspend entry):
Xid 120 GSP load-access page fault during UNLOADING_GUEST_DRIVE → GSP unload 0x62 → Xid 154 PF FLR.

deep path additionally: kernel oops in nvEvoDisableVblankSemControl via nvKmsResume / nv_pm_notifier while systemd-sleep runs (exited with irqs disabled), then GPU is probably locked until hard reset.

Evidence gist (filtered logs + hooks): https://gist.github.com/Coulomb-f/d4800aa80f6652eb648aa8cf5899899c

Related: #1271 #1142

[robertvandervoort]

Related data point on RTX 5090 / GB202, but a different suspend path than this Xid 120 / UseKernelSuspendNotifiers=1 crash.

On 595.84-open + Ubuntu 24.04 + GNOME Wayland + UseKernelSuspendNotifiers=0 (stock nvidia-suspend.service / nvidia-sleep.sh), we never reach S3: gnome-shell stays runnable inside nvidia.ko (gvaspaceAlloc_IMPL / dmaAllocMapping_GM107) so freeze fails, then nvidia-sleep.sh deadlocks in nv_procfs_write_suspend. SIGSTOP of gnome-shell before the procfs suspend makes S3 + power-button resume work on the same machine.

Filed separately: #1291

[olealgoritme]

About time to remove GSP and go back to good old RM, can't debug or fix any of these bullshit bugs.

[Lampe2020]

I have the same issue on a Tuxedo Gemini 17, with a 12GB RTX 5070.

[EDIT]: I managed to find a workaround: downgrading the driver

sudo dnf swap -y xorg-x11-drv-nvidia-\* xorg-x11-drv-nvidia-580xx-\* --allowerasing
sudo dracut --force --verbose
sudo grub2-mkconfig -o /etc/grub2-efi.cfg
sudo systemctl enable nvidia-{suspend,resume,hibernate}

Now, suspending or hibernating dumps a whole bunch of text to the screen, but does work.