[systemd-devel] systemd hibernator generator does not function on default Fedora install
Chris Murphy
lists at colorremedies.com
Wed Apr 20 16:48:11 UTC 2016
On Tue, Apr 19, 2016 at 11:44 PM, Tobias Hunger <tobias.hunger at gmail.com> wrote:
>
> Am 20.04.2016 06:47 schrieb "Chris Murphy" <lists at colorremedies.com>:
>> I kinda have to agree, if it can't be encrypted, then I think linux
>> hibernation is almost pointless, and maybe just give up. Intel Rapid
>> Start (firmware managed) hibernation with SSDs and the proper GPT
>> partition type GUID is faster and more reliable, but also not
>> encrypted. So if we're stuck with something not encrypted anyway, I
>> don't see why we don't just throw in the towl and only support
>> firmware hibernation which has the added benefit of automatically
>> switching from sleep to hibernate when the battery gets too low, which
>> software hibernation can't do.
>
> Intel apparently discontinued rapid start with the skylake CPUs. At least
> that is what Lenovo told me when I could not enable IRST on my new laptop.
There two IRSTs. One is Rapid Storage (firmware raid working in
conjunction with mdadm), the other is Rapid Start. Rapid Start is what
I'm referring to and even though the branding tags the CPU it's really
a firmware feature. There's nothing to enable or disable, there's no
user configurable options at that level.
And I find it hard to believe something that hibernates and resumes
about as fast as sleep and wake, does not involve the OS at all, has
the ability to transition from sleep to hibernate when the battery is
low or after a specified time frame is going to be dropped in favor of
OS managed hibernation once again.
> So that can not be a solution for suspend on Linux going forward.
Versus the present state of affairs which is so much more unreliable?
--
Chris Murphy
More information about the systemd-devel
mailing list