On Tue, Dec 20, 2011 at 14:31, Andy Whitcroft <apw@xxxxxxxxxxxxx> wrote: > On Sat, Dec 17, 2011 at 07:15:00PM +0100, Kay Sievers wrote: >> 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. > > No we wish to avoid 'settle'ing as that would force us to wait for the > majority of device probes to complete, and we do not have the majority > of the modules in the initramfs to service them. What does that mean? You wait for exactly what you yourself have triggered in the initramfs, not for anything unrelated or not loaded. And that's very likely the right thing to do. There are usually no other event pending at that point in time, unless you need to work around some other kernel bug here. :) 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
