incorrect usleep/select delays with HZ > 2500

[John Baldwin]

On Wednesday 09 September 2009 4:32:16 pm Luigi Rizzo wrote:
> On Wed, Sep 09, 2009 at 01:24:53PM -0400, John Baldwin wrote:
> > 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.
> ...
> > > > 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.
> 
> ok makes sense -- if the SMI interrupts last longer than 1/HZ
> they will cause us to miss one or more wraps of the i8254 in
> $ARCH/isa/clock.c::DELAY(). I suppose with a few measurements
> at different HZ values and some back of the envelope calculations
> one could even determine estimate the frequency and duration
> of those SMI interrupts!

On recent motherboards I have seen the SMI# interrupt fire every 250 ms with 
execution times ranging from 50 us to 1ms for the legacy USB interrupt 
handler.  We consistently see the TSC frequency miscalculated on the 
motherboards with the 1ms duration interrupt.  I suspect that the clock that 
drives the periodic SMI# interrupt is tied to the i8254 meaning that it often 
fires at the same time that the i8254 wraps causing the TSC frequency to 
often be wrong.

-- 
John Baldwin