incorrect usleep/select delays with HZ > 2500
rizzo at iet.unipi.it
Wed Sep 9 20:26:18 UTC 2009
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
> > > > 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
> > > 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
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!
More information about the freebsd-stable