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.