Date: Thu, 19 Feb 2009 09:26:41 +0100 From: Hans Petter Selasky <hselasky@c2i.net> To: Andrew Thompson <thompsa@freebsd.org> Cc: freebsd-usb@freebsd.org Subject: Re: USB2+umass: root mount fails Message-ID: <200902190926.42992.hselasky@c2i.net> In-Reply-To: <20090219050200.GA84647@citylink.fud.org.nz> References: <20090216.190312.1756925299.imp@bsdimp.com> <20090217.085424.775975548.imp@bsdimp.com> <20090219050200.GA84647@citylink.fud.org.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Thursday 19 February 2009, Andrew Thompson wrote: > I think its slightly more complex that adding a cold explore task. Cold explore is not possible any more and adds unneccesary complexity to the USB code. USB is dependant on processes/threads/tasks to execute. > Most of the USB2 periperhel drivers defer a portion of their attach to a > thread task, a change which needs to be reverted first. As others have > said both the probe and attach must be synchronous. 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. Another point I have is that we want to do operations in parallell. I see no reason at all to slow down the USB enumeration at boot. We are talking about a considerable amount of time! Instead the system needs to be changed. If you try to mount a device which is not present, then you need to retry mounting that device if some re-try flag is set. Adding some flag to "struct usb2_device" saying that the device is gone will almost solve the problem, but it does not cover the kldunload case. Also it can be quite dangerous if attach is hanging and we do a kldunload. Then I don't know what will happen. And we don't want to open that window by making USB attach always synchronous. Neither should we depend on the EHCI/OHCI/UHCI hardware to simply eject transfers on dissappeared devices, see three strikes and you are gone rule. --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200902190926.42992.hselasky>