[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FW: Delayed Xaction and LOCK#
- To: Mailing List Recipients <pci-sig-request@znyx.com>
- Subject: Re: FW: Delayed Xaction and LOCK#
- From: ghickey@cyclone.com (Geoff Hickey)
- Date: Wed, 28 Aug 96 15:07:33 EDT
- Resent-Date: Wed, 28 Aug 96 15:07:33 EDT
- Resent-From: pci-sig-request@znyx.com
- Resent-Message-Id: <"-enjx3.0.el2.UKV9o"@dart>
- Resent-Sender: pci-sig-request@znyx.com
>> > > >> use of LOCK# should be avoided if at all possible.
>>
>> ....<snip>....
>>
>> What about the opposite situation? Perhaps, a card which is NOT a bus
>> master, only a target, that has structures in its own memory that are used
>> to communicate between the host and the local processor. If the host needs
>> to update these structures, it needs to do a locked exchange of the mutex
>> semaphore before proceeding... If in fact, the cpu lock prefix doesn't
>> actually lock the PCI bus between the read and write, this method is not
>> safe....
>
>On a PC with an Intel chipset, I'm sure this will work, since Intel
>chipsets do implement LOCK#. But, the lock prefix is specific to the x86
>architecture. If you are designing a card of the type described above and
I think you are correct for Intel's Pentium chipsets, but a year or so ago I was looking into this same question, and found that Intel's 486 chipsets do not propagate a local bus LOCK# onto the PCI bus, nor a PCI LOCK# onto the local bus. Since no one seems to be using PCI LOCK# at present, I'd be hesitant to depend on its implementation. Does anyone know how Pentium and Pentium Pro chipsets handle it?
--> Geoff Hickey
Cyclone Microsystems
¨ L <