Hi!
> > > > OK, anything else I should try?
> > >
> > > not really, i just wait for Vojtech and Pavel :-)
> >
> > Try commenting out "call_usermodehelper". If that helps, Stefan's
> > theory is confirmed, and this waits for Vojtech to fix it.
> >
>
> This is more of a general swsusp problem I believe - the second phase
> when it blindly resumes entire system. Resume of a device can fail
> (any reason whatsoever) and it will attempt to clean up after itself,
> but userspace is dead and hotplug never completes. While I am
> interested to know why ALPS does not want to resume on ANdy's laptop
> the issue will never be completely resolved from within the input
> system.
When device fails to resume, what should I do? I think I could
if (error)
panic("Device resume failed\n");
, but... that does not look like what you want.
> Pavel, is it possible for swsusp to disable hotplug (probably just do
> hotplug_path[0] = 0) before resuming in suspend phase?
It feels like a hack, but yes, I probably could do that. (Do you have
patch to try?)
> A bit on tangent - you need to resume system so you can write the
> image, right? I wonder if we could add a flag to struct device that
> would mark device as "on_resume_path". The flag would be set when you
> select resume partition and propagated to the root of the system. Then
> when resume after making the image you could skip all devices that are
> not on resume path.
I'm not going to do that, see FAQ in swsusp.txt.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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/
