Date: Mon, 16 Sep 2002 13:50:03 -0700 (PDT) From: "Ted Stockwell" <tstockwell@mesabi-tech.com> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/35482: dc driver uses wrong case to read MAC from eeprom. Message-ID: <200209162050.g8GKo3q3073243@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/35482; it has been noted by GNATS. From: "Ted Stockwell" <tstockwell@mesabi-tech.com> To: "John Baldwin" <jhb@FreeBSD.org>, <freebsd-gnats-submit@FreeBSD.org> Cc: Subject: Re: kern/35482: dc driver uses wrong case to read MAC from eeprom. Date: Mon, 16 Sep 2002 15:37:12 -0500 From: "John Baldwin" <jhb@FreeBSD.org> To: <freebsd-gnats-submit@FreeBSD.org>; <tstockwell@visi.com> > I just went out and bought a SppedStream 1012 (it's the cardbus > version of the 1020 AFAICT) and it read the right MAC address > (verified by sticker on the card) just fine w/o needing this > patch. What MAC address do you get with this patch and what > address w/o this patch? >=20 > cardbus0: Expecting link target, got 0x59 > cardbus0: Resource not specified in CIS: id=3D10, size=3D100 > cardbus0: Resource not specified in CIS: id=3D14, size=3D400 > dc0: <Accton EN2242 MiniPCI 10/100BaseTX> port 0x1100-0x11ff mem = 0x88002000-0x88 > 0023ff irq 11 at device 0.0 on cardbus0 > dc0: Ethernet address: 00:30:f1:34:3a:b2 > miibus0: <MII bus> on dc0 > ukphy0: <Generic IEEE 802.3u media interface> on miibus0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >=20 > John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ The hardware must be a little different. Testing two different SpeedStream 1020 cards, without my fix, the MAC=20 address comes up as: "08:00:08:00:08:00" on both cards. With the fix the MAC addresses come up as: "00:30:f1:2d:f5:a1" and "00:30:f1:10:b7:a8". =20 The vendor id of "00-30-f1" is correct for Accton Technologies. In if_dc.c's dc_eeprom_putbyte(), there is a special case for the AN985 (DC_IS_CENTAUR). The comment states that: "The AN985 has a 93C66 EEPROM on it instead of a 93C46. It uses=20 a different bit sequence for specifying the "read" opcode." The SpeedStream 1020 behaves like a AN985 clone, but has a=20 93c46 EEPROM. So, going down the CENTAUR special case=20 causes it to read the eeprom incorrectly. One resource I found on the net suggested that the EN5251 was=20 really a clone of the ADMtek 983. I do not know how the 983=20 differs from the the 985 or 981, which are explicitly supported in=20 by the dc driver. One point about this code that merits review is the use of the DC_IS_CENTAUR() macro. Should the DC_IS_CENTAUR=20 be used in dc_eeprom_putbyte(), in which case the EN5251B=20 is not a CENTAUR? Or, should the test in dc_eeprom_putbyte()=20 test explicitly for the 985, in which case the new DC_TYPE_EN5152B=20 type should be added to DC_IS_CENTAUR? my notes can be found at: http://www.visi.com/~tstockwell/SS1020.html -- Ted Stockwell, tstockwell@mesabi-tech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200209162050.g8GKo3q3073243>