Re: [2.6.21.1] resume doesn't run suspended kernel?

["Rafael J. Wysocki" <rjw@sisk.pl>]

Hi,

On Tuesday, 29 May 2007 15:13, Nigel Cunningham wrote:
> Hi.
> 
> On Tue, 2007-05-29 at 14:40 +0200, Pavel Machek wrote:
> > On Tue 2007-05-29 14:03:07, Rafael J. Wysocki wrote:
> > > On Tuesday, 29 May 2007 13:29, Pavel Machek wrote:
> > > > Hi!
> > > > 
> > > > > > Yup.  Don't we do something like this for the (ACPI-based) suspend to RAM
> > > > > > already?
> > > > > 
> > > > > Yeah, I was thinking about this overnight too. It should be doable. In
> > > > > addition to what we already do, I think you'd want:
> > > > > 
> > > > > - to copy the assembly to do the copying to a safe page;
> > > > > - to put the location of the cpu state that was saved in the image
> > > > > header so that it can be used after the data is copied back;
> > > > 
> > > > ...alternatively, we can just rely on copy routine (and its data) not
> > > > changing frequently.
> > > > 
> > > > > - to copy the nosave data to a 'safe' page.
> > > > > 
> > > > > What else?
> > > > 
> > > > page directories need to be on a safe place, too.
> > > 
> > > They are already.
> > 
> > ...but will that place still be safe when we use other version of
> > kernel?

Yes.

> They'll be in the image too, won't they? Failing that, the information
> could be stored in the image header.

In fact, for each page we have the number of the page frame that it should be
restored to.  Page frame numbers don't change. :-)

> > Anyway, pagedirs are on the safe place, right? That means that we
> > swsusp should no longer clash with page allocation debugging... 
> 
> You mean DEBUG_PAGEALLOC? That can be overcome easily - I have code in
> current Suspend2 that works with DEBUG_PAGEALLOC. I handle the page
> fault, mapping the page and setting a flag in the fault handler to tell
> the atomic copy code to unmap the page again once it has been copied.

Well, I can't comment, I haven't look at that yet.

Greetings,
Rafael