From owner-freebsd-current@FreeBSD.ORG Tue Nov 10 18:16:33 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 0EE2F106566B; Tue, 10 Nov 2009 18:16:33 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5A5488FC15; Tue, 10 Nov 2009 18:16:32 +0000 (UTC) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 1992C55CD85E; Wed, 11 Nov 2009 02:16:31 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id qrLO8Wc0PMMT; Wed, 11 Nov 2009 02:16:25 +0800 (CST) Received: from delta.delphij.net (unknown [206.40.55.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 6382055CD860; Wed, 11 Nov 2009 02:16:22 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=ikFVBFU8wToq4s/7bB9LUequKSgSKhJ73Ul+CTXiIURugyh7f3Rh6jtsLME0BVShb GnlvrZyCVvBqbJyL07B5w== Message-ID: <4AF9ADF4.5040601@delphij.net> Date: Tue, 10 Nov 2009 10:16:20 -0800 From: Xin LI Organization: The Geek China Organization User-Agent: Thunderbird 2.0.0.23 (X11/20091022) MIME-Version: 1.0 To: Hans Petter Selasky References: <20091002150931.K35591@pooker.samsco.org> <30F3E66A-4A69-46CE-96F4-44B4049722E2@samsco.org> <200911050922.10205.hselasky@c2i.net> In-Reply-To: <200911050922.10205.hselasky@c2i.net> X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Marcel Moolenaar , re@FreeBSD.org, Chao Shin , 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 Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 18:16:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hans Petter Selasky wrote: > Hi, > > There is a newer patch in USB P4. > > The problem is when the /usr partition for example is not residing on the root > disk, which is the only disk the code is waiting for. Then the patch will make > the bootup fail. What if we teach rc.d scripts to do something like this: do { mount -a && break; sleep 1; counter++; } while counter < 30? Will this make sense? Or is there any other concerns? > --HPS > > On Thursday 05 November 2009 04:34:33 Chao Shin wrote: >> 在 Sun, 04 Oct 2009 07:52:45 +0800，Scott Long 写道: >> >> 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 separate >>>>> 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" > > _______________________________________________ > 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" - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkr5rfQACgkQi+vbBBjt66CMEgCffmh1MK5RysLrL6vooObZQhUP SyAAn2DNLOofpfkOR3aL6WUSwA+yAlw4 =panI -----END PGP SIGNATURE-----