Messages in this thread | | | From | Andrew Derrick Balsa <> | Subject | Re: [PATCH] 2.0.35: updated Jumbo -4 patch | Date | 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
| |