USB2+umass: root mount fails
Hans Petter Selasky
hselasky at c2i.net
Thu Feb 19 08:26:57 PST 2009
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
More information about the freebsd-usb
mailing list