On Wed, Feb 07, 2007 at 03:22:26PM +0100, Andreas_Hallmann wrote:
> 
> After an uptime of > 4 days I get along with many collisions lots of 
> 
> 	le0: missed packet
> 
> I digged the sources but am stil unshure.
> Does it meen that thoose 8 recieve buffers are insuficient?
> Can I increase the number of recieve buffers for le0,
> or are the part of the lance chip?

The maximum number of rx buffers will be 128, the number must be a power of 2.
I don't know exactly how the netbsd driver does things though!

However I suspect you aren't getting interrupts served often enough.
 
> Moreover looking a bit beeper on my dmesg, I wonder why my onboard
> le0 is bound to sbus0 and my sbus le1 is bound to ledma0.
> Does that meen I have dma support for le1 but not for le0?

No - the AMD Lance chipset always runs in DMA mode. It really expects
to acquire the host bus (from the cpu) in order to access memory.
For the sbus systems the LSI Logic 'DMA' part acts as the normal bus master
for the on-board bus, and relays transactions from the lance onto the sbus.
In order to do burst transfers on the sbus (and to get enough bandwidth)
the DMA part has (IIRC) two 32 byte buffers into which it pre-fetches TX
data and buffer RX data.  The caching and read-ahead algorithm is carefully
designed to work with the transfers the lance actually makes.

The DMA chip has interfaces for the lance, scsi, parallel port and the
ROM (I think that is all).  There is one on the motherboard that has all
the onboard devices connected, the sbus ethernet card will have one of its
own with the other devices absent.

There are several different version of the DMA chip (and I don't know
which sun motherbaords have which), the early one requires that ethernet
rx buffers be on a 32 byte boundary (which sucks because they then need
a software misaligne4d copy).  The DMA2 part handles that ok.

The other problem is one of sbus latency and priorities.  Somewhere
there ought to be a register to set the priorities of the sbus slots
master accesses.  Usually the motherboard port is high priority, and the
other low priority.  Under heavy load (and probably requiring 2 dual cpu
modules) the sbus devices can get starved of accesses to main memory.
This causes the lance to timeout its bus transfers - which exposes some
silicon bugs in the nmos lnace itself :-(
However you aren't seeing those because the system tends to lock solid
on the next access to the lance!
(And I don't remember seeing any of the required code in the netbsd le
or ledma driver.)

	David

-- 
David Laight: david@l8s.co.uk