On Fri, Dec 16, 2011 at 18:46, Andy Whitcroft <apw@xxxxxxxxxxxxx> wrote: > In exit (udevadm control --exit) processing we currently dump the entire > incoming queue and ignore any further incoming kernel events. We then wait > for the current workers to complete any events they were assigned, before > finally exiting. However if any of the pending events should trigger a > nested event that new event would not be processed preventing completion > of the existing worker event. We will eventually timeout both leading > to a long boot delay and in some cases to partially initialised cards. > These cards often will not be repaired even during coldplug and are lost > requiring manual intervention to recover. > > Modify exit processing such that we handle events with timeliness > constraints on them, bringing them into line with normal processing. > This allows events which are triggered from our existing workers events > to run to completion and allow completion of those workers. This allows > us to flush the queue and exit cleanly. Is 'udevadm settle' called before doing --exit in the initramfs? If not, I guess that's why others have not seen that. In general, requesting firmware synchronously on module init sounds pretty broken. The firmware request should be async. If the device allow that, done as late as the first ifup of the netdev, and not at module load time. If udev is not running, modprobe will hang until it runs into the timeout? Having module init depending on a 'userspace transaction' sounds pretty weird. How does that work when the module is compiled-in? The TIMEOUT= is basically just a left-over from the times of the crazy /sbin/hotplug era, where all the hooked-in shell scripts took ages to handle events, and the kernel's firmware loaders default was 10 seconds, and it ran into that all the time. The patch looks sensible, but I haven't really wrapped my head around if we really should make the TIMEOUT= handling even more special here. I rather see the firmware loading model fixed for the affected drivers, as I think it is very wrong, for many other reasons too, what they do here. Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
