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

[Pavel Machek]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/