FreeBSD Developer Summit Laptop Hibernation Hacking Session

May 15th (Thursday), room will be announced when it is known.

Overview

As part of the May 2014 FreeBSD developer summit, this working group will work on support for laptop hibernation. Suspend and resume is hit or miss on many laptops. One of the most common issues is for a laptop to resume ok, but the LCD panel does not turn on leaving the user in the dark. Hibernation works around this limitation since from the hardware's perspective the operations are the same as if the laptop was turned off and then back on. As such, it seems to have a chance of supporting a much broader range of laptops. Note that this session is not going to try to debug suspend and resume issues for S3 (suspend-to-RAM). The focus will be on implementing S4 for at least amd64 and possibly i386.

If you would like to participate, contact the chairperson below and CC devsummit@. You will be then added to this page. Please include a list of things you want to talk about or the areas you are interested in. This helps in planning the session and to bring people together with common interests.

Goals

Specific Tasks

Some of these tasks can be done in parallel, though having a few of them done ahead of time might be nice. In particular, the bhyve changes would make bhyve a nice platform for testing these changes. Another alternative would be to use other hypervisors that already have S3/S4 support with a "raw" disk backend.

Task

Status

Owner

Description

Implement S3 support in bhyve

Not Started

Add an _S3 object and handle S3 in the ACPI power management code in the hypervisor by suspending the process until it is resumed. Probably should wire a signal up to the fixed feature suspend button to use for requesting S3 externally and to resume a suspended guest. The reason for having this is it allows a way to test some of the other changes in a guest without having to hose an actual machine.

Quiesce the scheduler in suspend and shutdown

Not Started

For both shutdown and suspend we need to stop user processes from generating new I/O requests so that we can in turn better quiesce hardware.

Clean filesystems during suspend

Not Started

Right now filesystems are simply left as-is during suspend. The system should flush all dirty buffers to disk (once the scheduler is quiesced) and mark filesystems as clean during suspend. This avoids losing data and having to fsck if resume fails. I think we should even try this for NFS, but we should have a timeout on how long we will wait for dirty NFS writes to post.

Implement S4 support in bhyve

Not Started

Add an _S4 object and generally treat S4 like S5. For now I think we can punt on trying to implement the S4 resume logic in bhyve itself, though it might be nice to at least store a flag in the VM context that userboot can check for and decide to do an S4 resume instead of loading a new kernel image.

Write a copy of RAM and other data to a dedicated partition

Not Started

We can check if a bhyve guest writes out the data we think it should write.

Read the data from the dedicated partition into RAM from the loader

Not Started

Writing this in userboot should permit bhyve to resume. The code should be easily ported to libi386 for use with real hardware.

Attempt suspend and resume on real hardware

Not Started

Support using a file in the filesystem instead of a dedicated partition?

Not Started

Attendees

Name

Affiliation

Topics of Interest

Other Notes

JohnBaldwin

FreeBSD

Session chair

GlenBarber

FreeBSD

Testing

PawelJakubDawidek

FreeBSD

ColinPercival

FreeBSD

DevSummit/201405/Hibernation (last edited 2021-04-25T09:10:45+0000 by JethroNederhof)