Messages in this thread |  | | | Date | Tue, 17 Jul 2007 14:17:35 -0700 (PDT) | | From | david@lang ... | | Subject | Re: Hibernation considerations |
| |
On Tue, 17 Jul 2007, Rafael J. Wysocki wrote:
> On Tuesday, 17 July 2007 22:34, david@lang.hm 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 anyway.
>> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |