incorrect usleep/select delays with HZ > 2500

Luigi Rizzo rizzo at
Thu Sep 10 13:50:46 UTC 2009

On Thu, Sep 10, 2009 at 11:02:19PM +0930, Daniel O'Connor wrote:
> On Thu, 10 Sep 2009, John Baldwin wrote:
> > > $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.
> Can the calculation code disable the SMI# interrupt? Disabling legacy 
> USB could be a problem if you want to use a USB keyboard with the 
> loader (I think).

surely I don't think disabling these interrupts is a viable option.

Perhaps the best we can do in the calibration loop is alternate reads
of the tsc and the i8254 counter (getit()), and if we see too many ticks
between two subsequent calls to getit() it means that we have been
interrupted and should discard the last measurement interval.
Problem is, right now the calibration loop is

	start = rdtsc(); DELAY(1000000); b = rdtsc;

and DELAY is unaware of the existence of the TSC.
We should write some custom DELAY() code to implement the
calibration as above.


More information about the freebsd-stable mailing list