On 05/11/14 19:07, Alan Stern wrote:
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.
Hi,
echo "hw.usb.no_boot_wait=0" >> /boot/loader.conf
--HPS
--
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
