x86 CPU detection code in 2.1.75 and later kernels

Andre Derrick Balsa (andrewbalsa@usa.net)
Tue, 23 Dec 1997 11:31:19 +0100


Hi,

I have downloaded the 2.1.75 patch just to check the new x86 CPU
detection code and I would like to make a few comments and propose a few
changes:

1) The new code reports all x86 family 5 processors (e.g. Cyrix 6x86 and
AMD K6) as having the f0 bug. We all know that the latest elegant f0 bug
workaround has zero penalty and so is enabled regardless of the
processor (good - this makes kernel code shorter and simpler). But it
looks funny in /proc/cpuinfo and may confuse owners of 6x86 and K6 CPUs.
On the other hand, if I had an Intel Pentium CPU, I'd prefer to get the
bug correctly reported, as well as seeing that the workaround is
enabled.

2) Cyrix 6x86, 6x86L and 6x86MX processor revisions are not reported in
the industry-standard way. Also, the detection code does not distinguish
between the 6x86 and 6x86L. This is very confusing for 6x86 Linux users.

3) The Cyrix and AMD CPU performance options should be implemented in a
user-space program, *not* in the kernel. The only options that should go
in the kernel are those that enable features needed for correct
operation (e.g. CPUID on 6x86(L) processors). Note that these
"performance" options have _no_ measurable impact on performance
(benchmarking data available to support this statement).

4) These CPU performance options are included in the configuration
procedure, but not implemented in the kernel code (?).

5) time.c has _not_ been updated to workaround the possible oops with
6x86MX. Also, code in time.c gets compiled that is never run on 386, 486
K5 and 6x86 Linux boxes (do_fast_gettimeoffset).

6) The Cyrix documentation file should be updated. It should at the very
least mention the Cyrix "coma" bug and the available workaround, and
also the new 6x86MX processor changes.

7) VSPM is still mentionned concerning 6x86 CPUs, even though it is more
an experimental feature than something that could go in 2.2.x
"production" kernels.

8) The AMD K6 bug in early CPUs is not detected or reported, even though
the necessary code for this detection has been sent to the list (by
Benoit Poulot).

Proposed changes
================

Given these, I would like to propose a new, simpler, shorter
architecture for x86 CPU detection code in 2.1.76 and later kernels.

It's really a dumb algorithm that goes like this:

Read so-and-so CPU register

switch
case value 1: CPU is something; if (something is needed for
correct kernel operation) then {enable it}; break
case value 2: CPU is something else; if etc...
etc...
end /* switch */

Adding new x86 processors would be easy, whereas right now it seems
intricate at first glance.

I would also modify set6x86 (a user-space package to set Cyrix CPU
options, written by Koen Gadeyne) so that it allows setting the AMD K5
and K6 allocate-on-write cache options.

I will be working on this code for the coming week, but I cannot
guarantee that I will meet any short deadline. At least a week for the
kernel code changes and the new setx86 utility are needed for bugfree,
tested code. If anybody wants to help, it will be appreciated and
credits will be duly reported.

Cheers,
========================================================
André D. Balsa <andrewbalsa@usa.net>
Home Page: http://www.tux.org/~balsa
========================================================