PLX9060 / Write-Write deadlock

[Markus Leberecht <leberech@informatik.tu-muenchen.de>]

Hi everybody!

We are a small research group at a local university in Munich and
are currently developing a PCI card that performs protocol conversion
to SCI, the scalable coherent interface. We thus needed a combined
master/target interface and chose PLX technology's 9060 as the 
appropriate solution. However, there seems to be one particular 
situation in which the combination of the PLX 9060 and the
mainboard chipset (tested with FX and HX, 1st stepping) doesn't work 
as expected:

The application which essentially is the conversion of a protocol
with pure split memory transactions (SCI) to one with limited split
transaction capabilities (PCI) and vice versa demands the resolution of 
possible deadlock situations. A configuration is possible in which our card
needs to flush buffers to main memory before being able to accept any READ
or WRITE transaction from the host bridge. In case of the READ, 
everything works fine:

- host bridge owns bus
- 9060 issues a retry (we need to flush some buffers first)
- host bridge backs off
- 9060 flushes buffer
- host bridge restarts its access.

However, if the host bridge intended to start a WRITE access on PCI
to the memory range of our card, the following is happening:

- host bridge owns bus and wants to write
- 9060 issues a retry (we need to flush some buffers first)
- no GNT to the 9060 is ever asserted
- host bridge continues to try to write every 5 or 6 PCI clocks, 9060
  never accepts the transaction => system hangs

If I understand the PCI spec correctly, a target initiated termination
of a 'retry' type should work regardless of the transaction on the 
bus being a regular READ or WRITE, shouldn't it?

Some additional information: The memory range of our circuit is non-
prefetchable and is not a cacheable region (cache line size = 0), thus
the host bridge's attempted transaction is a pure memory write (0111).

Has anyone else ever encountered this and is there any solution or 
workaround to it? It shouldn't be such an uncommon problem *if* it 
possibly is a hardware bug somewhere and should occur for some other
DMA/shared memory capable networking circuitry, too. 

Any ideas anyone?

Best regards,

Markus Leberecht

--
-----------------------------------------------------------------------
Markus Leberecht, Ph.D. student, TU Muenchen, Germany      #####  #####
www  : http://wwwbode.informatik.tu-muenchen.de/~leberech/   # #  # # #
phone: +49-89-289-25357     fax: +49-89-289-28232            # #### # #

¯$