From owner-freebsd-usb@FreeBSD.ORG Thu Feb 19 08:24:16 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 0C2D11065672; Thu, 19 Feb 2009 08:24:16 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.swip.net [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id 41F4D8FC20; Thu, 19 Feb 2009 08:24:15 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=62zwTFIj3cim9I4EVzoA:9 a=mlQQyM2_PiEC4-j1ouPOM5pCRaAA:4 a=50e4U0PicR4A:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe11.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1026022920; Thu, 19 Feb 2009 09:24:14 +0100 From: Hans Petter Selasky To: Andrew Thompson Date: Thu, 19 Feb 2009 09:26:41 +0100 User-Agent: KMail/1.9.7 References: <20090216.190312.1756925299.imp@bsdimp.com> <20090217.085424.775975548.imp@bsdimp.com> <20090219050200.GA84647@citylink.fud.org.nz> In-Reply-To: <20090219050200.GA84647@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902190926.42992.hselasky@c2i.net> Cc: freebsd-usb@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 08:24:16 -0000 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