> OK.  Ah, I see.  "Murphy's law" has the ethernet packet built
> in such a way that the data and header fields won't *both* be
> aligned the same way.  And, if you tweek the LANCE's DMAC to
> align *one* of them, then the other ends up misaligned by a
> "half word".  No win situation...  So, configure the DMAC
> to align the *bulk* of the data and incur the cost of moving the
> rest "by hand"...
> 
> This, of course, assumes the SBUS will tolerate the misaligned
> transfers (i.e. your point exactly)

You need to get the system doing 4 word bursts on the sbus.  The cost
of single 16-bit transfers is far too high!  The DMA+/DMA2 has 2 cache
lines used to buffer the lance - memory traffic.  The way these are
flushed, invalidated and read ahead is somewhat unusual and is based
on explicit knowledge of the transfers that the lance will request.
> 
> OK.  This also makes sense.  And, a rational tradeoff -- data
> on the SCSI will still *be* there when you get around to it
> a bit later; the network packet *won't*!

Absolutely - unfortunately I came to the conclusion that the cpu is given
priority over the sbus on accesses to main memory.  This will slightly
improve SCSI benchmarks (the cpu will not stall on memory until it is
looping waiting for the data), but has a serious, detremental effect on
network traffic when the cpu is trying to use 100% of teh memory bandwidth.
(I never did find out whether the relevant arbiter worked that way).
> 
> Thanks!  A truly enlightening description of the problem!
> 
> Does there exist any documentation describing the various
> hardware in this sort of detail?  Or, is it only acquired
> "through experience" (i.e. by being burned and then trying to
> figure out "why")?

Some of it is documented, but usually only in places you search while
scratching your head trying to work out why the hell the system doesn't
work on a customer site :-)
Unfortunately you need the errata documents for the chipsets these are
particularly difficult to obtain!

    David