Hide Forgot
Supposed to be a "tulip" according to http://www.linksys.com/support/support.asp?spid=25 I gave one of these cards to Dr. Mike.
Please test...
verified that this card is not found during autoprobe, and doesn't respond to tulip or old_tulip drivers in beta3 ... it also doesn't respond to autoprobe, tulip or old_tulip in 6.1, 6.2 ... % lspci ; lspci -n 00:0b.0 Ethernet controller: Bridgecom, Inc: Unknown device 0985 (rev 11) 00:0b.0 Class 0200: 1317:0985 (rev 11)
Looks like it needs the .92 version of the Tulip driver and we provide .91. ftp://ftp.scyld.com/pub/network/tulip.c Adding johnsonm to the cc: list so maybe we can get this included.
verified this is still unresolved in post-RC1 tree (qa0819.0) ... (ie the card still does NOT respond to tulip or old_tulip drivers in tree)
Regarding tulip drivers.. please also note that the current driver and Don's latest 0.92 driver is flawed w/ forced full duplex operation under certain conditions/cards. An example of these is D-Link DFE-570TX, a cheap (250$) quad ethernet. Works fine now with tweaked drivers (below). This was flawed even with the latest Don Becker release (0.92) from Apr 2000. It has to be patches ad follows (or the driver in ftp://ftp.scyld.com/pub/network/test/ used) ------------------- The correction is around line 863. Note that it fixes two problems. The code must *clear* the bits first! /* Enable autonegotiation: some boards default to off. */ mdio_write(dev, phy, 0, mii_reg0 | (tp->full_duplex ? 0x1100 : 0x1000) | (media_cap[tp->default_port]&MediaIs100 ? 0x2000:0)); ___ /* Configure the xcvr: some boards default to autonegotiation off. */ mdio_write(dev, phy, 0, (mii_reg0 & ~0x3100) | (tp->full_duplex ? 0x0100 : 0x0000) | ((media_cap[tp->default_port] & MediaIs100) ? 0x2000 : 0x1000)); ------------------- This was given by Don Becker. This was discussed on linux-net on about 19th Jul.
This also breaks with the NetGear FA311
The NetGear FA311 isnt relevant to this . That isnt a tulip card but a for the moment unsupported natsemi device
To make a change this significant to such a commonly-used driver, the change would have had to have been made before a public beta where a relatively large group of people would test it, or in a stable kernel release from Alan (again, a large group of people would test it). There are a lot of variants on the tulip chip out there, and to change any tulip driver significantly without time for lots of testing would likely cause too many problems -- as evidenced by pekkas's note that Donald's driver from 4 months ago is known not to be sufficiently stable (and fixing one bug wouldn't be enough to make us confident in the change). Therefore, I'm regretfully deferring this. :-(
*** Bug 16652 has been marked as a duplicate of this bug. ***
Please try RC2 on this card.