Re: swsusp_suspend continues?

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

On Thursday 16 March 2006 10:19, Pavel Machek wrote:
> On Čt 16-03-06 13:20:35, Con Kolivas wrote:
> > Hi Pavel
> > 
> > I've been playing with hooking in the post resume swap prefetch code into 
> > swsusp_suspend and just started noting this on 2.6.16-rc6-mm1:
> > During the _suspend_ to disk cycle on this machine the swsusp_suspend function 
> > appears to continue beyond swsusp_arch_suspend as I get the same messages 
> > that I would normally get during a resume cycle such as this:
> > 
> > Suspending device platform
> > swsusp: Need to copy 14852 pages
> > Intel machine check architecture supported.
> > Intel machine check reporting enabled on CPU#0
> > and...
> > eth1: Coming out of suspend...
> > and so on
> > 
> > but then it manages to write to disk and power down anyway. Is this correct? 
> 
> Yes. We need our hardware enabled for image write (disk would be
> enough), so we resume it (and we resume all of it, because that was
> easier to code).
> 
> > If I put post_resume_swap_prefetch at the end of swsusp_suspend it hits that 
> > function on both resume _and_ suspend cycles. Am I missing something?
> 
> No. That's just the way it is.

But there is the in_suspend variable that you can use to avoid doing
unnecessary things during suspend (during resume in_suspend is 0).

> See 
> 
>         /* Restore control flow magically appears here */
> 
> and 
> 
>         /* Code below is only ever reached in case of failure. Otherwise
>          * execution continues at place where swsusp_arch_suspend was called
>          */
>         BUG_ON(!error);
> 
> Yes, I agree it is confusing, and feel free to suggest comment cleanups.
> 
> I'd suggest you hook at disk.c:pm_suspend_disk.

Or use in_suspend.

> Or just include that /sys interface, and trigger it from userspace
> just after resume. Actually I like that best. It is optional, it can
> be triggered from userspace, and you will not have to deal with
> suspend internals.
> 
> (And it will be useful to uswsusp, too, that avoids big chunks of
> in-kernel suspend code).

Agreed.

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/