I have just updated my wife’s laptop to Leap 15 from Leap 42.1, well a new install of everything except /home. Now the old 42.1 install hibernated quite OK however the new Leap 15 install does not always. Usually if she uses it for a while but then closes all the open programs and hits hibernate it stays with the power light on and a black screen although the keyboard will light if you touch it, no matter how long it is left (have done up to 5 minutes) nothing happens and the only option is hold down the power button for 5 seconds to force a power down. When this happens it always boot up as if from cold so obviously no hibernate image. Now if I just boot it up and then immediately hibernate it will do so just fine and power down as it should, it will then resume OK from hibernate.
Now I have checked swap is in use (obviously because sometimes it works) and both fstab and grub have it defined as /dev/sda4. Also swap is 3.7Gb and total memory is 3.5 Gb (some is used of the 4Gb for the video card). I just checked memory in use after doing some things and it was 0.4Gb so not much to copy to swap. However it did not hibernate completely and I had to hold the power button. On rebooting and immediately hibernating it work OK and powered down as it should on power up it resumes OK.
Is there perhaps something in the home directory which could cause this? I have look at the logs but cannot see anything obvious which explains it. If it matters this is a KDE system and has all available fixes applied.
So this is a weird issue and I would appreciate some advice as to what to look for to resolve this.
Stuart
Hi, I currently have 16GB RAM and only 2GB swap and I don’t use suspend to disk of course, but if I just do a little work after boot (say open a text editor and type a few words) the system still hibernates quite happily.
Of course if I open more memory hungry applications and try to hibernate I see what you are seeing, the system stalls and the only option is the power switch.
So I guess that you are just short of swap space, your calculations notwithstanding.
BTW, using Gnome, with more applications running when the system “feels” that too little swap space is available the “Hibernate” option disappears from the “What to do when the power button is pressed” menu.
Sorry, I wrote too soon.
I grew my swap to 16 GB and now too sometimes the system refuses to suspend to disk. Didn’t find a pattern so far, but indeed there may be an issue.
Maybe the following snippet from the journal sheds some light on the likely cause:
nov 19 20:43:04 LT_B systemd[1]: bluetooth.target: Unit not needed anymore. Stopping.
nov 19 20:43:04 LT_B systemd[1]: Stopped target Bluetooth.
nov 19 20:43:04 LT_B systemd[1]: systemd-hibernate.service: Main process exited, code=exited, status=1/FAILURE
nov 19 20:43:04 LT_B systemd[1]: Failed to start Hibernate.
nov 19 20:43:04 LT_B systemd[1]: Dependency failed for Hibernate.
nov 19 20:43:04 LT_B systemd-logind[1539]: Operation 'sleep' finished.
nov 19 20:43:04 LT_B systemd[1]: hibernate.target: Job hibernate.target/start failed with result 'dependency'.
nov 19 20:43:04 LT_B systemd[1]: sleep.target: Unit not needed anymore. Stopping.
nov 19 20:43:04 LT_B systemd[1]: systemd-hibernate.service: Unit entered failed state.
nov 19 20:43:04 LT_B systemd[1]: systemd-hibernate.service: Failed with result 'exit-code'.
nov 19 20:43:04 LT_B systemd[1]: Stopped target Sleep.
It simply says that attempt to hibernate failed, but does not give any reasons.
… and it is even not relevant, being issued after a successful wake from a successful suspend to disk (pressing the power button to wake up the system apparently also triggers a new hibernation that is correctly ignored).
Still trying to find a pattern.
Apparently the first attempt at suspend to disk succeeds, all other fail, some giving a simple screen-lock and no suspend, some leading to kernel panic (Caps-Lock blinking).
Seen something similar also on SLED 12 SP4 GMC on the same HW.
Since it might be HW dependent, I remain standing by and ready to help with testing if I see something relevant.
I am a little puzzled and not sure whether my issue and that of OrsoBruno are actually related since he started by saying he does not use hibernate. What is the difference between hibernate and suspend to disk or are they two terms for the same thing? Certainly nothing so far has helped me diagnose my issue. As I explained the laptop will hibernate OK if done immediately following a boot up and when hibernated OK it resumes OK, just wont hibernate when anything is executed following a boot up (or resume).
I’d really like to get it sorted as it is very likely to annoy my wife whose laptop it is with the issue.
Stuart
Yes, “Hibernate” is the same as suspend to disk (while “suspend to RAM” is AKA as “suspend”).
Maybe I see another thing, so I will not “steal” your thread; apparently my first “Hibernate” works here, irrespective of doing it just after boot or after some work. The second “Hibernate” attempt after boot fails.
Also, swap space is not involved as long as it is enough for the RAM image to be saved (currently testing with 8GB swap, 16 GB RAM).
Apparently here when “Hibernate” fails, “grub.once” is set (to boot the same OS/kernel running at the time of suspend) but the hibernate image on disk is not found or not loadable (check with “journalctl -b |grep image”).
So I think that something is not OK with writing he RAM image to disk, but I have no direct proof at the moment.
Please let me know if / how I can replicate what you are witnessing.
Well so far everything I do anything after booting hibernate fails and I see a black screen and am unable to get it to respond to any keyboard input, only thing which works is power key to force power off. Maybe something is crashing/freezing on hibernate but on reboot I have not found anything in journal. So far every hibernate I’ve tried directly after boot has worked.
Stuart
I’ve just had one more thought. This laptop has dual graphics both Intel on the I3 and Nvidia Geforce GT 620M, on install I got a mesage about not using the Nouveau driver but some Nouveau packages do get loaded. Could this be the problem? We dont need to use th Nvidia stuff as this is only used for web browsing and email etc no intensive graphics at all.
Stuart
Dual graphics with Intel and Nvidia here too. Don’t know if it might be related, but after one successful wake-up from hibernate I saw the following:
nov 20 11:58:34 LT_B kernel: Uhhuh. NMI received for unknown reason 3c on CPU 0.
nov 20 11:58:34 LT_B kernel: Do you have a strange power saving mode enabled?
nov 20 11:58:34 LT_B kernel: Dazed and confused, but trying to continue
nov 20 11:58:46 LT_B kernel: nouveau 0000:01:00.0: DRM: failed to idle channel 0 [DRM]
Proprietary drivers are known to have issues with suspend/hibernate, will try to check if I find something related to nouveau.
I only have the normal drivers installed not the proprietary ones. I do want to see if the Nvidia card is active and powered and if it is I want to permanently disable it. Need to do some research.
Stuart
Have tested with a Desktop system – AMD CPU and Graphics – 2 GB swap – KDE Plasma 5 GUI:
[ol]
[li]“Suspend” from KDE worked fine. [/li][li]“Hibernate” didn’t. [/li][li]From TTY1 and ‘root’ (KDE session running):[/li][LIST=1]
[li]“systemctl hibernate” failed with «Failed to hibernate system via logind. Sleep verb not supported.» [/li][li]“systemctl hybrid-sleep” failed with «Failed to put system into hybrid sleep via logind. Sleep verb not supported.» [/li][/ol]
[li]From the KDE session and a “root” Konsole window, “systemctl hibernate” hibernated the system and, the KDE session recovered … [/li][/LIST]
[HR][/HR]«Something is rotten in the state of Denmark.»
Gnome here, in a superuser terminal issued “systemctl hibernate” twice.
First instance, hibernated and resumed OK.
Second instance locked screen but didn’t hibernate. Journal shows:
Nov 20 19:01:57 LT_B kernel: PM: Preallocating image memory... done (allocated 1193484 pages)
Nov 20 19:01:57 LT_B kernel: PM: Allocated 4773936 kbytes in 0.26 seconds (18361.29 MB/s)
Nov 20 19:01:57 LT_B kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Nov 20 19:01:57 LT_B kernel: Suspending console(s) (use no_console_suspend to debug)
**Nov 20 19:01:57 LT_B kernel: nouveau 0000:01:00.0: DRM: failed to idle channel 0 [DRM]
Nov 20 19:01:57 LT_B kernel: pci_pm_freeze(): nouveau_pmops_freeze+0x0/0x20 [nouveau] returns -16
Nov 20 19:01:57 LT_B kernel: dpm_run_callback(): pci_pm_freeze+0x0/0xd0 returns -16
Nov 20 19:01:57 LT_B kernel: PM: Device 0000:01:00.0 failed to freeze async: error -16
**
again, don’t know if it is really related, but apparently nouveau/Nvidia refuse to go to sleep…
third issue of “systemctl hibernate” resulted in the same errors with no hibernation.
Trying “DRI_PRIME=1 glxspheres” to use nouveau resulted in a frozen system, only option to pull the switch.
Don’t know if nouveau is THE culprit, but it is definitely not in good shape…
Having installed bbswitch it shows as OFF when I run the command cat /proc/acpi/bbswitch.
Stuart
I checked with a plain old Intel laptop which hibernated happily with Leap 42.3, upgraded it to Leap 15 and hibernate seems normal.
So the problem is HW dependent and the evidence is mounting against Nvidia/nouveau.
It seems that after the first hibernation after boot up (always successful here) the dGPU doesn’t wake up properly (I cannot run any DRI_PRIME=1 command after resume from hibernate) and then prevents hibernating again.
I don’t know ATM if switching off the dGPU via bbswitch or other means improves the situation.
hi,
fwiw, observation,
Hibernate works ok if the mouse pointer is not moved during the selection process, this is independent of the uptime of the session
if mouse pointer motion is made then the Logout mode in entered
assumption: either this is just a coincidence or
the mouse input buffer is not inhibited and hence continue is recognised
ymmv
cheers
I have noticed something similar on ny TW desktop but I have two laptops with Leap 15 one hibernates from the KDE desktop just fine but the other which has Intel and Nvidia graphics does not so I don’t believe the mouse is an issue with it although I will test that.
Stuart