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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
