[tulip] Most ethernets record?

[Donald Becker]

On Tue, 19 Jun 2001, Ben Greear wrote:
> Donald Becker wrote:
> > 
> > On Tue, 19 Jun 2001, A James Lewis wrote:
> > > Cc: tulip@scyld.com, linux-net@vger.kernel.org
> > > Subject: Re: [tulip] Most ethernets record?
> > >
> > >
> > > Did this work properly since I tried Znyx 4 port tulip cards and they sort
> > > of work but there's loads of collisions and poor performance.  It works
> > > with SUN QFE cards though so I guess theres a problem in the tulip driver.
> > 
> > Please don't make a general claim that "there's a problem with the tulip
> > driver".
> > 
> > The Tulip driver from ftp.Scyld.com works fine with all Znyx cards we
> > have available for testing, and has for several years.
> 
> Actually, I was never even able to get my ZYNX 4-port (346Q)
> card to work correctly in full-duplex mode, even under the older
> 2.2 kernels.

The 346Q (21143 + SYM), as well as the older 346 (21140A) is in our
testing queue for the Tulip driver.
We just put a 346Q in an Alpha system this morning to test.

The only unexpected behavior is one common to all 21143+SYM boards:
autonegotiation does not complete until the interface is brought up the
first time.  This is because the driver software must explicitly handle
some of the autonegotiation timing, and the driver will not register
timer events unless the interface is open.  To do otherwise risks race
conditions with the timer code.

> As recent as the 2.2.19 kernel, the D-LINK 4-port cards did not do

We confirmed that the 2.2.19 and 2.4 kernels are still broken.
I can't even get driver contact info updated, so I don't accept the
blame for long-fixed problems in those distributions.

> Unfortunately, regardless of the 2.2 functionality, I will have to
> stay with 2.4 kernel, because it has so many other benefits that
> I need, but if the driver works in one kernel, maybe we can
> figure out why it fails in 2.4.

The 21143 + SYM code is tricky, and the actual requirements are not
documented.  The only way to figure out the working method is to have a
large collection of cards, and figure out the lowest common denomiator
for their interpretation of the Digital "SROM" documentation.

Digital (now Intel) did end up having to deal with the design problem
they created.  Later versions of 21143 chip incorporated Wake-On-LAN.
That meant the chip had to configure itself, rather than rely on an
arbitrarily complex driver.  The solution was adding even more stuff to
the EEPROM -- the transceiver configuration summary information that
should have been provided to the driver years ago.

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