Date: Thu, 5 Nov 2009 09:22:09 +0100 From: Hans Petter Selasky <hselasky@c2i.net> To: "Chao Shin" <quakelee@geekcn.org> Cc: Marcel Moolenaar <xcllnt@mac.com>, freebsd-current@freebsd.org Subject: Re: [PATCH] Fix for USB media not found at boot Message-ID: <200911050922.10205.hselasky@c2i.net> In-Reply-To: <op.u2wj7poohnq548@qld630> References: <20091002150931.K35591@pooker.samsco.org> <30F3E66A-4A69-46CE-96F4-44B4049722E2@samsco.org> <op.u2wj7poohnq548@qld630>
index | next in thread | previous in thread | raw e-mail
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.
--HPS
On Thursday 05 November 2009 04:34:33 Chao Shin wrote:
> 在 Sun, 04 Oct 2009 07:52:45 +0800，Scott Long <scottl@samsco.org> 写道:
>
> 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"
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200911050922.10205.hselasky>