[eepro100] 82559 Rx DMA burst limiting.

[Donald Becker]

On Wed, 24 Oct 2001, Robin Kletke wrote:

> Could someone please give me the correct settings for limiting the
> 82559 as PCI Master when doing DMA burst writes into processor memory?

Any setting should be correct.  The optimal setting is influenced by the
processor cache line size and memory subsystem design.

> I am attempting to run on an ARM7 variant (custom ASIC), that is
> giving a PCI target-disconnect during the 82559 burst write (CBE =
> 0111).  In these cases, the 82559 attempts to burst a large number of
> 32 bit words to the ARM, but the ARM asserts TRDY and STOP
> (target-disconnect).  The 82559 eventually does disconnect, but the
> final 32 bit word of the burst is lost and not written to local ARM
> memory.  I suspect that there is a problem with the ARM ASIC PCI/local
> bus bridge, but need to fix this in another way. 

Ouch!  That's a pretty serious bug.  We wouldn't trust any system with
that type of known flaw without access to public information about how
all of the PCI bus masters on the system behave.

Some '486 PCI systems had a similar bug, but they had the excuse of
referring to early PCI specs.

> My hope was to limit the burst size of the 82559 to 4 or 5 32 bit
> words. However, after setting rxdmacount and txdmacount to various
> values, (4,4) (4,0x84), I don't see any change in the 82559 cycles.

First, the settings are in four cycle units.

But that doesn't work around your hardware bug.  The settings only
control the internal arbitration, not limit the maximum burst size.  The
chip may still do an extended burst if no other internal DMA source
wants to transfer data, and there is room in the destination FIFO.  Most
of the time the limit will seem to work, but every once in a while the
chip will still do a long burst.

This detail illustrates why it's important to _know_ what's going on.
You could easily implement this change and observe that the bug no
longer appears for your test cases.  But the system is still broken, and
now it's nearly impossible for a third party to track down the bug!
This happens all of the time with Linux device drivers, and few people
understand that their quick fix only masks the problem.  (Yes, that
diverged to a flame, but no one believes me unless I point out specific
examples as they occur.)

> What is required to set and enable the dma counters?  Does byte 5, bit
> 7 == 1 enable or disable?  Various versions of the various drivers
> seem to contradict themselves. 

Bit 7 (0x80) set to 1 enables the counter.

Depending on the characteristics of your hardware bug, you might be
interested in the Byte 3 bits
    0x04 Try to align reads on cache line boundaries
    0x08 Try to terminate a burst write on a cache line boundary

More importantly, the cache settings in PCI configuration space should
be set correctly.

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993