incorrect usleep/select delays with HZ > 2500

Luigi Rizzo rizzo at
Wed Sep 9 21:05:26 UTC 2009

On Wed, Sep 09, 2009 at 04:42:05PM -0400, John Baldwin wrote:
> > > 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.

when or even how often it fires should not matter much -- as long
as the interrupt is shorter than 1 tick we will be able to see the
wrap and handle it correctly. I'll try to write a 1-sec loop around
rdtsc() and log large differences in the reads to figure out
whether i am getting some long interrupts.


More information about the freebsd-stable mailing list