On Thu, 21 Jun 2001, Ben Greear wrote: > Donald Becker wrote: > > > 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. > So your tulip driver is now known to work correctly for the ZYNX boards > (on Intel too)? The 346 and 346Q have been in the testing queue, and I pretty sure they worked for quite some time. An Alpha CS-20 just happened to be the machine the guys were testing when I moved the 346Q to the top of the "to-test" stack this morning. My personal development machine is a x86, so having someone else test the board in an Alpha provides better test coverage. > If so, I'll attempt to install your latest driver into > a 2.2.19 kernel and do some testing. What driver version should I be > looking for? We are doing final testing on our release, which uses 0.92v (soon to be renumbered v0.93 or v1.00). > > 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.... Note that this behavior can make the interface appear to be initially broken, especially with DHCP clients that start out by bring the interface up only briefly. > > 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. > > Is the reason the driver (in the kernel, at least) is so unstable after > all these years because the driver tries to run too many different > NICs? In other words, if it was split into more distinct drivers, > would it be more backwards compatible in the long run? Good concept looking from the outside. But the various chips have different parts in common, and having multiple drivers means that an update or fix will apply to most of the split-up drivers. The only driver where a split was obvious is the Davicom chip. It has a few really ugly bug work-arounds. The Winbond 840 chip is also Tulip-like, but would require variable register offsets. > Also, do you have any idea of when/if your working driver(s) will be > ported to function with the 2.4 kernel? The drivers now all compile against the 2.4 kernel, but we don't have any development machine we are willing to risk actually running 2.4. The whole testing team is currently focused on the 2.2 Beowulf kernel. After that's finished, we'll get the 2.4 port of the drivers and tools working. 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
