Re: swsusp 'disk' fails in bk-current - intel_agp at fault?

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Fri, 25 Mar 2005 15:24:15 +0100, Pavel Machek <pavel@suse.cz> wrote:
> 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.

Oh, always panic-happy Pavel ;). It really depends on what kind of
device has faled to resume. If the device is really needed for writing
image then panic is the only recourse, but if it some other device you
resuming just ignore it, who cares...

Btw, I dont think that doing selective resume (as opposed to selective
suspend and Nigel's partial device trees) would be so much
complicated. You'd always resume sysdevs and then, when iterating over
"normal" devices, just skip ones not in resume path. It can all be
contained in driver core I believe (sorry but no patch, for now at
least).

> 
> > 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?)
>

Not really, I won't be able to write any code anything till next week I think.

-- 
Dmitry