[laptop-discuss] Re: Re: Making Solaris Boot Faster

[Jürgen Keil]

Garrett wrote:

> Jürgen Keil wrote:
> >> Does anyone know of any discussions about processes
> >> that can be safely svcadm-disabled so as to allow
> >> Solaris boot faster in a laptop?
> >>     
> >
> > Not an smf service, but if you have an S-x86 box with lots
> > of uhci USB 1.x host controller devices (e.g. Intel ICH
> > chipset), you can try to change the uhci_attach_wait
> > tunable to 0; should save one second of boot time per
> > uhci controller:
> >
> >
> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/usb/hcd/uhci/uhci.c#118
> >
> > Add this to /etc/system and reboot:
> >
> >   set uhci:uhci_attach_wait = 0
>
> I haven't looked at this, but why can't this attach
> logic be parallelized?

The USB host controller drivers are loaded early during 
kernel boot time, partly because of "ddi-forceattach=1;" 
properties in the /kernel/drv/?hci.conf files.

forceattach is done from the kernel's main() function:

http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/os/main.c#471

    471 	/*
    472 	 * attach drivers with ddi-forceattach prop
    473 	 * This must be done after consconfig() to prevent usb key/mouse
    474 	 * from attaching before the upper console stream is plumbed.
    475 	 * It must be done early enough to load hotplug drivers (e.g.
    476 	 * pcmcia nexus) so that devices enumerated via hotplug is
    477 	 * available before I/O subsystem is fully initialized.
    478 	 */
    479 	i_ddi_forceattach_drivers();


And i_ddi_forceattach_drivers() calls uhci`uhci_attach() via a
ddi_hold_installed_driver(ddi_name_to_major("uhci"))  call:

/*
 * Launch a thread to force attach drivers. This avoids penalty on boot time.
 */
void
i_ddi_forceattach_drivers()
{
        /*
         * On i386, the USB drivers need to load and take over from the
         * SMM BIOS drivers ASAP after consconfig(), so make sure they
         * get loaded right here rather than letting the thread do it.
         *
         * The order here is important.  EHCI must be loaded first, as
         * we have observed many systems on which hangs occur if the
         * {U,O}HCI companion controllers take over control from the BIOS
         * before EHCI does.  These hangs are also caused by BIOSes leaving
         * interrupt-on-port-change enabled in the ehci controller, so that
         * when uhci/ohci reset themselves, it induces a port change on
         * the ehci companion controller.  Since there's no interrupt handler
         * installed at the time, the moment that interrupt is unmasked, an
         * interrupt storm will occur.  All this is averted when ehci is
         * loaded first.  And now you know..... the REST of the story.
         *
         * Regardless of platform, ehci needs to initialize first to avoid
         * unnecessary connects and disconnects on the companion controller
         * when ehci sets up the routing.
         */
        (void) ddi_hold_installed_driver(ddi_name_to_major("ehci"));
        (void) ddi_hold_installed_driver(ddi_name_to_major("uhci"));   <<<<<<<<<<<<<<<<
        (void) ddi_hold_installed_driver(ddi_name_to_major("ohci"));

        ....


So the one second delay in uhci_attach happens in the context of the
kernel's main() startup function.


The one second uhci attach wait appears to be a workaround for some
unspecified NCR system:

#ifndef __sparc
        /*
         * On NCR system,  the driver seen  failure of some commands
         * while booting. This delay mysteriously solved the problem.
         */
        delay(drv_usectohz(uhci_attach_wait*1000000));
#endif


It wouldn't surprise me if one of more of the following applies:

- that NCR system is unable to run modern Solaris x86 releases
  (in that case: why does Nevada still need the workaround?)

- lots of changes in the Solaris USB drivers in the last couple of years
  have made the uhci/NCR workaround obsolete



Maybe Nevada should just change the default uhci_attach_wait to 
0 seconds (instead of one second), and see if we get any bug reports
on broken S-x86 nevada uhci support?
 
 
This message posted from opensolaris.org