On Thu, 2016-09-22 at 22:29 -0600, Chris Murphy wrote:
On Thu, Sep 22, 2016 at 6:00 PM, Ranjan Maitra
> On Fri, 23 Sep 2016 00:24:21 +0100 "Patrick O'Callaghan"
> > I'm using kernel-4.6.6-300.fc24.x86_64 with the proprietary NVidia
> > driver, plus daily updates from the stable repos. Hibernation used to
> > work with previous kernels, but now regularly fails to wake up
> > properly, i.e. on restarting I get the BIOS screen followed by the boot
> > text console and select the first (newest) option as usual. So far so
> > good. Then after a few seconds I see the BIOS again, repeat the
> > selection, and get a full reboot.
> > Anyone else seeing this?
> I have been seeing this once in a while over the past two weeks. (And I do not have
a NVidia card or driver.) However, in my case, it just reboots.
> Initially, I thought that maybe I had run out of battery (even though this did not
make sense), but the day before (when it last happened), I noticed that the battery was at
100% when it booted in. So, I had the same thought, and have been thinking of moving to
the vanilla kernel (where hibernate works out of the box) since Fedora has decided that
they and not the user should decide that we should not have support for hibernation (a
decision which I am very disappointed with -- per reasoning below).
> This decision has the potential to essentially kill hibernation in the long-term
because fewer people will use it if something requires additional work to get it going (as
happens with Fedora and I think Ubuntu). As a result, less people will be catching bugs
and even fewer will be reporting them (of course, reporting within Fedora may not even be
allowed anymore since it is disabled by default).
> Hibernation besides, being environmentally friendly, also is often, when you are
taking a long trip in the middle of nowhere, the only way to get your battery to last
> Anyway, sorry for expressing my disappointment.
Part of the problem it Linux has to implement its own hibernation
because Intel, one way or another, doesn't provide access to the
various power states supported by the hardware. Like in the case of
Rapid Start, which appeared to be supported in Windows 8 and is now
dead (didn't last long) was something the vendor had to license to get
access to the code. I have no idea what they're using now on Windows
10. So the hardware keeps changing. On the one hand the power
management stuff in hardware is getting better but the required code
isn't going into the kernel. That's just one part where it can fail.
Another part where it can fail now is UEFI Secure Boot. The image file
isn't encrypted so it's possible to modify the image and bypass the
whole point of Secure Boot. They're are patches but as far as I know
they're not upstream. In fact Fedoras UEFI Secure Boot support isn't
upstream because they've been dragging their feet on a distro unified
position how to support it. That's another part where it won't work,
Next, there's disagreement between systemd, dracut, and anaconda
developers on how to provide the hint to the kernel needed for it to
find the hibernation image. All the other distros I'm familiar with
use resume=<dev> as a boot parameter to do this, but anaconda devs say
this is dracut's job to find it. So out of the box it's not even
configured for hibernation.
Because of how hibernation works on Linux: the hibernation image is
written to disk, then the computer is powered off, to resume you are
actually cold booting, going through the bootloader which loads the
kernel and initramfs just like a regular boot, but then the kernel
sees the hint finds the hibernation image and loads it, it's actually
pretty damn slow. If you have a pile of applications and docs open,
yes all of that gets resumed as well with resume from hibernation, but
not so for a true reboot. So there might still be some savings.
But even if everything none of the above apply, and you've configured
it yourself, it can still fail just because of kernel and hardware
bugs. I've tried using hibernation, the kernel finds the image, but
then rejects it as bad, 100% of the time. So enabling this by default
for everyone with no means of per model or per configuration
blacklisting is fraught with peril. It's not appropriate to give
people the idea their computer will safely hibernate, protecting their
data, and then just face plant on resume.
Executive summary: yes, hibernation *is* broken, and may never be fixed.
I have no insight what the desktop folks are looking to build, but
take is that more applications need to save their states
automatically. If they get force quit, such as what'd happen during an
abrupt power off at critical power, they'd see this "dirty" state and
recover on their own. Maybe there's something the DE could do to make
that easier for developers to opt into. The idea of manually saving
documents is pretty antiquated, we don't do this with mobile devices,
there's no good reason why we're still doing this on laptops except it
just hasn't caught up. The DE could maybe keep track of what programs
are running, and again if upon login finds a "dirty" flag it can
autolaunch those programs.
That would be great if the session control in the various DE's was
reliable. As a KDE user I find it's a crap shoot. Some apps come back
up reliably, some don't. The ones that don't seem to be those written
to Gtk rather than Qt (but maybe under Gnome it's the other way round).
Typical errors include not remembering which virtual desktop they were
on, or sometimes just losing all their tabs (Chrome, I'm looking at
you). Luckily I've never lost any data (touch wood).
Anyway between, hardware, firmware, bootloader, kernel, installer,
systemd, it's not easy for users to even produce quality bug reports
that isolate the actual cause of hibernation not working. "not
working" doesn't come close to helping pinpoint the problem. And long
term I'm not sure either users or developers have much interest in
this working any better than it does, or finding a better way entirely
to do it seeing as we just aren't getting enough support from Intel
for these sorts of things (or anyone else for that matter).
Exactly. It's an unholy mess.