-----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 <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" > > _______________________________________________ > 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" - -- Xin LI <delphij_at_delphij.net> 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-----Received on Tue Nov 10 2009 - 17:16:33 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:57 UTC