Re: Delayed Xaction and LOCK#

["Monish Shah" <monish@mcsy2.fc.hp.com>]

On Aug 26, 12:37pm, Devendra K Tripathi wrote:
> Subject: Delayed Xaction and LOCK#
> Hi all,
>
> There is possibility of deadlock, the way specification for delayed xaction
> for exclusive accesses has been specified (PCI2.1 PP 52).  It says that
> target needs to compare (latched) LOCK# signal to find if request is being
> repeated.  On the other hand there is no requirement for initiator (PCI 2.1
> PP 76) that it must retry an exclusive access as exculsive access only.

I don't see how you came to that conclusion.  On page 51, the last
paragraph of 3.3.3.3.2 does say "The master must repeat the transaction
exactly as the original request...".  That should include LOCK# as well.  I
don't think there is anything on page 76 that contradicts that.  (Yes, you
are required to release LOCK# if the transaction is retried, but when you
attempt it again, you'd have to assert LOCK#.)

BTW, I don't think it is possible to do locked transactions as delayed
transactions.  So, matching LOCK# merely makes it so that a locked
transaction doesn't get serviced with a completion from a previous delayed
transaction to the same address, which might have come from a different
agent.  Is it important to protect against that case?  May be not.  The
spec writers apparently thought otherwise.

> I
> am not clear why matching of LOCK# is required on target side.  I think it
> should be good enough that target consider itself locked and do not allow
> any access other than the pending one.  Once the pending request comes, it
> should honor irrespective of whether or not the access is exclusive one.
>
> Any comments ?
>
> Thanks,
> Tripathi.

Monish Shah
Hewlett Packard
†
¬š