Hibernation does not work on Dell XPS 9530

English Install/Boot/Login
21 
Aug 23 17:19:00 localhost kernel: PM: Image loading progress:  30%
Aug 23 17:19:00 localhost kernel: PM: Image loading progress:  40%
Aug 23 17:19:00 localhost kernel: PM: Image loading progress:  50%
Aug 23 17:19:00 localhost kernel: PM: Image loading progress:  60%
Aug 23 17:19:00 localhost kernel: PM: Image loading progress:  70%
Aug 23 17:19:00 localhost kernel: PM: Image loading progress:  80%
Aug 23 17:19:00 localhost kernel: PM: Image loading progress:  90%
Aug 23 17:19:00 localhost kernel: PM: Image loading progress: 100%
Aug 23 17:19:00 localhost kernel: PM: Image loading done
Aug 23 17:19:00 localhost kernel: PM: hibernation: Read 8915412 kbytes in 9.21 seconds (968.01 MB/s)
Aug 23 17:19:00 localhost kernel: PM: Image successfully loaded
Aug 23 17:19:00 localhost kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Aug 23 17:19:00 localhost kernel: NVRM: GPU 0000:01:00.0: PreserveVideoMemoryAllocations module parameter is set. System Power Management attempted without driver procfs suspend interface. Please refer to the 'Configuring Power Management Support' section in the driver README.
Aug 23 17:19:00 localhost kernel: nvidia 0000:01:00.0: PM: pci_pm_freeze(): nv_pmops_freeze [nvidia] returns -5
Aug 23 17:19:00 localhost kernel: nvidia 0000:01:00.0: PM: dpm_run_callback(): pci_pm_freeze returns -5
Aug 23 17:19:00 localhost kernel: nvidia 0000:01:00.0: PM: failed to quiesce async: error -5
Aug 23 17:19:00 localhost kernel: i915 0000:00:02.0: [drm] GT0: GuC firmware i915/adlp_guc_70.bin version 70.29.2
Aug 23 17:19:00 localhost kernel: i915 0000:00:02.0: [drm] GT0: HuC firmware i915/tgl_huc.bin version 7.9.3
Aug 23 17:19:00 localhost kernel: i915 0000:00:02.0: [drm] GT0: HuC: authenticated for all workloads
Aug 23 17:19:00 localhost kernel: i915 0000:00:02.0: [drm] GT0: GUC: submission enabled
Aug 23 17:19:00 localhost kernel: i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled
Aug 23 17:19:00 localhost kernel: i915 0000:00:02.0: [drm] GT0: GUC: RC enabled
Aug 23 17:19:00 localhost kernel: pcieport 10000:e0:06.0: can't derive routing for PCI INT A
Aug 23 17:19:00 localhost kernel: nvme 10000:e1:00.0: PCI INT A: no GSI
Aug 23 17:19:00 localhost kernel: pcieport 10000:e0:06.2: can't derive routing for PCI INT A
Aug 23 17:19:00 localhost kernel: nvme 10000:e2:00.0: PCI INT A: no GSI
Aug 23 17:19:00 localhost kernel: nvme nvme0: D3 entry latency set to 10 seconds
Aug 23 17:19:00 localhost kernel: nvme nvme1: D3 entry latency set to 10 seconds
Aug 23 17:19:00 localhost kernel: nvme nvme1: 16/0/0 default/read/poll queues
Aug 23 17:19:00 localhost kernel: nvme nvme0: 16/0/0 default/read/poll queues
Aug 23 17:19:00 localhost kernel: PM: hibernation: Failed to load image, recovering.
Aug 23 17:19:00 localhost kernel: PM: hibernation: Basic memory bitmaps freed
Aug 23 17:19:00 localhost kernel: OOM killer enabled.
Aug 23 17:19:00 localhost kernel: Restarting tasks ... done.
Aug 23 17:19:00 localhost kernel: PM: hibernation: resume failed (-5)

Looks like the hibernation image is being saved/read just fine but the Nvidia GPU/driver is not cooperating with resume.
For further debugging:
https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt

Off the top of my head, I would say you could try with the open source nouveau driver to see if that helps. If it does, try hibernate/resume with it and switch to the proprietary driver prior to display server start.

22

FWIW, here’s an archlinux thread describing the same NVIDIA+hibernation issue. The OP of that thread mentioned…

It appears that having early KMS (which requires the nvidia module to be in the initramfs) has a bad interaction with PreserveVideoMemoryAllocationsbeing enabled.

Another user mentioned…

I had the same problem, and you were right about the cause (early KMS). I stopped the early loading, and only used kernal parameter nvidia_drm.modeset=1. It can hibernate fine now.

Another similar NVIDIA discussion…

1 Like
23

I’m confused, honestly.

Can someone spoon-feed me the best approach?

24

I don’t own NVIDIA hardware so can only provide limited advice. I suppose not many use hibernate these days? Anyway, is the systemd nvidia-hibernate.serrvice enabled?
systemctl list-unit-files --type=service | grep nvidia
Also discussed here.

25

wiking@localhost:~> systemctl list-unit-files --type=service | grep nvidia
nvidia-hibernate.service enabled disabled
nvidia-persistenced.service disabled disabled
nvidia-powerd.service enabled disabled
nvidia-resume.service enabled disabled
nvidia-suspend.service enabled disabled

26

That checks out as expected.

27

Could my problem have resulted from disabling bbswitch and replacing it with switcherooctl? Is it possible this is why I cannot hibernate?

28

@wiking For Intel/Nvidia one should use fbdev=1 nosimplefb=1 to use the Intel iGPU as primary and Nvidia dGPU as Offload with switcherooctl.

Likely the BIOS power options regarding s0ix with the Intel GPU rather than Nvidia

29

I added these kernel parameters in YAST and tried rebooting and hibernating and I still cannot recover from hibernation. The errors on the screen look basically the same as before.

30

@wiking Did you investigate the BIOS and system power settings to ensure they match up?

31

My concern with this approach is due to reading complaints that Nouveau drains the battery quicker on this model laptop (Dell XPS 9530) vs. the Nvidia drivers.

32

You could unload the nouveau driver prior to the display server starts and load the proprietary driver.

The flow would be like this:

  1. On shutdown, stop display server
  2. Unload proprietary driver
  3. Load nouveau driver
  4. Hibernate. No worries about battery drainage as you’re hibernating. Possibly an issue when suspending to RAM, don’t know :person_shrugging:
  5. On resume, nouveau loads as usual
  6. Prior to starting display server, unload nouveau and load the proprietary driver
33

Is there a way to automate this process so that I can just hibernate as normal, or would I need to do all of these steps manually every time I want to hibernate?

Also, my sleep does not work correctly either, and my battery drains on sleep so I try to set up my power options to hibernate after so many minutes of sleeping. But if hibernate doesn’t work then I lose my work.

34

Ok what settings should I look for in BIOS and how should I set them? Please be as explicit as possible.

Thank you.

35

@wiking have a read of this thread https://forums.opensuse.org/t/extra-battery-drain-in-sleep-mode/176323 @jbouter may be able to offer some help as they have the same system…

36

Which BIOS settings are you talking about in your other post? I looked in BIOS and I don’t see which settings are relevant.

37

Probably called Power Settings. I don’t have a similar device but perhaps mentioning S0xi setup?

38

I reinstalled OpenSUSE TW-Slowroll this time I made sure to create a swap partition resized to my RAM size using guided setup.

At this point I have not installed any NVIDIA drivers and so OpenSUSE is just using the Intel graphics on the laptop.

If I choose “Hibernate,” now the laptop does hibernate and shut off but it wakes up from hibernation after a few seconds and shows the login screen. All of the items on the desktop are restored properly, though.

I am leaving the laptop screen lid open while doing this. Do I need to close the lid or something?

Any ideas of what is happening here?

39

Check if you can solve with this: PC immediately wakes up after suspend to RAM / Newbie Corner / Arch Linux Forums

40

Any idea of what these correspond to? PBTN and LID0 are obvious but the others I’m not sure about.

PEG1
XHCI
RP04
TXHC
TDM0
TRP0
TRP1
AWAC
LID0
PBTN

I disabled all of these as in 1.1 from here https://wiki.archlinux.org/title/Power_management/Wakeup_triggers#Instantaneous_wakeups_from_suspend using the echo command outputting to /proc/acpi/wakeup.

Disabling all of these at once definitely prevents the wakeup but then I cannot resume at all. Pressing the power button with all of these disabled actually results in a reboot of the system.

Disabling these one at a time is a huge pain in the butt because I need to reboot to see any changes. So having an idea of what I am disabling would help.