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
