[lkml]   [2007]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Hibernation considerations
    On Tue, 17 Jul 2007, Rafael J. Wysocki wrote:

    > On Tuesday, 17 July 2007 22:34, wrote:
    >> On Tue, 17 Jul 2007, Rafael J. Wysocki wrote:
    >>> On Tuesday, 17 July 2007 20:32, Alan Stern wrote:
    >>>> I'm still not entirely clear on how "suspend-to-both" ought to be
    >>>> handled. Presumably it will start off as a normal hibernation. But
    >>>> instead of shutting down, wouldn't the kexec'd kernel return to the
    >>>> original kernel?
    >>> No, I think the image-saving kernel should suspend. Then, on resume the
    >>> platform will go back to it and it will jump back to the hibernated kernel.
    >>>> After all, the original kernel knows about all the devices and can put them
    >>>> into a low-power state, while the kexec'd kernel might not have sufficient
    >>>> information.
    >>> That's correct, but ...
    >>>> But what about the freezer? The original reason for using kexec was to
    >>>> avoid the need for the freezer. With no freezer, while the original
    >>>> kernel is busy powering down its devices, user tasks will be free to
    >>>> carry out I/O -- which will make the memory snapshot inconsistent with
    >>>> the on-disk data structures.
    >>> ... we can't return to the hibernated kernel unless we are going to cancel the
    >>> hibernation.
    >> this is where we disagree.
    >> why not? if all that the hibernated kernel does is to suspend-to-ram and
    >> makes no changes to disks or TCP connections anything that it does do
    >> would be lost if power were to fail and you instead did a restore from
    >> disk.
    > How do you guarantee that no tasks are scheduled when you get back to the
    > hibernated kernel?

    just don't schedule any userspace tasks. all you need to do is to execute
    the ACPI sleep functions. you normally do that after stopping userspace

    >> there is only a problem if something takes place that would prevent the
    >> restore-from-disk from working. if this is done in a non-ACPI way that
    >> will work across a power cycle you don't have to worry about the hardware
    >> state not matching anyway.
    >>> That's why I think that for the suspend-to-both the image-saving kernel will
    >>> need to support the same set of devices as the hibernated kernel.
    >> suspend-to-both doesn't really make sense if the suspend-to-disk portion
    >> is useing the ACPI S4 mode.
    > Well, not exactly. If your battery runs out of power while you're suspended,
    > but you have the image saved, it's still better to restore from the image, even
    > if something may not work correctly after the restore, than to risk a loss of
    > data.

    if things don't work correctly you are still risking the loss of data, the
    user just doesn't know it.

    >> if you don't run out of power you will restore-from-ram
    >> if you do run out of power the restore-from-disk won't work either becouse
    >> devices are not in the right ACPI states.
    > See above.
    > Greetings,
    > Rafael
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-07-17 23:27    [W:0.037 / U:2.600 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site