Re: [PATCH] 2.0.35: updated Jumbo -4 patch

Andrew Derrick Balsa (andrebalsa@altern.org)
Mon, 20 Jul 1998 16:35:41 +0200


Hi Andreas,

On Mon, 20 Jul 1998, Andreas U. Trottmann wrote:
....
>... this new kernel boots (and seems to work) fine on the iP and the
>TTillamook that caused the problems before. It doesn't seem to break
>anything as well, since a so-patched kernel still runs fine on the Cyrix
>6x86L. I also tested it on a i486SX where everything seems to work fine as
>well.

Great :-) Thanks a lot for the testing, too :-)
>
>The iP and the Tillamook get their clock frequency detected (in the case
>of the iP, /proc/cpuinfo says 120.00 +- 0.01 MHz, which is totally correct,
>whereas the Tillamook is detected to run at 265267154 Hz = 265.26 +- 0.01
>MHz... did they cheat me when they sold me a Tillamook 266? :-) )

No, don't worry, the CPU clock in most cases is not an exact frequency, due to
the oscillator/PLL specs. Sometimes the TSC calibration code reads a higher than
nominal frequency, sometimes slightly below.

I have never actually taken a frequency reading with a frequency meter
and compared to the calculated value, so it is possible that the calibration
code is introducing a constant error. However, the iP 120.00 MHz reading seems
to indicate this is not the case. In fact, I am pretty sure the calibration
code is accurate to within +/- 0.01% or better.

Also you will notice the calibration is very stable WRT time: I always get the
same numbers +/- a dozen Hz every time I turn on my Linux box.

This is why I wrote that the new TSC calibration code is jitter and drift free
(by design, not by accident; the empirical data just confirms this).

>
>The 6x86L and the i486SX don't display the clock frequency, but I think
>this is caused because they don't have (correctly working) TSCs.

Correct; neither the 486-class CPUs not the 6x86(L) have a TSC. Hence the code
does not try to display a MHz reading for these CPUs.

We could do it using the timing of specific loops, but this would have a cost in
terms of additional code (and hence kernel memory footprint) which is
unacceptable. The MHz reporting in fact comes for free as a consequence of the
new TSC calibration code.

>So, thanks a lot for the work you put into this and for your fast response!

Thanks to you for your patience to test it :-)

BTW rev -5 is in the works, with improved reporting for the Intel CPUs, AMD K6
bug detection (courtesy of Rob Dale who ported the code from 2.1.x), the Intel
Pentium fix above and some other goodies.

I am pretty confident -5 will be the _best_ x86 CPU detection code available on
_any_ OS. :-)

Cheers,
---------------------
Andrew D. Balsa
andrebalsa@altern.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html