On Thu, 2016-09-22 at 22:29 -0600, Chris Murphy wrote: > On Thu, Sep 22, 2016 at 6:00 PM, Ranjan Maitra > <maitra.mbox.ignored@xxxxxxxxx> wrote: > > > > On Fri, 23 Sep 2016 00:24:21 +0100 "Patrick O'Callaghan" <pocallaghan@xxxxxxxxx> wrote: > > > > > > > > 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 while working. > > > > 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, > yet anyway. > > 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 my > 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. poc _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
