On Tue, 29 Mar 2005 21:23:39 +0200, Pavel Machek <[EMAIL PROTECTED]> 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 - 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/
