On Tue, Oct 2, 2018 at 9:12 AM, Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Di, 02.10.18 07:26, Justin Forbes (jmforbes(a)linuxtx.org) wrote:
> > What is new is that GNOME (g-s-d) now uses it be default through
> > by choosing suspend-then-hibernate as suspend action when
> > hibernation is available.
> Right, so systemd really is just proxying, and Gnome is now creating a
> policy. It does not change the underlying issue, we shouldn't cripple
> a mechanism because someone wants to introduce a new undesirable
Uh, the mechanism is already "crippled", I mean, that's the key of the
issue: the hibernation mechanism apparently doesn't have the quality
and does not receive the love it needs for the Fedora community to
support it properly.
I don't think it's a community issue or Fedora kernel team issue at
all. It's strictly maintained, warts and all, by upstream kernel
developers. There's also some complicating factors as to which ACPI
version is used by Windows (I think it's insisting the hardware
fallback to a much older ACPI revision, where Linux has at least until
recently (?) supported the latest version of ACPI the hardware
supports). Even Windows 10 doesn't always get hibernation
right/reliable. And so we end up in a much bigger pit of potential
bugs than even Windows does on the same hardware - and it affects the
reliability of suspend to RAM not just suspend to disk. On very common
HP hardware, I see a wake from suspend to RAM hard fail about 1 in 5
times and there's nothing in the logs because it's crashing during the
wake up phase, not even video has been initialized yet so there's
literally nothing to do about some of these problems.
I suggest that the original question of this thread needs to go
upstream, and supplement it with more questions there, just exactly
what the state of S4/S5 support really is; and what it's going to look
like in the future.
Again, the Windows 10 case is, they're basically bailing out on saving
user state in the hibernation file. Instead, upon hibernation being
needed, they're basically logging the user out, expecting applications
save their own state, and then create a hibernation file based on all
users being logged out. That way all a restore from hibernation is
merely a faster arrival at the login window than booting. If the
hibernation restore works, it's fast, if not, you have to do a full
boot. Either way the experience for the user is the same, you still
have to log back into your user, and launch apps.
Also, I'd consider the kernel hibernation mechanism itself broken
because a) we don't have a Secure Boot implementation for hibernation
upstream and b) we don't have a Secure Boot implementation upstream
either. I think upstream kernel devs need to bite the bullet on how
they're going to support Secure Boot, before they're supporting
hibernation. Arguably both things are busted (or vapor) right now.
That it's working with some legacy computers is neat but even if that
were 51% of computers, it's not good enough to say it's working or