Fedora reawakens the hibernation debate [LWN.net]

Fedora reawakens the hibernation debate

Posted Sep 17, 2018 14:38 UTC (Mon) by smurf (subscriber, #17840)
Parent article: Fedora reawakens the hibernation debate

The GNOME developers in question should perhaps explain how systemd is supposed to discover whether hibernation works reliably.

There are enough laptops out there where hibernation works 95% of the time.

to post comments

Fedora reawakens the hibernation debate

Posted Sep 17, 2018 17:03 UTC (Mon) by MarcB (subscriber, #101804) [Link]

Yes, or systems where it works exactly once per power-cycle. Or where it only works when using either the free or the proprietary graphics driver - with the possibility of reversing the roles upon updating both drivers.

I always wondered, whether "works" - "works not" could be used to feed an RNG with some strong entropy.

SSDs + Systemd + "crash safe" applications(*) have now mostly "solved" the problem for me .

(*) IDE and Browser handle it fine. Good enough for me.

Fedora reawakens the hibernation debate

Posted Sep 17, 2018 20:37 UTC (Mon) by ballombe (subscriber, #9523) [Link] (1 responses)

> There are enough laptops out there where hibernation works 95% of the time.

So in your experience, suspend-to-RAM work more reliably than suspend-to-disk ?

Fedora reawakens the hibernation debate

Posted Sep 17, 2018 22:02 UTC (Mon) by ncm (guest, #165) [Link]

Of course. It has been quite some years since suspend-to-RAM has failed, for me. And as long since I last tried to get hibernation to work.

That said, I usually could get hibernation working, with enough effort. I had learned to avoid Nvidia, and the i915 driver was getting pretty OK (meaning it would wake up from suspend-to-RAM as often as from hibernation).

Even when both worked, I never got it to switch reliably from suspended to hibernating when the battery got low. But I don't doubt somebody did.

Fedora reawakens the hibernation debate

Posted Sep 17, 2018 22:47 UTC (Mon) by ebassi (subscriber, #54855) [Link] (6 responses)

how systemd is supposed to discover whether hibernation works reliably

systemd includes a hardware quirks database (hwdb) and a kernel/userspace device matching system (udev), so it's perfectly positioned to know if some hardware supports hibernation reliably or not.

Fedora reawakens the hibernation debate

Posted Sep 17, 2018 23:34 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (3 responses)

Based on the combination of hardware, firmware version and kernel version?

Fedora reawakens the hibernation debate

Posted Sep 18, 2018 10:25 UTC (Tue) by ebassi (subscriber, #54855) [Link] (2 responses)

I mean: if the kernel wants to detect that, since it has access to all those three items, then it's also fine by me.

It's unlikely that GNOME, or any other high level user space UI, would be able to access those three things without building a huge quirks database anyway, so might as well defer to components that already have that database.

Fedora reawakens the hibernation debate

Posted Sep 18, 2018 16:12 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

No component has the necessary information to determine that hibernation will work reliably.

Fedora reawakens the hibernation debate

Posted Sep 18, 2018 20:27 UTC (Tue) by madscientist (subscriber, #16861) [Link]

Great if there's some component on the system that can provide a best-guess as to whether it would work or not.

But, how about deferring to ME for the final decision, rather than some probably-out-of-date and not-quite-complete static database, regardless of where it lives?

Fedora reawakens the hibernation debate

Posted Sep 18, 2018 17:29 UTC (Tue) by mbiebl (subscriber, #41876) [Link] (1 responses)

We had such a quirks database with hal. I don't want to go back there.

Imho this is rather simple: GNOME should default to suspend-to-ram and only offer suspend-then-hibernate as an option.

Fedora reawakens the hibernation debate

Posted Sep 21, 2018 2:55 UTC (Fri) by flussence (guest, #85566) [Link]

udev having a quirks database isn't “going back to HAL” — it's keeping us out of the 2.4 dark ages where everyone had to hand-roll their modprobe script, xfree86.conf and asound.conf if they wanted hardware from $overpriced-PC-brand to work sanely.

Take an actual look in /lib/udev/hwdb.d/ (or /usr/share/{libinput,alsa,X11}/) sometime and marvel at how many $1000+ laptops have broken input and output devices that you haven't had to know about in 10 years or more, because someone else has gone through the pain for you (and BSD users!)

And this is just the userspace side of it; the kernel has its *own* quirks lists for really bad hardware like those self-bricking Intel NICs.

Fedora reawakens the hibernation debate

Posted Sep 18, 2018 1:24 UTC (Tue) by hp (guest, #5220) [Link]

The API GNOME is using appears to have two methods, "CanSuspendThenHibernate" and "SuspendThenHibernate"
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/comm...

In that code it looks like GNOME does "if (CanSuspendThenHibernate) { SuspendThenHibernate }" which, you know, seems reasonable.

If the implementation doesn't know whether it can SuspendThenHibernate (without crashing, to some degree of certainty), I'd say CanSuspendThenHibernate should return false.

If the only way to know whether CanSuspendThenHibernate is for a user to try to hibernate a bunch of times themselves and see if it fails, then the SuspendThenHibernate feature doesn't exist for all practical purposes - better for CanSuspendThenHibernate to always return false, or maybe always return false unless it's been manually enabled through some system-level configuration file.

If CanSuspendThenHibernate can't be trusted then it becomes impossible to ever enable the feature through system-level config or hardware quirks, because GNOME and others would have to ignore that API entirely. Better for everyone to use the API, and then fix the API (even if the fix is a config option, the option should configure the canonical API, rather than configuring only certain apps or certain desktops).