cvs commit: src/sys/i386/isa clock.c

[Bruce Evans]

On Fri, 30 Apr 2004, Nate Lawson wrote:

> On Sat, 1 May 2004, Bruce Evans wrote:
> > The TSC calibration is lower level than the bug fixed in the commit.
> > It just uses DELAY(1000000) without even adjusting for DELAY()'s
> > overhead.  Perhaps acpi is working "better" and throttling the cpu
> > during the calibration, or something is interrupting the calibration.
> > I hope FreeBSD still has interrupts disabled at that point, but there
> > may be SMM interrupts especially with acpi.
>
> Let me try to answer this in Bruce-speak...
>
> The mis-theory that acpi is working at all this early in the boot in terms
> of throttling is incorrect.  It's possible that something is interrupting
> the calibration since an SMI (misspelled as SMM interrupts above) is
> non-maskable.

Oops.  The AMD manual has an index entry for "SMM interrupts", but SMM
is not what causes the interrupts; it is the SMI interrupt that causes
SMM (to be entered).  I mostly meant that acpi might generate SMI's.
acpi might cause SMI's even if it hasn't been run by FreeBSD this early
it is enabled in the BIOS.

> > > I also noticed this today from vmstat -i:
> > >
> > > interrupt                          total       rate
> > > irq0: clk                         746040        986
> > > irq8: rtc                          95484        126
> > >
> > > That should be 1000 & 128, if I'm not mistaken.  Are these all symptoms of
> > > some timing code during boot messing up?
> >
> > Depends on the timecounter.  The vmstat -i times are consistent with
> > using the TSC timecounter after miscalibrating the TSC by a factor of
> > 1556/1575.  Other timecounters don't use boot time calibration by
> > default (i8254) or at all (acpi).
>
> To answer Mike, it should be:
>
> interrupt                          total       rate
> irq0: clk                          46834         99
> irq8: rtc                          59950        127

99 and 127 are normal, but only because of rounding bugs in vmstat(1).
The correct values can be printed accidentally if ntpd is run and
happens to adjust the values enough (from 99.9... to 100.0.., etc.).
My version of vmstat does correct rounding but it also prints the rates
with more precision to give a quick indication of broken clock code.
Errors of larger than 100 ppm here indicate either misconfiguration
or bugs.  Errors of 1.4% (11400 ppm) indicate large bugs.

Bruce