Messages in this thread | | | Date | Mon, 18 May 1998 22:33:49 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: Cyrix 6x86MX and Centaur C6 CPUs in 2.1.102 |
| |
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.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |