Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta Adatta ai principianti
  • Qualcosa non va?
#1,343 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
72/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
c, linux
Ambito
operating-systems

Direzione di ricerca

Inizia in kernel-open/nvidia/nv.c presso nv_pm_notifier e confronta il percorso PM_RESTORE_PREPARE con PM_HIBERNATION_PREPARE. Conferma che il notifier gestisca l’evento di restore attraverso il percorso di suspend consentito, quindi riproduci l’ibernazione con i moduli NVIDIA nell’initramfs e verifica che la sessione ripristinata non fallisca più in nv_pmops_freeze.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
C
Stelle
17.4k
Fork
1.9k
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di NVIDIA/open-gpu-kernel-modules

Tutte le issue di NVIDIA/open-gpu-kernel-modules

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.