From owner-freebsd-current@FreeBSD.ORG Thu Nov 5 08:23:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9F38106566C for ; Thu, 5 Nov 2009 08:23:07 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe15.swip.net [212.247.155.193]) by mx1.freebsd.org (Postfix) with ESMTP id 4F6FD8FC19 for ; Thu, 5 Nov 2009 08:23:06 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=aQey1_VUwUUA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=-o65W9qwAAAA:8 a=6I5d2MoRAAAA:8 a=OwP0SP-sF6umdFmdu08A:9 a=4feMDSS3fg_F5bqao2wA:7 a=fQuIEd6tWuuh7cEHHVSJtwLauOoA:4 a=HRJsq0TPXRMA:10 a=SV7veod9ZcQA:10 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe15.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 587155258; Thu, 05 Nov 2009 09:23:05 +0100 From: Hans Petter Selasky To: "Chao Shin" Date: Thu, 5 Nov 2009 09:22:09 +0100 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <20091002150931.K35591@pooker.samsco.org> <30F3E66A-4A69-46CE-96F4-44B4049722E2@samsco.org> In-Reply-To: X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpO< =?utf-8?q?Q0yAl=7E=3F=60=27F=3FjDVb=5DE6TQ7=27=23h-VlLs=7Dk/=0A=09?=(yxg(p!IL.`#ng"%`BMrham7%UK,}VH\wUOm=^>wEEQ+KWt[{J#x6ow~JO:,zwp.(t; @ =?utf-8?q?Aq=0A=09=3A4=3A=26nFCgDb8=5B3oIeTb=5E=27?=",; u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200911050922.10205.hselasky@c2i.net> Cc: Marcel Moolenaar , freebsd-current@freebsd.org Subject: Re: [PATCH] Fix for USB media not found at boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 08:23:08 -0000 Hi, There is a newer patch in USB P4. The problem is when the /usr partition for example is not residing on the r= oot=20 disk, which is the only disk the code is waiting for. Then the patch will m= ake=20 the bootup fail. =2D-HPS On Thursday 05 November 2009 04:34:33 Chao Shin wrote: > =E5=9C=A8 Sun, 04 Oct 2009 07:52:45 +0800=EF=BC=8CScott Long =E5=86=99=E9=81=93: > > Hi all > > Is there any newer patch/workarounds available? > > > On Oct 3, 2009, at 12:51 PM, Marcel Moolenaar wrote: > >> On Oct 3, 2009, at 9:00 AM, Hans Petter Selasky wrote: > >>> On Saturday 03 October 2009 17:05:35 Scott Long wrote: > >>>> On Oct 3, 2009, at 4:30 AM, Hans Petter Selasky wrote: > >>>>> On Saturday 03 October 2009 10:19:57 Scott Long wrote: > >>>>>> config_intrhook system will sleep after all > >>>>> > >>>>> Then why do you need the intr hook callback? > >>>> > >>>> The config_intrhook lets you know that interrupts are enabled, the > >>>> scheduler is running, and mountroot hasn't run yet. It provides a > >>>> very convenient and standard way to do exactly what we want with USB > >>>> enumeration. > >>> > >>> Hi, > >>> > >>> The root HUB attach and explore code is already running from a separa= te > >>> thread, so won't that be superfluous? I mean, the HUB explore code for > >>> any USB > >>> HUB will not run until the scheduler is running anyway. > >>> > >>> In my opinion delaying the system until the boot disk is present is > >>> just not > >>> good. We should rather be event driven, so that every time a new disk > >>> becomes > >>> present it checks it for mountroot. > >>> > >>> while (1) { > >>> if (mountroot is successful) > >>> break; > >>> if (ctrl+c is pressed) > >>> manual_mountroot(); > >>> printf("Waiting 1 second for root-disk to appear. Press CTRL+C to > >>> abort.\n"); > >>> sleep(1); > >>> } > >> > >> Yes. > >> > >> The mount root code should keep a list of potential root devices to try > >> and > >> it should try a device as soon as it appears. The current approach to > >> block > >> the root mount simply because we want everything to be discovered > >> before we > >> try to mount the root is preventing fast boots -- such as when the root > >> is > >> a memory disk and you don't need to wait for anything... > >> > >> Put differently: it's rather odd to hold off the root mount when the > >> root > >> device is already present... > >> > >> An approach like this also allows one to indefinitely wait for the root > >> device, which is a good feature to have... > > > > When /etc/rc tries to mount everything in the fstab, it'll fail the boot > > if some of the devices haven't arrived in time. An argument can be made > > for fixing that as well, but we're starting to get beyond on the scope > > of fixing what is needed for 8.0-RELEASE. > > > > Scott > > > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > > "freebsd-current-unsubscribe@freebsd.org"