Exactly the same here. So wait for newer kernels, I guess?
Do you mean just the lts not booting correctly, or the problem with hibernation?
Both.
I just removed lts, I anyway don’t really have a use case for it.
I am not very well educated in forum’s ethics, but we can basically consider this a solution, right?
As long as we both experience the same problem on the same machines, we can only wait for updates to fix it (correct me if I am wrong).
I’d wait a little bit: kernel 6.14.5 just drop and experimenting with it other stuff happened: basically telling the system to go into hibernation, a cursor blinked, the screen went black for a while and then it restarted (failing to load the image). Doing a journalctl -r --grep=nvidia gives me:
mai 07 00:13:42 olivier-82ju kernel: nvidia 0000:01:00.0: PM: failed to quiesce async: error -5
mai 07 00:13:42 olivier-82ju kernel: nvidia 0000:01:00.0: PM: dpm_run_callback(): pci_pm_freeze returns -5
mai 07 00:13:42 olivier-82ju kernel: nvidia 0000:01:00.0: PM: pci_pm_freeze(): nv_pmops_freeze [nvidia] returns -5
The nvidia card might be at fault here. I have a config file in /etc/modprobe.d with the line:
options nvidia "NVreg_PreserveVideoMemoryAllocations=1"
Which has been reported to cause problems with hibernation (although in my case it didn’t). I hope changing it will still allow the card to go into D3Cold when not in use…
Edit: this is with nvidia-open drivers. Maybe the closed source ones would fare better. BTW, changing the above line didn’t improve anything.
Edit 2: It seems I am making some progress: regarding the file above in /etc/modprobe with the line:
options nvidia "NVreg_PreserveVideoMemoryAllocations=1"
Changing that to 0 had no effect because I had a nvidia-sleep.conf file in /usr/lib/modprobe.d/ which had the following content:
# https://download.nvidia.com/XFree86/Linux-x86_64/560.35.03/README/powermanagement.html#PreserveAllVide719f0
# Save and restore all video memory allocations.
options nvidia NVreg_PreserveVideoMemoryAllocations=1
#
# The destination should not be using tmpfs, so we prefer
# /var/tmp instead of /tmp
options nvidia NVreg_TemporaryFilePath=/var/tmp
To enable hibernation, I copied /usr/lib/modprobe.d/nvidia-sleep.conf to /etc/modprobe.d/ and set options nvidia NVreg_PreserveVideoMemoryAllocations=1 to 0. I also commented the lines options nvidia NVreg_PreserveVideoMemoryAllocations=1 and options nvidia NVreg_TemporaryFilePath=/var/tmp in my custom file and regenerated the initrds.
Rebooting, then hibernating led to:
- Still no shutdown
- But resuming from hibernation after a hard shutdown succeeds in loading the hibernation image into the ram
I hibernated twice. Twice the same result.
Sources: From opensuse forum and nvidia forums. Apparently, removing nvidia modules helps as well.
I have upgraded to 6.14.5 kernel today too and the behaviour on my machine stays the same. Basically It acts exactly as you describe
Only in my case this is identical to the behaviour with previous kernel version. I never had problem with the resuming from disk as long as I had waited enough time before hard powering off my laptop with button, which I guessed by my external keyboard backlight going off (I think in that moment the laptop just reached the state of “hibernation-done” → “shutdown-to follow”).
Btw my contents of /usr/lib/modprobe.d/nvidia-sleep.conf are identical to yours.
Hi,
Thanks. Actually, the “improvement” I described in my previous post is reverted. I am at a loss to explain it.
Edit: this seems to be kernel-dependent: it works with the stable kernel but not with the zen one.
There is some body of evidence that nvidia early kms might be at fault here. If that’s the case, maybe omitting kernel-modules-extra when setting up the initramfs helps (kernel-modules-extra) deals with out-of-tree kernel drivers, hence nvidia drivers.
I’ve recently noticed an unexpected behaviour that if I set the laptop to hibernate as soon as the battery reaches certain threshold while charging out, it hibernates and shuts down afterwards without any problem (and resumes fine too). Maybe this could lead to the solution by triggering something like low battery state instead of hibernating the classic way. But it goes against any logic, I think. I don’t know why the shutdown-followed hibernation works in this case and not in the other… I didn’t expect it and discovered it by a coincidence.
Thanks. To be honest, it seems that, on my end, tinkering here or there doesn’t bring much. I’ll use a more systematic approach to document what is wrong with my system has I am unable to have any reproducibility at all: any change I carry out will hibernate and resume for some time and then will stop resuming. The only constant I have is that it never shuts down, which in itself is a problem.
I won’t have time to do that before next week though. In the meantime, I’ll revert the changes I’ve made to start from the top.
Hi one year after, Berneri!
Is there a chance you have solved the issue? I haven’t spent much time on my lenovo during the period, but I tried to solve it by myself several times. Without any success tho. Have you succeeded? Would be very keen to hear so 
Hi, seems to work, kinda. I’ll go over my config later, but the tldr is that if trigger hibernate from my session, it will lock it. Then I have to tell the computer to hibernate again and then it works (shuts down and wakes up from hibernation just fine).
Cheers
Oh awesome to hear and even better to try out myself. I never thought having the laptop shutdown after hibernating it can feel so good. Unfortunatelly it doesn’t resume after hibernation. Underscore blinks and that coldboots. Have you run into this issue too? I am almost sure I have the swap partition and UUID in /proc/cmdline setup right.
Jun 01 08:10:25 misa-82jq systemd-hibernate-resume-generator[189]: Reported hibernation image: ID=endeavouros kernel=6.19.14-arch1-1 UUID=ad0a9421-0bd0-4c59-8f95-48c88bc329fa offset=0
Jun 01 08:10:26 misa-82jq systemd-hibernate-resume[461]: Reported hibernation image: ID=endeavouros kernel=6.19.14-arch1-1 UUID=ad0a9421-0bd0-4c59-8f95-48c88bc329fa offset=0
Jun 01 08:10:35 misa-82jq systemd-hibernate-resume[461]: Unable to resume from device '/dev/disk/by-uuid/ad0a9421-0bd0-4c59-8f95-48c88bc329fa' (8:3) offset 0, continuing boot process.
Jun 01 08:10:35 misa-82jq systemd[1]: systemd-hibernate-resume.service: Deactivated successfully.
Jun 01 08:10:35 misa-82jq systemd[1]: systemd-hibernate-resume.service: Consumed 2.458s CPU time over 9.353s wall clock time, 2M memory peak.
└─sda3 part 20,3G ad0a9421-0bd0-4c59-8f95-48c88bc329fa swap
And btw I used this command, which hibernated successfully:
loginctl lock-session & sleep 5 & systemctl hibernate