incorrect usleep/select delays with HZ > 2500

[John Baldwin]

On Tuesday 08 September 2009 5:01:00 pm Luigi Rizzo wrote:
> On Tue, Sep 08, 2009 at 01:08:23PM -0400, John Baldwin wrote:
> > On Sunday 06 September 2009 11:51:54 am Luigi Rizzo wrote:
> > > [Note 3] the TSC frequency is computed reading the tsc around a
> > >         call to DELAY(1000000) and assuming that the i8254 runs
> > >         at the nominal rate, 1.193182 MHz.
> > >         From tests I have made, the measurement in init_TSC() returns
> > >         a large error when HZ is large, whereas repeating the 
measurement
> > >         at a later time returns a much more reliable value.
> > >         As an example, see the following:
> > > 
> > >     Sep  6 14:21:59 lr kernel: TSC clock: at init_TSC 2323045616 Hz
> > >     Sep  6 14:21:59 lr kernel: 
> > 
Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
> > >     Sep  6 14:21:59 lr kernel: AMD 
> > Features=0xea500800<SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow!>
> > >     Sep  6 14:21:59 lr kernel: TSC: P-state invariant
> > >     Sep  6 14:21:59 lr kernel: TSC clock: at cpu_startup_end 2323056910 
Hz
> > >     Sep  6 14:21:59 lr kernel: TSC clock: at acpi_timer_probe 2311254060 
Hz
> > >     Sep  6 14:21:59 lr kernel: TSC clock: at acpi_timer_probe_2 
2311191310 
> > Hz
> > >     Sep  6 14:21:59 lr kernel: TSC clock: at pn_probe_start 2300822648 
Hz
> > >     Sep  6 14:21:59 lr kernel: TSC clock: at pn_attach_start 2300830946 
Hz
> > >     Sep  6 14:21:59 lr kernel: TSC clock: at pn_probe_start 2300840133 
Hz
> > >     Sep  6 14:21:59 lr kernel: TSC clock: at pn_attach_start 2300835253 
Hz
> > >     Sep  6 14:21:59 lr kernel: TSC clock: at lapic_setup_clock 
2300868376 Hz
> > > 
> > >         The latter values are close to what is reported when HZ=1000.
> > 
> > Try disabling legacy USB support in the BIOS to see if an SMI# is firing 
> > during the DELAY() causing the TSC freq to be too high.  I have seen the 
USB 
> > legacy support cause this in other machines.
> 
> Thanks, will try tomorrow.
> Would this explain the measurement becomes better as we get
> further into the initialization, and why high HZ values affect
> the measurement ?

It would explain why it gets better later since the uhci(4), ohci(4) and 
ehci(4) drivers disable the SMI# interrupts while attaching to the 
controllers.

-- 
John Baldwin