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

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

On Tue, 29 Mar 2005 21:23:39 +0200, Pavel Machek <pavel@suse.cz> wrote:
> Hi!
> 
> > > > If you look at Andy's second trace you will see that we are waiting
> > > > for the disk I/O to get /sbin/hotplug from the disk. Pavel, do you
> > > > know why IO does not complete? khelper is a kernel thread so it is
> > > > marked with
> > > > PF_NOFREEZE. Could it be that we managed to freeze kblockd?
> > >
> > > Uf, no idea about kblockd freezing -- we certainly should not.
> > >
> > > *But*, if we are doing execve while system is frozen, something is
> > > very wrong. We should not be doing execve in the first place.
> >
> > Well, there lies a problem - some devices have to do execve because
> > they need firmware to operate. Also, again, some buses with
> > hot-pluggable devices will attempt to clean up unsuccessful resume and
> > this will cause hotplug events. The point is you either resume system
> > or you don't. We probably need a separate "unfreeze" callback,
> > although this is kind of messy.
> 
> There's a better solution for firmware: You should load your firmware
> prior to suspend and store it in RAM. Anything else just plain does
> not work. (Because your wireless firmware might be on NFS mounted over
> that wireless card).
> 
> Hotplug... I guess udev just needs to hold that callbacks before
> system is fully up... it has to do something similar on regular boot,
> no?

Well, I did not really look into udev but hotplug (which can iteract
with udev) does not keep anything. If it fails its ok - that's why
there are coldplug scripts that "recover" lost events. But here we
block trying to start hotplug - we not getting an error - and this is
bad. Unfortunately I am not familiar with block devices working to say
why it hangs.

Should we pull Jens into the discussion?
 
-- 
Dmitry