USB2+umass: root mount fails

[Hans Petter Selasky]

Hi Warner,

On Thursday 19 February 2009, M. Warner Losh wrote:
> In message: <200902190926.42992.hselasky at c2i.net>
>
>             Hans Petter Selasky <hselasky at c2i.net> writes:
> : Do you understand why probe and attach is currently partially deferred in
> : some drivers? It has to do with the ability to quickly recover if a
> : device is suddenly detached when doing multiple sequential USB operations
> : towards a USB device. I have the impression that you are not thinking
> : about failure cases like constant timeouts. What makes the picture
> : additionaly complicated is that there are multiple sources of detach,
> : that do not all go through the USB stack.
> :
> : kldunload does not go through the USB stack.
> : set_config does.
> : device_detach does.
>
> You are doing something wrong then.  All of these *DO* go through
> newbus for proper drivers.  If not, then that's a bug in newbus and
> should be fixed there, not kludged around.

Yes, but they do not go through the USB stack [thread].

When you are running kldunload then the kldunload process is doing the 
detach(). This can crash with the USB explore thread adding and removing 
devices.

Last time I checked the newbus attach/detach was only protected by "Giant" 
which is exited when an operation is sleeping. This Giant needs to be 
replaced by a sleep-enabled lock, like a SX lock, which will not get exited 
when we are calling msleep(), pause() or cv_wait().

>
> None of this prevents the usb stack from signaling when the
> probe/attach is done.

It is not a problem to do a synchronous enumeration of the USB stack before 
mountroot. It just wastes time in my opinion.

> You can't expect mountroot to wait forever.
> Also, there are times when there's multiple disks available that could 
> be root.  Just waiting for root is also bad because that root might
> not ever get there.  There has to be some sanity timeout.  

Yes, you have a point there. I think that fallback options should only kick in 
after a reasonable timeout. The first non-fallback disk to present itself is 
selected within a tuneable delay.

> By properly 
> signaling that the operation is complete, you can have better
> semantics. 

Yes, I can make such a function for USB. We know how many USB busses there are 
after attach and we can keep a refcount which cause a callback when the 
refcount reaches zero.

Does such a function or API already exist that USB can call? And what should 
such a function do? Should it just signal that it is time to go trying 
secondary boot options?

> All the other drivers in the system can accommodate this 
> paradigm.  What makes usb so special?

There is nothing special about USB.

>
> These sound like they might be bugs in newbus.  Can you elaborate on
> the details?

See top of e-mail.

--HPS