Messages in this thread | | | Date | Fri, 25 Mar 2005 15:24:15 +0100 | From | Pavel Machek <> | Subject | Re: swsusp 'disk' fails in bk-current - intel_agp at fault? |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |