Mike Jagdis wrote:
>
> that weak locking really does expose the locked cycle on the bus
> and doesn't do away with it altogether. As I understood it weak
> locking is for the case where the data will not be changed by
> another device without a locked cycle and the cache knows to
> flush on a seeing a locked cycle. Whereas NO_LOCK means, "Who
> gives a toss anyway..."
I tested it and I confirm your reasoning: setting weak locking on main
memory using ARR7 does *not* avoid the xchg infinite locking bug. Kudos
to you :-)
Only NO_LOCK does the trick here.
>
> > Now how about the descriptor tables? Could Weak Locking on descriptor
> > tables cause a problem for Linux kernels?
>
> No, other than on SMP, because only the CPU cares about them
> anyway so if they are cached that's fine. That does bring up
> another problem though. I don't know about weak locking but
> NO_LOCK applies _only_ to explicit locks. Page table accesses
> always occur as locked cycles I think, in which case it _may_
> be possible to freeze out the system by doing a tight loop
> over an invalidate for the current page and thereby causing
> the MMU to generate a locked cycle to reload it?
Could be... but that's not possible in user space, is it? :-)
I am more concerned with SCSI and video chips with memory mapped i/o
registers. Alan was going to check whether the lock would propagate to
the PCI bus devices; if it does and if somebody used an xchg instruction
against such a register, we could have an occasional glitch if using
NO_LOCK, I think.
Could anybody test the NO_LOCK workaround on a system with this kind of
video board?
(ET6000, Matrox Mystique, Matrox Millenium AFAIK)
Cheers,
========================================================
Andrew D. Balsa
Home Page: http://www.tux.org/~balsa
andrewbalsa@usa.net
========================================================