>>My first thought is that it would be a good idea to check whether the
>>same thing happens when using the fxp driver.
>>If you try to do a large network transfer, the driver locks up after
>>64Kb has been transferred.
>>Robert Swindells

We are also seeing unexplained behaviour on the PCI bus. With a transfer
from one of the normal slots to the system slot, the PCI signals show that
transfers are happening nice and efficiently - long bursts of data are being
transferred in one shot. However, for transfers in the opposite direction
(from a system to a normal slot), the PCI signals show that there are short
bursts of data, not long ones, with "retry" and "abort"'s being seen.

This affects our image capture card, with compression from the card to
system SDRAM being nice and quick, but sending images from SDRAM to the card
for display being sluggish. The card works well under NetBSD/i386 with the
same driver, but has these problems under NetBSD/arm32 on the EBSA285. We
see the same sort of performance isssues with the pciide driver, using a
Promise Ultra DMA 33 controller, which has been well integrated into NetBSD.
The transfers from disk to RAM are great, but from RAM to disk are much
slower.

Is this problem not wider than 1 or 2 device drivers? Is it not a problem
with some part of the PCI implementation on NetBSD/arm32, or specifically
the EBSA285/DC21285 implementation? This is not a plea for flaming: I'm just
asking the question...

Bruce.