Ubuntu 24 fails to resume after hibernation due to NVIDIA issue

Graphics / Linux Linux
,
1

Technical Support Ticket: Regression in Hibernation Power Management (RTX 4060 Ti)

System Environment

  • OS: Ubuntu (using X11 Desktop Session)

  • Kernel: 6.17.0-1020-oem

  • Driver Version: 580.126.09

  • CUDA Version: 13.0

  • GPU: NVIDIA GeForce RTX 4060 Ti (16GB)

  • Storage Setup: 36GB Swap file (/swap.img) on ext4 partition (/dev/nvme0n1p5)

Problem Description

The system successfully initiates hibernation and saves the memory image to disk. However, upon resuming from hibernation, the kernel successfully loads and decompresses the image data from the swap file, but the resume operation aborts at the final stage because the NVIDIA driver fails to freeze/quiesce. This forces a fallback to a fresh cold boot, losing the user’s session.

Direct invocation via the kernel interface (echo disk | sudo tee /sys/power/state) immediately fails with an Input/output error.

Relevant Kernel Logs (dmesg)

Plaintext

[   12.449952] PM: hibernation: Read 5453596 kbytes in 3.20 seconds (1704.24 MB/s)
[   12.450571] PM: Image successfully loaded
[   12.458850] nvidia 0000:05:00.0: PM: pci_pm_freeze(): nv_pmops_freeze [nvidia] returns -5
[   12.459178] nvidia 0000:05:00.0: PM: dpm_run_callback(): pci_pm_freeze returns -5
[   12.459183] nvidia 0000:05:00.0: PM: failed to quiesce async: error -5
[   12.982944] PM: hibernation: Failed to load image, recovering.
[   13.160812] PM: hibernation: Basic memory bitmaps freed
[   13.161318] PM: resume failed (-5)

Troubleshooting Steps Already Taken

To isolate the driver as the single point of failure, the following configurations were applied and verified:

  1. VRAM Preservation Enabled: Verified PreserveVideoMemoryAllocations: 1 is active in /proc/driver/nvidia/params.

  2. Dedicated Temp Paths: Set NVreg_TemporaryFilePath=/var/tmp with ample disk space to prevent memory allocation drops.

  3. Early Module Loading: Added nvidia, nvidia_modeset, nvidia_uvm, and nvidia_drm directly to the initramfs modules to guarantee availability during early boot phases.

  4. Kernel Parameters: Modified GRUB to include exact resume=UUID and resume_offset coordinates. Verified /sys/power/resume successfully points to the root block device device mapping (259:5).

  5. ASPM and Secure Boot Disabled: Confirmed mokutil --sb-state reports Secure Boot is disabled. Motherboard PCIe Active State Power Management (ASPM) has been disabled to prevent bus-level timing drops.

  6. Isolated Environment Isolation: The failure persists with the exact same -5 (EIO) error code even when initiating hibernation cleanly from a virtual terminal console (TTY3) with minimal VRAM utilization (~1.4GB used by basic Xorg/GNOME processes).

Request

Please advise if this nv_pmops_freeze failure (error -5) is a known regression with the 580.x driver branch on 6.17+ OEM Linux kernels, and if there is a specific module parameter configuration required to prevent the asynchronous driver freeze timeout on Ada Lovelace architecture GPUs.

nvidia-bug-report.log.gz (1.2 MB)

2

I have the same exact issue. I am on Bazzite 44 and kernel:

6.19.14-ogc2.1.fc44.x86_64 #1 SMP PREEMPT_DYNAMIC Fri May 8 00:34:25 UTC 2026 x86_64 GNU/Linux

My nvidia driver is:

NVRM version: NVIDIA UNIX Open Kernel Module for x86_64 595.71.05 Release Build (akmods@) Mon May 11 01:22:09 UTC 2026
GCC version: gcc version 16.1.1 20260501 (Red Hat 16.1.1-1) (GCC)

3

I was able to find a workaround with Claude Opus 5 after few hours of trial and error:

Update: still reproduces on 7.0.0-31 / 580.173.02, and a working workaround

Following up with newer versions and a more precise trace. Same GPU (RTX 4060 Ti 16GB, AD106).

Environment

  • Ubuntu 24.04, kernel 7.0.0-31-generic (HWE)
  • Driver 580.173.02 — reproduced identically with both the proprietary and the open kernel modules (nvidia-driver-580 and nvidia-driver-580-open)
  • GNOME on Wayland
  • 36 GB swapfile on ext4, resume_offset verified against filefrag
  • Secure Boot disabled
  • nvidia.NVreg_PreserveVideoMemoryAllocations=1, nvidia_drm.modeset=1
  • nvidia-suspend/hibernate/resume.service all enabled

Worth noting separately: I also had to set mem_sleep_default=deep. The board was defaulting to s2idle, under which suspend hung immediately. That’s an unrelated fix, but anyone reproducing should rule it out first.

Failure mode

Both systemctl suspend and systemctl hibernate fail the same way. The machine never powers down — fans and lights stay on, displays go black. The kernel remains fully alive: Caps Lock toggles the LED, the box answers ping, and Alt+SysRq+B reboots
cleanly. Only the display is gone.

INFO: task nvidia-sleep.sh:13937 blocked for more than 122 seconds.
task:nvidia-sleep.sh state:D stack:0 pid:13937 ppid:1
  os_acquire_rwlock_write+0x31/0x50 [nvidia]
  _nv052718rm+0x10/0x40 [nvidia]
  ? rm_power_management+0x76/0x310 [nvidia]
  ? nv_set_system_power_state+0x2d8/0x490 [nvidia]
  ? nv_procfs_write_suspend+0x108/0x1c0 [nvidia]

INFO: task nvidia-sleep.sh:13937 <writer> blocked on an rw-semaphore
      likely owned by task gnome-shell:2933 <writer>
  ? nvkms_call_rm+0x4e/0x90 [nvidia_modeset]
  ? __nv_drm_gem_nvkms_map+0x85/0x100 [nvidia_drm]
  ? __nv_drm_gem_nvkms_mmap+0x17/0x40 [nvidia_drm]
  ? nv_drm_mmap+0xe0/0x190 [nvidia_drm]
  ? nv_drm_ioctl+0x43/0x3f0 [nvidia_drm]

systemd[1]: systemd-hibernate.service: State 'stop-sigterm' timed out. Killing.
systemd[1]: Killing process 13937 (nvidia-sleep.sh) with signal SIGKILL.

This reads as a lock inversion. nvidia-sleep.sh writes to /proc/driver/nvidia/suspend and blocks acquiring an RM rw-semaphore held by the Wayland compositor, which is itself inside nv_drm_mmap → __nv_drm_gem_nvkms_map. Neither side progresses,
systemd eventually SIGKILLs the sleep hook, and the session is left with no display.

Earlier in the same sequence I also see:

[drm:__nv_drm_gem_nvkms_map [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000500]
    Failed to map NvKmsKapiMemory 0x00000000947cdee5
nvidia-modeset: WARNING: GPU:0: Lost display notification (0:0x00000000); continuing.
nvidia-modeset: ERROR: GPU:0: Error while waiting for GPU progress: 0x0000c77d:0 2:0:536:528

Workaround

Switching to a text VT before sleeping makes the compositor drop DRM master and release the lock. Both suspend and hibernate then complete and resume correctly:

#!/bin/sh
# /usr/local/bin/sleep-safe — symlink as suspend-safe / hibernate-safe
action=${1:-$(basename "$0" -safe)}
GUI_VT=$(fgconsole)
chvt 3
systemctl "$action"
chvt "$GUI_VT"

chvt 3 && systemctl hibernate alone is enough to confirm it. This only covers manually triggered sleep — idle/automatic suspend still goes through the normal path and still deadlocks, so I’ve disabled automatic suspend.

Notes

Switching to the open kernel modules changed nothing, which suggests this isn’t specific to the proprietary implementation. There appear to be closely related reports in the open-gpu-kernel-modules tracker — #1291 (“GNOME Wayland suspend never reaches
S3”, “gnome-shell stays runnable in nvidia.ko, nvidia-sleep.sh deadlocks”, 595.84) and #1284 (610.57.04) — both on GB202. My report is AD106, so this doesn’t look Blackwell-specific.

Happy to collect nvidia-bug-report.sh output or test a patched build if that’s useful.

Two things to adjust before posting. Check whether your original X11 -5 failure still reproduces on the current kernel and driver — if it doesn’t, say so, since that changes the picture. And run nvidia-bug-report.sh and attach it; NVIDIA staff nearly
always ask for it first, and having it up front saves a round trip.

4

The nvidia-sleep.sh script is already supposed to do its own VT switch before it writes to /proc/driver/nvidia/suspend so it’s surprising that doing another one helps. Is it possible that systemd is freezing gnome-shell before starting suspend? That behavior is supposed to be disabled with a drop-in configuration. You can check with systemctl cat systemd-suspend.service. You should see an addon at the end:

# /usr/lib/systemd/system/systemd-hibernate.service.d/nvidia-suspend-nofreeze.conf
# Systemd does not interact well with Xorg during system suspend when a kernel
# driver requests a VT switch because systemd freezes all userspace processes,
# including Xorg, before triggering kernel suspend. This deadlocks with the Xorg
# server, which can't respond to the request to switch VTs because it was frozen
# by systemd.
#
# For now, disable freeze on suspend.
[Service]
Environment = SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false

Also, please test with the newly-released 615.41.09 driver. It enables kernel suspend notifiers by default so it takes a different suspend path that avoids some of these systemd interactions, although disabling SYSTEMD_SLEEP_FREEZE_USER_SESSIONS is still required for now.