On Sun, 11 May 2014, drago01 wrote: > >>> I know that 1-4 is the touchscreen (its an ultrabook with a > >>> touchscreen) ... the touchscreen itself works just fine though. > >>> So if it takes more time / attempts to enumerate it and it works > >>> eventually anyway why do we block boot on it? > >> > >> That is a question for the systemd people / list. > > > > systemd-devel@, WTF!? :) > > systemd ain't kernel! As I understand it (and my understanding could easily be wrong), device probing happens asynchronously during boot-up. Then when the kernel is about to mount the real root fs, it waits for all those async probes to finish so that the real root device will have been found and is ready for use. Thus, a device that introduces a long delay during probing can block booting, even if it doesn't contain the root filesystem. It's a heavy-handed approach. Maybe it would be possible to cut the wait short when the root device has been found, maybe not. I'm not an expert on this. Part of the problem is that the USB stack contains too many nested retry loops with long delays in the device initialization pathway. It's not clear which of them should be removed, however. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
