On Tue, Oct 2, 2018 at 9:12 AM, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > On Di, 02.10.18 07:26, Justin Forbes (jmforbes@xxxxxxxxxxx) 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 supportable. -- Chris Murphy _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
