On Fri, Apr 25, 2008 at 11:19:02AM +0300, Pekka J Enberg wrote:
quoted text
> 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/