incorrect usleep/select delays with HZ > 2500
rizzo at iet.unipi.it
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