Hi,
Fedora Workstation WG is tracking the following issue:
Support for hibernation? https://pagure.io/fedora-workstation/issue/121
ACPI power states decoder ring [1] S0 normal powered on state, S0 low power idle, freeze, s2idle, connected/modern standby, power nap S1 standby, power-on suspend, shallow S2 not used on linux S3 suspend, suspend to RAM, S2RAM, sleep, deep S4 soft off, used for hibernate/suspend to disk and implies firmware coordination S5 power off, used for hibernate/suspend to disk
Summary of the issues:
- Hibernation image and swap (paging) share the swap device. There's no kernel support to separate them. With a shared swap partition, there's no guarantee there will be enough contiguous free space (this is a requirement) to write out the hibernation image.
- A swap device sized at 1:1 with RAM, and any appreciable use of swap, will thwart the creation of a hibernation image. This is discovered at hibernation image creation time.
- A swap device sized at 2:1 with RAM might be quite a lot more reliable, but it's still not a guarantee. And already the swap partition is considered too big.[2] And we're considering dropping it by default in Fedora 33 in favor of swap-on-ZRAM. [3]
- Hibernation is getting very little attention by hardware vendors and Microsoft.
- For 5+ years the emphasis has been on S0 low power idle (a.k.a. freeze, standby, s2idle, S2I, modern standby, and power nap), and faster boots. Hibernation is intended as a last resort fallback when the battery charge becomes low.
- Microsoft's hardware certification mandates UEFI Secure Boot by default since Windows 8 (2012). It's reasonable to estimate this is the vast majority of present and future hardware.
- Linux kernel enforces hibernation lockdown (among other things), on UEFI systems with Secure Boot enabled.
- S3 (a.k.a. suspend, suspend-to-RAM, S2RAM, STR, sleep, deep) is widely available hardware and linux support wise; but the gotcha has always been wake from suspend and device reactivation, including graphics. There are lots of firmware, ACPI, and kernel bugs, and regressions, and it's make/model/version specific.
- Lately, since ~2018 [4], linux is catching up, with more effort being put into S0 low power idle (called s2idle on linux and either connected standby or modern standby on Windows, and power nap on macOS). It's all done in software, and ostensibly has no firmware or ACPI dependencies, so it can be done on any platform.[4]
- uswsusp: I can't find any recent upstream information on it. [6] It's not packaged in Fedora. I see no evidence of image signing capability. If it could work around kernel Secure Boot lockdown, I think most any reasonable person would consider that a security vulnerability.
- Fedora kernel team has said resource constraints means hibernation is not a priority, i.e. it's best effort, and can't practically be release blocking. There's prior, Fedora specific, kernel, systemd, and GNOME discussion in these threads. [7]
I'll start a separate thread for questions and discussion.
[1] https://www.kernel.org/doc/Documentation/power/states.txt https://www.kernel.org/doc/html/v4.19/admin-guide/pm/sleep-states.html [2] https://pagure.io/fedora-workstation/issue/120 [3] https://pagure.io/fedora-workstation/issue/127 [4] https://lwn.net/Articles/762132/ [5] https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/... [6] http://suspend.sourceforge.net/ https://wiki.archlinux.org/index.php/Uswsusp [7] https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org... https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org... https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org...
On Mon, Feb 10, 2020 at 4:33 AM Chris Murphy lists@colorremedies.com wrote:
- A swap device sized at 1:1 with RAM, and any appreciable use of
swap, will thwart the creation of a hibernation image. This is discovered at hibernation image creation time.
- A swap device sized at 2:1 with RAM might be quite a lot more
reliable, but it's still not a guarantee. And already the swap partition is considered too big.[2]
Actually, as I learned recently, you can't hibernate if you use occupy than 50% of total memory, it will fail with "can't allocate memory" error. The reason, at least what I found out, is that the kernel first copies the whole memory into your memory (ouch), before writing it to the swap partition. So if you have 16 GB RAM, you can't hibernate if you use more than 8 GB, and therefore an 8 GB swap partition (fully unoccupied) is enough for you. I have tested this multiple times, it works for me exactly as written. So, actually, a swap device sized 1:1 with RAM is already an overkill (unless you use more than 50% of swap size with just regular usage), and 0.5:1 ratio would be perfectly fine if you made sure that swap got used just for hibernation.
On Mon, Feb 10, 2020 at 4:28 pm, Kamil Paral kparal@redhat.com wrote:
Actually, as I learned recently, you can't hibernate if you use occupy than 50% of total memory, it will fail with "can't allocate memory" error. The reason, at least what I found out, is that the kernel first copies the whole memory into your memory (ouch), before writing it to the swap partition. So if you have 16 GB RAM, you can't hibernate if you use more than 8 GB, and therefore an 8 GB swap partition (fully unoccupied) is enough for you. I have tested this multiple times, it works for me exactly as written. So, actually, a swap device sized 1:1 with RAM is already an overkill (unless you use more than 50% of swap size with just regular usage), and 0.5:1 ratio would be perfectly fine if you made sure that swap got used just for hibernation.
Seems like case in point for why we do not (and should not) support hibernation.
On Mon, Feb 10, 2020 at 4:51 PM Michael Catanzaro mcatanzaro@gnome.org wrote:
Seems like case in point for why we do not (and should not) support hibernation.
If "not support" means not enabling it out of the box and/or not creating a swap partition, that's fine by me. I'd be a sad panda if you introduced roadblocks that would prevent hibernation and required heavily patching GNOME to enable it, though. As I mentioned in the other thread, suspend to RAM doesn't work for me, so I rely on hibernation pretty heavily. I found one of the mentioned roadblocks some time ago, when I wanted to enable hybrid sleep on one of my other machines. It can be easily configured through logind, but gnome-settings-daemon overrides the power button event and only offers a limited selection of actions (hybrid sleep not being one of them). It also doesn't offer "don't consume the event, ignore it" action. So even though I can easily trigger hybrid sleep from command line, I can't trigger it when pressing the power button or perhaps closing the lid. That's fine for me (although inconvenient), but not fine for my parents. Of course I reported this against gsd, but nothing happened. So when you make changes, just please think about people who might want to enable hibernation or some other action for some reason, and don't completely lock them out (add a gsettings option or something). Thanks.
desktop@lists.fedoraproject.org