Mike Jagdis wrote:
>
> On Sun, 9 Nov 1997, Andre Derrick Balsa wrote:
...
> > Note that the 6x86 does not stop like the Pentium; it goes into an
> > infinite loop. The Intel part dies, the Cyrix goes into a coma...
>
> That's pipelining for you :-). By the time the first xchg has started
> on the write part of its locked cycle the pipeline has already
> predicted the branch (maybe no the first time but certainly the
> second) and queued the locked read to the memory interface logic.
> Now I suspect that the memory glue ought to force one or more
> idle cycles between two locked accesses but instead it just happily
> steams ahead. With no unlocked time in between there is no chance
> to get an interrupt in anywhere and the only way to stop the
> processor looping is to reset it. I guess someone should tell
> Cyrix so they can fix it _before_ OpenPIC becomes a reality and
> we need locked cycles :-).
Yep. It seems that a strange combination of the 6x86 advanced
architectural features is causing this problem: the CPU never unlocks
the bus, after the xchg instruction locks it.
You are right, it seems the branch prediction logic will (correctly)
predict the second and all following xchg instructions, which get queued
on one pipeline, while probably the mov gets queued on the other
pipeline and possibly accesses an alternate copy of eax. Since the data
does not change I suppose what one would observe using ICE equipment is
a locked read followed by a locked write sequence on the L1 cache, with
not a single idle cycle in between.
The jmp is eliminated by branch prediction and the mov reg,reg by
speculative execution and register renaming.
I guess Cyrix engineers went one (unlocked) cycle too far? ;-)
The effect of NO_LOCK is that it simply eliminates locked cycles on xchg
instructions, and completely eliminates the problem.
BTW I have already sent an email to Cyrix about the solution, and it
seems c't magazine had already contacted them two weeks ago about the
problem. I didn't get an answer yet and I don't know what they told c't.
I don't think they'll correct the bug because of OpenPIC, since Cyrix/NS
is clearly not targeting the SMP market, but anyhow a bug is a Bad Thing
for marketing purposes. IMHO I don't expect to see a revised mask with
this bug gone before the MXi.
>
> > Isn't it a lot simpler to just add a line to an rc.cyrix script?
>
> Yes, but that doesn't fix it for the general Joe User case. Maybe
> a distribution could put it there by default but how many would
> know _why_ it was needed and how many would even notice if
> some wan... er, bast..., er fellow sysop took it out? The kernel
> should be _safe_ as far as possible. It shouldn't rely on external
> operations to make it safe later.
I agree. Shall we end this argument? :-)
>
Cheers,
========================================================
Andrew D. Balsa
Home Page: http://www.tux.org/~balsa
andrewbalsa@usa.net
========================================================