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_at_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_at_freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > > "freebsd-current-unsubscribe_at_freebsd.org"Received on Thu Nov 05 2009 - 07:23:08 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:57 UTC