Re: PCI #LOCK assertion

H. Peter Anvin
2002-01-27T21:18:31Z

Followup to: <Pine.LNX.3.95.1020125132236.1362A-100000@chaos.analogic.com>
By author: "Richard B. Johnson" <root@chaos.analogic.com>
In newsgroup: linux.dev.kernel
>
> On Intel machines, you precede a memory access with the 'lock'
> instruction. With CPUs i486, and later, only the accessed page
> is locked at that instant. Earlier CPUs locked the whole bus.
>
> The PCI/Bus controller handles the #LOCK signal itself to guarantee
> the atomicity of a transaction. You should never have to do this
> yourself. If you think you have to, just precede each PCI/Bus
> address-space access with the 'lock' instruction. You just make
> your own version of the readl/readw/readb/etc macros that are
> provided. You may find that this deadlocks, though, and all bets
> are off. You may have just locked the PCI/Bus off the bus when
> you needed it most!!
>

LOCK on readl/readw/etc is meaningless (might even be an error). The
*only* case when the lock matters is when transferring
read/modify/write transactions such as "inc", "add", "xchg" (the
latter locks automatically.)

In practice, LOCK# on the PCI bus is so poorly supported that you
can't rely on it anyway (and it causes deadlocks.) A number of
motherboards have been known not even to wire it up. LOCK is still
needed for SMP coherency, however.

-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com>