I am still trying to find the best solution to the new Cyrix bug.
Richard, this would perhaps provide a solution to the Pentium F0 bug
too. Is there any (documented or undocumented) way to enable some sort
of Weak Locking on Pentiums?
Alan Cox wrote:
>
> > On the other hand there could be a problem with PCI memory mapped I/O
> > devices, like some video chips (the Matrox chips use memory-mapped I/O,
> > as well as the ET6000). :-(
>
> If I remember correctly the LOCK prefix has no mapping onto the PCI bus
> but I may be wrong there. I know a LOCK opcode on SMP kernels locks the other CPU off
> the bus but not AFAIK by propagating lock to the PCI bus. I'd have
> to read the spec again to be sure
This is what the Cyrix 6x86 data sheet says (valid for entire 6x86
family):
"Typically, XCHG instructions, instructions preceded by the LOCK prefix
and descriptor table accesses are locked cycles. Setting Weak Locking
allows the data for these accesses to be cached."
I can add that caching will be write-back caching either at the L1 cache
level (CPU internal) or at the L2 level (motherboard chipset level).
Also, if Weak Locking is set, other CPU bus masters will be allowed
access, but as you mention above, this would only matter for SMP, and
since the 6x86 does not implement SMP I guess we don't have to worry
about this.
Now how about the descriptor tables? Could Weak Locking on descriptor
tables cause a problem for Linux kernels? In what parts does the Linux
kernel use instructions prefixed with LOCK (apart from SMP)?
Richard Johnson has already determined that libc does not use the LOCK
instruction, so the only cause of a problem with enabling Weak Locking
could be the kernel or a specific driver (e.g. an XFree video driver).
Thanks for your feedback,
========================================================
Andrew D. Balsa
Home Page: http://www.tux.org/~balsa
andrewbalsa@usa.net
========================================================