Date: Thu, 19 Feb 2009 07:39:09 -0800 From: Alfred Perlstein <alfred@freebsd.org> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-usb@freebsd.org, Andrew Thompson <thompsa@freebsd.org> Subject: Re: USB2+umass: root mount fails Message-ID: <20090219153909.GK75810@elvis.mu.org> In-Reply-To: <200902190926.42992.hselasky@c2i.net> References: <20090216.190312.1756925299.imp@bsdimp.com> <20090217.085424.775975548.imp@bsdimp.com> <20090219050200.GA84647@citylink.fud.org.nz> <200902190926.42992.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I really don't understand why it can't be made an option. The cold probe can be done right before mountroot where threads are available. Not doing this deterministically is bad, but forcing slow behavior as the only option seems equally bad. Offering choice seems to be the right solution. -Alfred * Hans Petter Selasky <hselasky@c2i.net> [090219 00:24] wrote: > 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 > _______________________________________________ > freebsd-usb@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-usb > To unsubscribe, send any mail to "freebsd-usb-unsubscribe@freebsd.org" -- - Alfred Perlstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090219153909.GK75810>