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.
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.
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.
David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
