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 - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
