(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Thu, 26 Mar 2009 00:29:59 GMT bugzilla-daemon@xxxxxxxxxxxxxxxxxxx wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=12944 > > Summary: Parallel initialization of USB creates races for boot > devices > Product: Drivers > Version: 2.5 > Kernel Version: 2.6.29-rc7 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: high > Priority: P1 > Component: USB > AssignedTo: greg@xxxxxxxxx > ReportedBy: dvomlehn@xxxxxxxxx > Regression: Yes > > > Speeding up initialization of USB devices appears to have created race > conditions for consoles and auto-configured network devices. Waiting until no > USB events have been received for a while before the kernel init opens > /dev/console appears to make the USB console work, but I have not found any > such work-around for handling network devices initialized with ip= parameters > on the kernel command line. > > Note that this problem first arose in 2.6.28, but, it's taken a while to narrow > this problem down. > > My configuration consists of a USB EHCI hub with a CP2101 serial device and an > RTL8150 Ethernet device. We have a very small INITRAMFS boot filesystem and not > much else in the way of devices, so we get to the IP autoconfig quite quickly. > The RTL8150 isn't enumerated yet, so autoconfig gives up after its standard two > tries. When we try to open /dev/console, we haven't got to the CP2101 and hence > have no console devices registered. This causes the open of /dev/console to > fail, although this is properly ignored. We're an embedded system, so that's > all the devices we have to communicate with at this point. Then the system just > sits there, deaf and blind. It's rather sad, really. > -- 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
