Hibernation on systems with Nvidia GPUs have proven to have a variety of issues. This issue will be used as sort of a meta issue to keep track of the current state of the situation, as well as gather information on experiments that work for different people and hopefully narrow in on a proper solve for all systems.

As we gather info, please always be sure to share details of your specific system setup inclusive of CPU, GPU, driver, and system type (desktop vs laptop). Nvidia has proven to have a lot of variance so this will not be a one-size-fits-all solution. I suspect we'll have further issues dealing with laptops with iGPUs since it could technically be either GPU at boot. 

#5500 has a good amount of information that ultimately lead to #5519. However in research, and testing, it proved we're still not quite there.

According to [Arch Wiki](https://wiki.archlinux.org/title/NVIDIA/Tips_and_tricks#Preserve_video_memory_after_suspend), the values of the module parameters vary based on the driver set. This means to have a proper solution, we'll need to handle this for devices capable of running 595+ drivers, as well as those pinned to 580xx. 

> Introduced as an "experimental" interface (originally named NVreg_PreserveVideoMemoryAllocations in the 430-590 series drivers), it enables saving all video memory (given enough space on disk or RAM). With 595+ drivers, it has been succeeded by the NVreg_UseKernelSuspendNotifiers=1 [kernel module parameter](https://wiki.archlinux.org/title/Kernel_module_parameter) which needs to be set to save and restore all video memory contents.

The same section of the wiki highlights issues with hibernate used in-tandem with early KMS, which we do use in Omarchy to provide a smooth boot experience.

> When using [early KMS](https://wiki.archlinux.org/title/NVIDIA#DRM_kernel_mode_setting), i.e. when the loading of nvidia module happens in the initramfs, it has no access to NVreg_TemporaryFilePath which stores the previous video memory: early KMS should not be used if hibernation is desired.

## Helpful Hints
Check current params using this command after reboot to ensure you're operating from a known state.
```
cat /proc/driver/nvidia/params | grep -E 'PreserveVideoMemoryAllocations|UseKernelSuspendNotifiers'
```

Always run `limine-update` after modifying module params or mkinicpio confs and restart before trying a hibernation test to ensure you're operating from a good state.

## Test Findings
I'll kick us off with some findings on my main Nvidia machine.

**Device Type:** Desktop
**Motherboard:** ASUS ROG Strix X870-I
**CPU:** AMD Ryzen 9 9950X3D
**GPU:** RTX 5090 (Blackwell GB202)
**Kernel:** Linux 7.0.3
**Driver**: nvidia-open-dkms 595.71.05

### Test 1                                                                                                                                             
                                                                                                                                                        
With the two module params set as below and the default /etc/mkinitcpio.conf.d/nvidia.conf (early KMS) 

```                                                                                                                                                    
PreserveVideoMemoryAllocations: 1                                                                                                                    
UseKernelSuspendNotifiers: 1                                                                                                                         
```

**Result**
System boots as normal as though hibernation never happened. No session restored.

**Logs Show**
Hibernate writes the image and enters S4 successfully. On wake, a fresh boot runs (new journald boot ID), the initramfs resume hook finds the image and reads it back (PM: Image signature found, resuming → PM: Image successfully loaded), and then resume aborts:           
                                                                                                                                                        
 ```                                                                                                                                                    
   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                                                                                                    
 ```

### Test 2
With the two module params set as below (proper for Blackwell) and the default `/etc/mkinicpio.conf.d/nvidia.conf` (early KMS). This is the state the #5519 put us in.

```
PreserveVideoMemoryAllocations: 0
UseKernelSuspendNotifiers: 1
```

**Result**
System hibernates correctly (verified visually: GPU lights off, every fan off). On power-on, LUKS unlocks, then the landed in Hyprland booted to safe mode after some length of time.

**Logs Show**
Kernel hibernation cycle completes end-to-end. Image written, S4 entered (~125s of real sleep, confirmed by ~125s wall-clock advance with zero monotonic-clock advance). On wake, the initramfs resume hook restores the saved kernel context (same boot ID across the cycle), PM: hibernation: hibernation exit fires cleanly. ~55 seconds later, the NVIDIA GPU emits a fatal Xid cascade: 
                                                                                                                                      
```                                                                                                                                                    
NVRM: Xid 31, pid=355, name=modprobe, MMU Fault: ENGINE CE4_PBDMA0 HUBCLIENT_ESC0                                                                    
      Fault is of type FAULT_PDE ACCESS_TYPE_VIRT_READ                                                                                         NVRM: Xid 13: Graphics Exception (against Hyprland)                                                                                                  
NVRM: Xid 154: GPU recovery action changed to Node Reboot Required                                                                                   
NVRM: nvGpuOpsReportFatalError: uvm encountered global fatal error 0x60,                                                                             
      requiring os reboot to recover.                                                                                                                
NVRM: Xid 109: CTX SWITCH TIMEOUT (against Xorg)                                                                                                     
NVRM: GSP-RM is slow / GSP Timeout / Failed to get RM state, timeout
```

Hyprland crashes with SIGABRT in CHyprOpenGLImpl::begin while taking a window snapshot during VT-switch restore. The Xid 31 is charged to pid=modprobe  — the post-resume udev re-bring-up of the GPU. Appears to be an upstream NVIDIA bug specific to Blackwell + open 595. See ublue-os/bazzite#4492 and NVIDIA/open-gpu-kernel-modules#1080 for similar reports. 

### Test 3
With the two module params set as below (proper for Blackwell) and the default `/etc/mkinicpio.conf.d/nvidia.conf` removed (no early KMS).

```
PreserveVideoMemoryAllocations: 0
UseKernelSuspendNotifiers: 1
```

**Result** 
System hibernates same as Test 2. On power-on, LUKS unlocks, then the user gets a pure black screen with no compositor at all — strictly worse than Test 2's crashed-Hyprland state. Hard power-cycle is the only recovery.

**Note**
In this variant, the Plymouth loader appears in the top left of the screen instead of the middle. I suspect it has something to do with not loading the Nvidia modules early so it fails to properly detect the screen in time or re-draw after it does. This could be something that could be fixed on the Plymouth end but would need further exploration there.

**Logs Show** 
Identical kernel-level cycle to Test 2 (image written, S4 entered, resumed cleanly, same Xid 31 → 154 → uvm 0x60 → GSP timeout cascade ~55s after resume). The kernel doesn't care whether nvidia is in initramfs. With nvidia loaded later via udev (post-init, not from initramfs), the display path never reaches a renderable state on resume — Hyprland never gets to a point where it can even partially render.