I guess the dust is settling down on this issue, so I would just like to
point a few facts so that the kernel code can get adequately patched for
2.1.103 or later.
a) Trevor, I think you are doing a great job. :)
b) Phil, I am sorry, but *ALL* the 6x86MX have a stoppable TSC. This
feature is _not_ just for stepping 0.3 or whatever. If it's a 6x86MX
(any stepping), the tsc will stop counting when halted, _if_ the
Suspend-on-Halt feature is enabled (it is disabled by default after a
reset on all Cyrix CPUs).
I have three rev 1.6 6x86MX based Linux machines, and they behave
_exactly_ the same as the 1.3 parts in this respect: a random oops in
do_fast_gettimeoffset() in time.c, if the kernel is not patched.
c) The code that shows Cyrix CPU steppings does not conform to Cyrix
stepping numbering. 6x86MX steppings are documented as 1.3, 1.4, 1.5,
1.6, etc... in both the Cyrix/NS and IBM documentation, _not_ 0.3, 0.4,
0.5, 0.6 as the present Linux kernel code would have it.
A similar mistake is done for K6 steppings, which in the AMD
documentation are described as steppings A, B, C.
This causes confusion with users that do "cat /proc/cpuinfo" and can't
figure out what CPU stepping they have. So I wish you could get it
right.
d) Also bug reporting in /proc/cpuinfo. Everytime I see reported that my
6x86(L,MX) or K6 machines don't have the F00F bug, I wonder what use is
there to report a bug that simply is _not_ there and couldn't be. This
also confuses most Linux users.
e) Another thing that I would like to see was recently suggested by
Vojtech Pavlik :
Could we have a single calibration of the TSC done at boot time? For
some reason I cannot understand, the TSC gets re-calibrated 100
times/second in time.c !?!?! If there is a real need for this frequent
recalibration, perhaps we could have the value exported so other CPU
drivers can make use of it?
f) One final thing: Phil, I agree with you 100% when you write that
Linux should equally support all x86 CPU, not just those from Intel or
another CPU vendor. In ethical terms, this is the correct stance.
I am available to help implement any of the above suggestions. Please
write to me directly since I am not on this kernel list.
Cheers,
------------------------
André 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