On Wed, 21 Jul 1999, Bob_Tracy wrote:
> Sigh... 2.3.11 won't boot on my Cyrix 6x86L/P200+, even with the Cyrix
> coma bugfix code added back in (which was needed to get 2.3.10 to boot).
> Same symptoms as I reported earlier when 2.3.10 wasn't booting: the
> vesafb code switches the video mode (vga = 791), then the machine
> freezes.
>
> I'll do a little poking around to see if I can figure out what changed
> that might affect the boot process, but if anyone has any ideas I'll be
> more than happy to listen.
See if you can find any generated XCHG instruction inside a tight-loop on
the vesafb code. All Cyrix 686 exploits I've seen depend on the XCHG
instruction inside a very tight loop, such that the CPU never gets out of
a locked memory cycle. Look also for instructions with the lock prefix.
Maybe some busy waiting code somewhere? Still is very hard to come up with
useful code that would fit the exploit template...
In any case, this tug-of-war thing with the comma bug is ridiculous. It
seems to be the scape goat for any obscure kernel problem that happens to
be in vogue. Last year it was blamed for X-server crashes, then it turned
out to be a bug in X. Now FS corruption? What's next?
To be fair, there is a known interaction with 3fx cards and the NOLOCK
fix, and I bet it is a race in the glide library (but there's no way of
knowing). Think about it, the NOLOCK prevents locked cycles during XCHG,
descriptor and page table accesses. On an uniprocessor system this
shouldn't make any difference (if it does I would really like to know what
weird device you have plugged in.)
If it's too much of a problem, lets just put the official four-poke magic
from Cyrix instead of the NOLOCK code. Still, I agree with you that the
kernel should look after this, and it's just about 16 bytes worth of init
code.
Cheers,
-Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/