On Fri, Apr 25, 2008 at 11:19:02AM +0300, Pekka J Enberg wrote: > Hi Matthew, > > On Thu, 24 Apr 2008, Matthew Dharm wrote: > > > > This also has all sorts of races between do_mounts 'waiting' and the actual > > > > USB device enumeration. It's entirely possible that the kernel loads via > > > > BIOS, the USB drivers are loaded, that forces devices to disconnect/reset, > > > > and they take a while to re-enumerate. During that delay, the kernel gets > > > > to do_mount; now, no devices show in this "waiting for scan" count. > > On Fri, Apr 25, 2008 at 09:30:52AM +0300, Pekka J Enberg wrote: > > > So how does that happen? ->storage_probe fails and driver core calls it > > > later at some point? > > On Fri, 25 Apr 2008, Matthew Dharm wrote: > > There's no guarantee that storage_probe is going to get called in a timely > > manner. > > How can we add such a guarantee? Don't we have this problem with any other > storage devices? No we don't. The problem with USB is that you _never_ know if you are done discovering all of the devices that are currently plugged into the bus. For PCI SCSI and ATA devices, that is not an issue. So no matter how many times you think you can mark things "done" you never really know for sure. So this means that we can't do this in the kernel, use an initramfs if you want such functionality, you can sit and spin there and wait until the device that you think you "know" is there to show up before continuing on with the boot process. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
