> 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.
Already fixed in a patch sent to this list approx. 3 hour ago.
> 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.
It seemed a bit inappropriate to me to implement a rather complex conversion
routine for stepping numbers. The 6x86L detection should be in (see
the cyrix_model function in arch/i386/kernel/setup.c). If you have any
improvements, feel free to send them to me.
> 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).
There are _NO_ performance options in the 2.1.75 kernel. You probably
missed that the patch actually _deletes_ them from the configuration help.
> 4) These CPU performance options are included in the configuration
> procedure, but not implemented in the kernel code (?).
They are neither included in config nor implemented.
> 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).
It has _not_ been updated, because I don't have a good solution for
the problem. Your solution based on _disabling_ gettimeoffset_fast
is a work-around, not a solution.
> 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.
The old Cyrix doc file has been removed. Feel free to write your own
and send it to me.
> 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.
I don't see any references to VSPM in the 2.1.75 kernel.
> 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).
Which bug do you mean?
> 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.
The current detection code actually works in this way, but it calculates
some additional parameters first (vendor number etc.) to make the rest
more straightforward (i.e., doing a simple comparison of numbers instead
of comparing strings).
> 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.
Yes, it's a good idea. Maybe rename it to "setcpu" then...
> 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.
Again, if you have any suggestions about what to improve and any
patches, I'm looking forward to see them.
Have a nice fortnight
-- Martin `MJ' Mares <mj@gts.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "Anyone can build a fast CPU. The trick is to build a fast system." -- S. Cray