Resume from hibernation always fails when the driver is in the initramfs: `nv_pm_notifier` does not handle `PM_RESTORE_PREPARE`

[professoramx]

Summary

When the NVIDIA modules are loaded from the initramfs (the default on Arch Linux, and
therefore on Arch-derived distributions), resume from hibernation fails 100% of the time
with nv_pmops_freeze returning -EIO, provided NVreg_PreserveVideoMemoryAllocations=1 —
which Arch's own packaging sets by default.

Writing the hibernation image always succeeds. Only the restore fails, and it fails one step
after the image has been read back correctly.

This is distinct from the Blackwell early-KMS hibernation hangs discussed in distribution
trackers: this reproduces on Turing, and it is a logic gap in the PM notifier that is visible
in the source rather than a modesetting problem.

Environment

Driver	nvidia-open-dkms 610.57.04
GPU	Quadro T2000 (Turing, TU117GLM), 0000:01:00.0
Machine	Lenovo ThinkPad P53 (20QN), Optimus laptop
Kernel	7.1.9-arch1-2
Distro	Omarchy (Arch-based)
Display topology	Only connected output is eDP-1 on the Intel iGPU. nvidia-drm logs Cannot find any crtc or sizes.

Relevant module parameters, all distro defaults:

PreserveVideoMemoryAllocations: 1     # /usr/lib/modprobe.d/gsr-nvidia.conf
UseKernelSuspendNotifiers:      1     # /usr/lib/modprobe.d/nvidia-sleep.conf

Modules early-loaded into the initramfs by /etc/mkinitcpio.conf.d/nvidia.conf:

MODULES+=(nvidia nvidia_modeset nvidia_uvm nvidia_drm)

Steps to reproduce

1. Arch-based system, nvidia-open-dkms, NVIDIA modules in the initramfs MODULES array.
2. NVreg_PreserveVideoMemoryAllocations=1 (default if gpu-screen-recorder is installed).
3. A working hibernation setup — valid resume= and resume_offset=.
4. systemctl hibernate.
5. Power the machine back on.

Expected: the session is restored.
Actual: the image is found and read back successfully, then the restore is abandoned and the
machine continues into a fresh boot.

Log

Run /init as init process
nvidia: loading out-of-tree module ...                          <- initramfs
[drm] Initialized nvidia-drm 0.0.0 for 0000:01:00.0 on minor 1
nvidia 0000:01:00.0: [drm] Cannot find any crtc or sizes
PM: Image signature found, resuming
PM: hibernation: Read 5563848 kbytes in 3.28 seconds (1696.29 MB/s)
PM: Image successfully loaded
NVRM: GPU 0000:01:00.0: PreserveVideoMemoryAllocations module parameter is set.
      System Power Management attempted without driver procfs suspend interface. ...
nvidia 0000:01:00.0: PM: pci_pm_freeze(): nv_pmops_freeze [nvidia] returns -5
nvidia 0000:01:00.0: PM: failed to quiesce async: error -5
PM: hibernation: Failed to load image, recovering.
PM: hibernation: resume failed (-5)

Note that the image was read back at 1.7 GB/s with a valid signature — the hibernation setup
itself is entirely correct. The failure is strictly after Image successfully loaded.

Analysis

Restoring a hibernation image is a two-kernel operation. The freshly booted resume kernel
loads the image, then must quiesce its own devices —
hibernation_restore() → dpm_suspend_start(PMSG_QUIESCE) → each driver's .freeze —
before jumping into the restored image. Because the driver is in the initramfs, that resume
kernel has a live, initialised NVIDIA device to freeze.

kernel-open/nvidia/nv.c — nv_pmops_freeze() calls
nvidia_suspend(dev, NV_PM_ACTION_HIBERNATE, is_procfs_suspend=NV_FALSE), and
nvidia_suspend() contains:

if (nv->preserve_vidmem_allocations &&
    nv_dev_needs_vidmem_preservation(nv) &&
    !is_procfs_suspend)
{
    ...
    status = NV_ERR_NOT_SUPPORTED;
    goto done;
}

All three conditions hold on the resume path:

• preserve_vidmem_allocations — set, via NVreg_PreserveVideoMemoryAllocations=1.
• nv_dev_needs_vidmem_preservation() (common/inc/nv.h) returns
  !is_tegra_pci_igpu && !NV_IS_SOC_DISPLAY_DEVICE, true for a discrete PCI GPU.
• is_procfs_suspend is NV_FALSE, because this is the kernel PM callback.

NV_ERR_NOT_SUPPORTED → nv_pmops_freeze returns -EIO → the restore is abandoned.

Why the save path does not hit this. With NVreg_UseKernelSuspendNotifiers=1 the driver
registers nv_pm_notifier. On the way down the kernel fires PM_HIBERNATION_PREPARE, the
notifier runs nv_suspend_devices(), which calls nvidia_suspend(..., is_procfs_suspend=NV_TRUE)
— the permitted path — saves video memory and sets NV_FLAG_SUSPENDED. The subsequent
nv_pmops_freeze then short-circuits on that flag and returns success.

The gap. On the way back up, software_resume() fires PM_RESTORE_PREPARE, and
nv_pm_notifier's switch handles only:

case PM_SUSPEND_PREPARE:
case PM_HIBERNATION_PREPARE:
case PM_POST_SUSPEND:
case PM_POST_HIBERNATION:
default:  return NOTIFY_DONE;      /* PM_RESTORE_PREPARE lands here */

PM_RESTORE_PREPARE falls through to default. Nothing pre-authorises the freeze,
NV_FLAG_SUSPENDED is clear, and the refusal above fires unconditionally.

This is deterministic, not intermittent.

Suggested fix

Handle PM_RESTORE_PREPARE in nv_pm_notifier alongside PM_HIBERNATION_PREPARE, so the
resume kernel's devices are quiesced through the same permitted path the suspend side uses.

Workaround

Keep the NVIDIA modules out of the initramfs, so the resume kernel has no NVIDIA device bound
and there is no .freeze callback to refuse:

# /etc/mkinitcpio.conf.d/zz-nvidia-no-early-load.conf   (must sort last)
_mods=()
for _m in "${MODULES[@]}"; do
  case $_m in nvidia|nvidia_modeset|nvidia_uvm|nvidia_drm) ;; *) _mods+=("$_m") ;; esac
done
MODULES=("${_mods[@]}")
unset _mods _m

Then rebuild the initramfs. On this machine that restored hibernation completely: entry at
11:06:39, resume at 11:07:53, no PM errors, same boot ID — a genuine restore rather than a
fresh boot.

This costs nothing on an Optimus laptop whose only connected display is on the iGPU. It would
not be acceptable on a system where NVIDIA drives the panel and early KMS is wanted, which is
why it is a workaround rather than a fix.

Impact

Any configuration that early-loads the NVIDIA modules with
NVreg_PreserveVideoMemoryAllocations=1 cannot resume from hibernation. On Arch that is the
default pairing: nvidia.conf puts the modules in the initramfs, and gsr-nvidia.conf
(shipped with gpu-screen-recorder) sets the flag.

[tzalkind]

Driver: nvidia-open-dkms 610.57.04 (open modules), Ada.
Related: forum thread "PreserveVideoMemoryAllocations + systemd services causes resume from hibernate to fail" (forums.developer.nvidia.com/t/233643), omarchy #5554, open-gpu-kernel-modules #1080.

Summary

When the nvidia driver is loaded inside the initramfs (early KMS), resuming from a hibernate image fails at the driver freeze step with -5, the session is lost, and the system falls back to a fresh boot. When the same driver loads after switch_root (no early KMS), resume completes cleanly. This is reproducible and the fix is local and verified.

Failure mode with early KMS

Image writes fine. On the restore boot the initramfs resume hook loads the image, then:

NVRM: GPU 0000:01:00.0: PreserveVideoMemoryAllocations module parameter is set.
      System Power Management attempted without driver procfs suspend interface.
nvidia 0000:01:00.0: PM: pci_pm_freeze(): nv_pmops_freeze [nvidia] returns -5
PM: hibernation: resume failed (-5)
PM: hibernation: Failed to load image, recovering

Fresh boot follows, session gone.
With PreserveVideoMemoryAllocations=0 instead of the -5, the image restores and then the GPU dies ~20-55 s later with a Xid cascade (Xid 13 against the compositor, Xid 31 MMU fault charged to post-resume modprobe, uvm global fatal 0x60, "OS Reboot"). Same early-KMS condition. Matches the open upstream reports on Blackwell; confirmed on Ada (RTX 4070 SUPER) here.

Root cause hypothesis (from 610.57.04 source)

nv_pm_notifier() (nv.c) registers for PM_SUSPEND_PREPARE, PM_HIBERNATION_PREPARE, PM_POST_SUSPEND, PM_POST_HIBERNATION and falls through to NOTIFY_DONE for PM_RESTORE_PREPARE / PM_POST_RESTORE, the two events the kernel fires on the restore path. The write side passes is_procfs_suspend = NV_TRUE and works; the restore side reaches .freeze -> nv_pmops_freeze -> nvidia_suspend(..., NV_FALSE) on a freshly loaded driver with NV_FLAG_SUSPENDED clear, which trips a guard and returns -EIO (surfacing as -5).
The initramfs load is the deciding factor: on a restore boot the driver is loaded before systemd runs, so the procfs/notifier suspend handshake cannot happen before .freeze is called. Without early KMS, the driver loads post-switch_root and the resume path completes.

Fix (verified on this box)

Remove nvidia from the initramfs. No early KMS.

sudo mv /etc/mkinitcpio.conf.d/nvidia.conf ~/nvidia.conf.bak
sudo limine-mkinitcpio

Result: the console during the initramfs is drawn by simpledrm on the firmware framebuffer (the LUKS prompt still renders), nvidia loads after switch_root, and hibernate restore completes cleanly with no -5 and no Xid cascade. Verified across multiple restore cycles, including after real power-off (S5) restores and platform-mode cycles.
Note: this contradicts the Blackwell finding recorded in omarchy #5554 (Test 3: removing early KMS gave a black screen on a 5090). On this Ada system with a monitor attached to the dGPU and simpledrm available, removing early KMS is the fix, not a regression.

Ask

1. Is the missing PM_RESTORE_PREPARE / PM_POST_RESTORE handling in nv_pm_notifier() intentional?
2. Should a driver loaded in the initramfs be able to resume from hibernate at all? The Arch wiki and omarchy guidance say early KMS and hibernate are incompatible; if that is a hard limitation, it would be useful documented explicitly per driver branch.
   Happy to attach nvidia-bug-report.sh output or test a candidate fix.