Re: use lock# to solve deadlock?

["Alexander Bezrukov" <alb_@pisem.net>]

Liu,

there is no standard and compatible way
(and no way at all in all C compilers I
know) to have a C compiler to generate
LOCK prefix for a processor instruction
(which accesses data at address that
mapped to your PCI address space).
(And such a single instruction could
be generated from a quite complex C statement).
Also atomic access instructions cannot be
locked by processor (from the point of
processor's bus usage this is a nonsense).
There is a long way beetween issuing a LOCK
prefix and asserting the LOCK# on your
secondary PCI bus.

And do you really believe your deadlock will
be resolved by locked accesses? Note, that
not all (host) bridges implement LOCK state
machine. Also processor's cache LOCK (caused
by LOCK prefix) does not necessary propagates
to processor's bus LOCK, so you need to mark
your physical memory area with suitable memory
type (using MTRRs) or handle it somehow else.

I would recommend you first try to tune your
PPB (if it is possible, disable caching as much
as possible, disable fast back to back
transactions and so on), see if the deadlock
disappears and try to understand the picture
of the deadlock. If you have a logic analyzer,
you possibly do not need to drastically torment
your imagination :).  Maybe you will be then
able to vanquish this deadlock in hardware.

My best wishes,
Alexander Bezrukov

----- Original Message -----
From: "lyf" <liuyunfei@routerd.com>
To: <pci-sig@znyx.com>
Sent: Thursday, 23 May, 2002 09:59
Subject: use lock# to solve deadlock?


> Hello experts,
>
> I believe that my GX1-based system goes into deadlock when devices work on
secondary pci bus of PPB(intel 21150 or ti pci2050). And I found in spec
that signal lock# can be used to solve deadlock.Now I wonder how to
> generate lock#. I found in GX1 datasheet that some instructions with a
prefix "lock" can generate signal lock#.
> But how about it in C language ?
>
> Thanks in advance!
>
> Liu Yunfei