> The new workaround actually depends on the Intel bug not only forgetting
> to clear the "lock" state of the instruction, it also forgets to clear the
> fact that the instruction tries to do a read-modify-write cycle. So it
> will not only do the IDT access as a locked cycle, it will do it as a
> locked cycle that requires write permissions..
Well, of course! My old 486 manual says (about CMPXCHG):
"In order to simplify interface to the procssor's bus, the destination
operand receives a write cycle without regard to the result of the
comparison. DEST is written back if the comparison fails, and SRC
is written into the destination otherwise. (The processor never
produces a locked read without producing a locked write.)"
So LOCK always implies read-lock-modify, at least if the above () is
valid for the Pentium also.
Morten