On Tue, 21 Apr 2009, Hal Murray wrote: > I'm missing the key idea. > > Is the problem that the hardware is broken by design and might never say > "console is over here"? If so, why don't I hear lots of complaints about > plugging something in and the system never seeing it? How does booting from > a USB disk work? No, that's not the problem. The hardware isn't broken, by design or otherwise. _Booting_ from a USB disk is a totally separate issue. Booting is done by the BIOS (or other firmware), so finding the disk drive and setting up a driver for it is the BIOS's problem, not the kernel's. Perhaps you had in mind running with the root filesystem on a USB disk? That indeed is a problem and has been for years. It is a large part of the reason the "rootwait" kernel parameter exists. > Or is the problem that the USB hardware is so complicated that the driver > needs an environment with interrupts and threads and whatever which may not > be available when you want a console for low level debugging? No, interrupts, threads, and whatever are already available when the cnosole is registered. The problem is that the console device is opened at a specific point during the boot procedure. If the open call fails, then neither init(1) nor any of its descendants will have a stdin or stdout. Discovering and probing devices on a USB bus takes time, and thanks to the recent round of improvements in boot speed, the kernel tries to open the console before a USB serial device can be discovered and registered. Consequently the open call fails. If the open could be delayed for an appropriate length of time then it would succeed. The _hard_ problem, which nobody has figured out how to solve yet, is determining how long that "appropriate" length of time should be. 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
