From owner-freebsd-usb@FreeBSD.ORG Thu Feb 19 16:26:55 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A49EA1065715; Thu, 19 Feb 2009 16:26:55 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id CE04E8FC1E; Thu, 19 Feb 2009 16:26:54 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=8kQB0OdkAAAA:8 a=zs6WiUrcYp1FutRstEwA:9 a=kL0MxikLeeivc0pPJa4A:7 a=GZU3bAq2iunWNZzQUEDF-EqnMmAA:4 a=50e4U0PicR4A:10 a=9aOQ2cSd83gA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1196734001; Thu, 19 Feb 2009 17:26:52 +0100 From: Hans Petter Selasky To: "M. Warner Losh" Date: Thu, 19 Feb 2009 17:29:16 +0100 User-Agent: KMail/1.9.7 References: <20090217.085424.775975548.imp@bsdimp.com> <200902190926.42992.hselasky@c2i.net> <20090219.090621.-786048162.imp@bsdimp.com> In-Reply-To: <20090219.090621.-786048162.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902191729.18715.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org, thompsa@freebsd.org Subject: Re: USB2+umass: root mount fails X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 16:26:57 -0000 Hi Warner, On Thursday 19 February 2009, M. Warner Losh wrote: > In message: <200902190926.42992.hselasky@c2i.net> > > Hans Petter Selasky 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