Re: Cyrix detection in bugs.h [PATCH]

Andrew Derrick Balsa (andrebalsa@altern.org)
Sun, 14 Jun 1998 14:28:19 -0100


Hi,

Rafael R. Reilova wrote:
>
> Hi Alan, Andre,
>
> The included patch restores the original behavior to 2.1.10[345] before
> the PII-BX gave us the CYRIX_CODE_BREAKAGE. No fancy stuff, just moves
> everything from head.S to bugs.h and tries to C'ify it.
>
> Changes: moves check_bugs() to just before calibrate_delay(), in order to
> be able to fix the problem with the Cx686(L) and BogoMIPS. (Hopefully
> this doesn't break other architectures, but is the only way out IMHO).
>
> adds the following functions to bugs.h:
> check_cyrix_cpuid() - to detect cyrixes without cpuid or with
> cpuid off by default (and enable it).
> check_cyrix_devid() - to use the DIR0/1 registers if available.
> check_Cx686_SLOP() - to fix the problem with udelay calibration on the
> 686(L)
> an assorted set of inline fuctions to handle all that asm in a
> pseudo-clean way. ;)
>
> Does it look better now? I can only test on a very limited number of
> machines so please check I didn't miss something.

Hmmm Rafael, the patch looks good to me, but there are some small
mistakes; for example, you forgot to enable MAPEN before trying to reset
the SLOP bit, so in fact function check_Cx686_SLOP() will not work at
all and may even cause a stray I/O cycle to go to the bus :(

But moving everything to bugs.h is the Right Thing (tm), and that was
the hardest part, in fact. Thanks for doing all the hard word work, I'll
take care of the tidbits and get all the glory ;)

So, Cyrix 6x86 Linux users: please hold on a little bit more, you'll get
a correct patch for kernels 2.1.10x next week when Rafael comes back
from his trip.

Meanwhile I will be porting a revised version of his patch to 2.0.34, so
Alan can get this into 2.0.35pre_something. I hope to get the details
right.

Regards,
------------------------
André Balsa
andrebalsa@altern.org

BTW I just got hold of a Cyrix MII chip. Right now I am using it to
write this email, clocked at 3x83.3 MHz. This CPU does _not_ have the
Coma Bug, unlike the previous 6x86MX. More details soon on a dedicated
Web page.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu