cvs commit: src/sys/i386/isa clock.c
Nate Lawson
nate at root.org
Fri Apr 30 23:55:24 PDT 2004
On Sat, 1 May 2004, Bruce Evans wrote:
> On Fri, 30 Apr 2004, Mike Silbersack wrote:
>
> > Hm, I just learned something interesting about my clock issue... good
> > thing that I was saving dmesgs for warner:
> >
> > Nov 13, 2003:
> > CPU: Mobile Intel(R) Celeron(R) CPU 1.60GHz (1594.98-MHz 686-class CPU)
> >
> > Apr 10, 2004, with ACPI:
> > CPU: Mobile Intel(R) Celeron(R) CPU 1.60GHz (1556.71-MHz 686-class CPU)
> >
> > Apr 10, 2004, without ACPI:
> > CPU: Mobile Intel(R) Celeron(R) CPU 1.60GHz (1575.84-MHz 686-class CPU)
> >
> > today, without ACPI:
> > CPU: Mobile Intel(R) Celeron(R) CPU 1.60GHz (1575.84-MHz 686-class CPU)
>
> 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.
:)
> > 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
-Nate
More information about the cvs-src
mailing list