Re: Hibernation considerations

[david]

On Sat, 21 Jul 2007, Pavel Machek wrote:

> > > > > So it will be break at least battery status and "AC plugged in"
> > > > > status, because those are handled by ACPI and we do not know how to
> > > > > control them by hand.
> > > >
> > > > It seems that it should be possible to initialize ACPI as if the system
> > > > just booted up normally.  Then battery status and such should be
> > > > correct, since they are correct after normal initialization.
> > > >
> > > > It should be possible to make hibernate look just like a reboot to all
> > > > of the devices, including ACPI stuff.
> > >
> > > Patch to make that work with swsusp/shutdown method would be indeed
> > > welcome. It does not work today.
> >
> > is this a problem in the restore path?
> >
> > with the kexec approach (and ignoring suspend to ram and disk for the
> > moment) the system will actually get shutdown completely after the image
> > is written. on resume it gets cold booted. at this point the ACPI stuff
> > should have no problem
> >
> > now if the ACPI drivers are storing something in ram about the battery
> > status and AC power status, but don't re-check after the resume, it
> > seems
>
> That seems to be the problem. They store something in ram, and we
> don't tell them that we resumed. That's why platform mode is
> important, and way to go on ACPI systems.

this sounds like the few drivers that do this sort of thing (and this 
should only be the things that report status, drivers that enable devices 
should be taken care of) need a 'forget what you think you know, check the 
reality of the hardware' function.

even without suspend I've sen these drivers get out of sync with reality, 
and so such a function call would be useful to get them back in sync in 
any case.

if such a 'check reality' function was available it should be 
straightforward to call it after a non-ACPI hibrnate/resume

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/