Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Feb 2009 21:02:00 -0800
From:      Andrew Thompson <thompsa@FreeBSD.org>
To:        "M. Warner Losh" <imp@bsdimp.com>
Cc:        freebsd-usb@FreeBSD.org
Subject:   Re: USB2+umass: root mount fails
Message-ID:  <20090219050200.GA84647@citylink.fud.org.nz>
In-Reply-To: <20090217.085424.775975548.imp@bsdimp.com>
References:  <20090216.190312.1756925299.imp@bsdimp.com> <7F91349C-7E58-47C8-BB69-3B2F391B4E73@mac.com> <200902170856.11631.hselasky@c2i.net> <20090217.085424.775975548.imp@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 17, 2009 at 08:54:24AM -0700, M. Warner Losh wrote:
> In message: <200902170856.11631.hselasky@c2i.net>
>             Hans Petter Selasky <hselasky@c2i.net> writes:
> : On Tuesday 17 February 2009, Marcel Moolenaar wrote:
> : > > But it looks like the old usb code didn't call it either...  I think
> : > > old code enumerated right away during boot, while the new code defers
> : > > the enumeration until events can be processed...
> : >
> : > Yes, you're right. USB1 used the following:
> : >
> : > SYSINIT(usb_cold_explore, SI_SUB_CONFIGURE, SI_ORDER_MIDDLE,
> : >      usb_cold_explore, NULL);
> : >
> : > SI_SUB_CONFIGURE didn't complete before all USB busses
> : > were enumerated.
> : 
> : I would really prefer that first time USB enumeration is not synchronous. This 
> : has to do with startup timing. It simply wastes a lot of time to wait for all 
> : the busses to be probed in serial. Sure it works nice with a USB keyboard and 
> : a USB mouse, but when you have a couple of USB HUBs and +8 devices connected, 
> : it simply speeds up the boot time so that you reach the root prompt by the 
> : time you would else have done the mount root mfs.
> : 
> : If the mountroot code cannot find the disk, it should sleep and loop.
> 
> I think this is a weak argument.  I'm strongly in favor of the usb1
> behavior here.

I think its slightly more complex that adding a cold explore task. 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.


Andrew



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090219050200.GA84647>