Re: Cyrix 6x86MX and Centaur C6 CPUs in 2.1.102

Linus Torvalds (
Mon, 18 May 1998 22:33:49 -0700 (PDT)

On Tue, 19 May 1998, Phil's Kernel Account wrote:
> # ...
> #and that's it. Look at how 2.1.102 handles this: the cyrix-specific
> #setup code will zero out the TSC bit from the capability mask, because
> #Cyrix in essense does not _have_ a TSC that is correct.
> Well, I am looking at things here on 2.1.98, so I will DEFINITELY give
> you the different handling. I'll have to grab 2.1.102 sometime
> tonight. However, it's STILL wrong, IMO.

Well, consider it this way: I think it is conceptually just completely
wrong to have a "capability" word, and then despite having a capability
word have something horrible like this:

> if ((boot_cpu_data.x86_capability & 16) && (boot_cpu_data.x86_vendor ==
> X86_VENDOR_CYRIX (boot_cpu_data.x86_model != [5x86Model])) &&
> (boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR
> (boot_cpu_data.x86_stepping == 0))) {

That kind of throws away the whole _point_ of using the capability word in
the first place.

If you want to distinguish between
- has no cycle counter
- has a broken cycle counter
- has a cycle counter that works as documented

then that part I have no argument with. HOWEVER, if so, you'd better make
it a new capability or something, because I don't want to have "real"
kernel code having to care. This is something that is very CPU dependent
(and even stepping-dependent), and I don't want to have code all around
the kernel checking for the "random stepping of the day bug".

Let's get this straight: I don't have anything against fixing problems
with buggy CPU's, but workarounds for ugly problems have to at least be
done right.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to