Messages in this thread | | | Date | Mon, 10 Nov 1997 16:50:22 +0100 | From | Andre Derrick Balsa <> | Subject | Re: Pentium DEATH and Cyrix COMA in user-mode |
| |
Hi Mike,
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 ========================================================
| |