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

[Garrett D'Amore]

Why not have this be tunable via /etc/system or driver.conf?  I'd also 
argue that you could default this to zero, with a possible default 
override of one second for systems that were "detected" to need it (if 
you can detect such systems.)

Something like this:

static const struct {
    uint16    venid;
    uint16_t devid;
    int          usecs;
} uhci_need_delays[] = {
    { NEC_VID, NEC_DID, 1000000 }
    { 0, 0, 0 }.
};

static int uhci_attach_delay = 0;
...
uhci_attach() {
    ...
    if (uhci_attach_delay == 0) {  /* only if not already in /etc/system */
        for (i = 0; uhci_need_delays[i].venid; i++) {
           if (uhci_need_delays[i].venid == venid && 
uhci_need_delays[i]].devid == devid) {
                 uhci_attach_delay = uhci_need_delays[i].usecs;
                 break;
           }
        }
    }
    ...
    drv_usecwait(uhci_attach_delay);
    ...
}

That gives maximum flexibility, IMO.

    -- Garrett

Jürgen Keil wrote:
>> Is there a business case requirement for saving one second?
>>     
>
> I guess no.
>
> But it saves one second *per* uhci controller.  I think Intel
> ICH8 chipsets now have 5 uhci controllers (for a total of
> ten usb host ports), so tuning uhci attach wait to 0
> would save five seconds of boot time on such a system
> with ICH8 chipset.
>  
>   
>> Since there is an obvious risk there, it is not good
>> to move without clear requirement.
>>     
>
> If there really are systems out there that need the delay,
> they could change it back to the one second delay using
> a line in /etc/system (set uhci:uhci_attach_wait = 1;).
>
>
>   
>>> 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
> _______________________________________________
> laptop-discuss mailing list
> laptop-discuss at opensolaris.org
>