Re: [linux-pm] Re: [PATCH 0/2] Kexec jump: The first step to kexecbase hibernation

[david]

On Fri, 13 Jul 2007, Alan Stern wrote:

> On Fri, 13 Jul 2007, Rafael J. Wysocki wrote:
>
> > > I missed this discussion. is this idea to suspend, write to disk, but
> > > leave things in ram so that if you wakeup soon enough you have everything
> > > for ram, but if you don't and the battery dies you can restore from disk?
> > >
> > > if so I think it's a mistake to mix the two. it would be better to just
> > > suspend to ram, and wake up once in a while to check the battery state and
> > > when the battery gets low enough do the suspend to disk.
> > >
> > > otherwise you end up mixing the requirements of the two types of suspend,
> > > which is how things got so ugly in the first place.
> >
> > Not necessarily.  If we don't put devices into low power states before creating
> > the image, that should work just fine (quiesce devices, create the image or
> > kexec the new kernel, reprobe devices, save the image, suspend to RAM,
> > resume from RAM, continue - or restore from the image if power failed in the
> > meantime).  Still, for this purpose, both kernels need to be able to handle the
> > same set of devices.
>
> Why?
>
> Suppose the kexec kernel can't handle some device.  The normal kernel
> has already quiesced the device, so it will remain quiescent while the
> kexec kernel runs and throughout the suspend.  When the regular kernel
> regains control the device will be ready for use.  I don't see any
> problem.

remember that during the hibernation the box may be powered off.

but there's still no reason for the hibernate kernel to know how to access 
the USB TV Tuner for example.

David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/