<...>
> You might have thought of this already (in fact, ISTR Alan Cox posted
> something like this when the problem was first detected), but the
> following
> should work:
> * check 386, 486 as usual
> * check CPUID, if not present, <= 486, NexGen, or 6x86 (non-L) with
CPUID
disabled (or rather, not yet enabled :-)
> * use CPUID to determine which type of CPU is really present
> * if and only if Intel Pentium II or later, check for BX
Actually, there is a patch for this already, both for 2.1.103+ and
2.0.33+. I recently posted the 2.1.103+ version, but from the feedback I
got (hush... none), it seems either its not a priority right now with all
the push to get 2.1 stable and ready for 2.2, or I seriously screw-up and
I'm being ignored ;-)
If interested, the patch can be gotten from,
http://www.ececs.uc.edu/~rreilova/Linux-Cx/head.S-patch.gz
It does (almost) the same algorithm above. I didn't follow the advice
under the CYRIX_CODE_BREAKAGE comment to move the code to bugs.h, b/c by
that time the udelay calibration has been done and the C6x86(L) will be
stuck with incorrect BogoMIPS. If we go as far as detecting for a C6x86,
then might as well do the rest in head.S.
> I also STR reading somewhere than IDT WinChips can have various
manufacturer
> ID's... But that shouldn't affect the Cyrix/Pentium II w/ BX detection.
Can you still find a link to that info? Currently the code only checks
for the CyrixInstead string (actually just for "Cyri"), if these chips
also need the cpuid to be enabled, or use the Cyrix devid method of
idetifying steps/revisions then they will not get identified correctly
(though it should be safe for PII-BX).
Cheers,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu