Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 2 Jun 2003 00:43:39 +0100 (BST)
From:      Andrew Gordon <arg-bsd@arg.me.uk>
To:        <net@freebsd.org>
Subject:   if_dc - ADMTek AN983B problem (solution)
Message-ID:  <20030601235753.C46670-200000@server.arg.sj.co.uk>

next in thread | raw e-mail | index | archive | help
  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--0-615467604-1054511019=:46670
Content-Type: TEXT/PLAIN; charset=US-ASCII


Problem:

  if_dc driver fails to read MAC address from AN983B (on-board ethernet on
  MSI motherboard in this case).  Not only does it get the wrong value of
  MAC address, but it permanently trashes the EEPROM contents, so that it
  is necessary to use the manufacturer's utility to re-set the MAC address
  in the EEPROM before it will work again in Windows.

Analysis:

   if_dc only claims to support the AN985B, not the AN983B, though they
   appear from the datasheet to be the equivalent and have the same
   device ID ('985 is cardbus, '983 is ordinary PCI).  If the EEPROM
   reading code in the driver is commented out, the driver works OK and
   the EEPROM is not corrupted.

   I had expected this to be the usual sort of problem with
   on-motherboard devices being configured in a non-standard way
   (and maybe storing the MAC address elsewhere), but in fact it
   seems to be a perfectly standard implementation with an EEPROM
   dedicated to the AN983B (adjacent to it on the PCB).

Solution:

  For this device, the only thing that the driver attempts to read from
  the EEPROM is the MAC address.  However, according to the datasheet
  (and confirmed by testing) the MAC address is automatically loaded into
  the PAR0/PAR1 registers after reset, so we can simply read it from
  those registers directly rather than doing the bit twiddling to
  access the EEPROM by brute force.

  The enclosed patch does this, and works well for me (I've minimised
  the changes, so only 3 lines of diff).

  I'm working in RELENG_4, but there have been no relevant changes to
  the driver and the patch applies unchanged to -current too.

Caveats:

  I only have this one type of motherboard for testing; I don't have
  any AN985B cards to see if my patch upsets them.
  Also, the driver treats the "Accton EN2242" as equivalent to the
  AN985B - I'm guessing that this is just a card built from the
  AN983B but using different vendor/device Ids for branding purposes,
  so I've made my patch apply to these too, but again I can't test.

  The code that I've replaced looks a bit odd: it seems to read
  the MAC address from a copy of the EEPROM in the softc that
  it recorded earlier, then immediately over-writes that by
  reading it directly from the EEPROM again.  Did this ever work?






--0-615467604-1054511019=:46670
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="if_dc.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <20030602004339.H46670@server.arg.sj.co.uk>
Content-Description: 
Content-Disposition: attachment; filename="if_dc.patch"

SW5kZXg6IGlmX2RjLmMNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBm
aWxlOiAvdXNyL2N2c2Jhc2UvcmVwb3NpdG9yeS9zcmMvc3lzL3BjaS9pZl9k
Yy5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS45LjIuNDENCmRpZmYgLXUg
LXIxLjkuMi40MSBpZl9kYy5jDQotLS0gaWZfZGMuYwk1IE1hciAyMDAzIDE4
OjQyOjMzIC0wMDAwCTEuOS4yLjQxDQorKysgaWZfZGMuYwkxIEp1biAyMDAz
IDIzOjM1OjE0IC0wMDAwDQpAQCAtMTg3MSw3ICsxODcxLDcgQEANCiAJCXNj
LT5kY19mbGFncyB8PSBEQ19UWF9VU0VfVFhfSU5UUjsNCiAJCXNjLT5kY19m
bGFncyB8PSBEQ19UWF9BRE1URUtfV0FSOw0KIAkJc2MtPmRjX3Btb2RlID0g
RENfUE1PREVfTUlJOw0KLQkJZGNfcmVhZF9zcm9tKHNjLCBzYy0+ZGNfcm9t
d2lkdGgpOw0KKwkJLyogRG9uJ3QgcmVhZCBTUk9NIGZvciAtIGF1dG8tbG9h
ZGVkIG9uIHJlc2V0CSovDQogCQlicmVhazsNCiAJY2FzZSBEQ19ERVZJQ0VJ
RF85ODcxMzoNCiAJY2FzZSBEQ19ERVZJQ0VJRF85ODcxM19DUDoNCkBAIC0x
OTk0LDkgKzE5OTQsOCBAQA0KIAkJYnJlYWs7DQogCWNhc2UgRENfVFlQRV9B
TDk4MToNCiAJY2FzZSBEQ19UWVBFX0FOOTg1Og0KLQkJYmNvcHkoJnNjLT5k
Y19zcm9tW0RDX0FMX0VFX05PREVBRERSXSwgKGNhZGRyX3QpJmVhZGRyLA0K
LQkJICAgIEVUSEVSX0FERFJfTEVOKTsNCi0JCWRjX3JlYWRfZWVwcm9tKHNj
LCAoY2FkZHJfdCkmZWFkZHIsIERDX0FMX0VFX05PREVBRERSLCAzLCAwKTsN
CisJCSoodV9pbnQzMl90ICopKCZlYWRkclswXSkgPSBDU1JfUkVBRF80KHNj
LCBEQ19BTF9QQVIwKTsNCisJCSoodV9pbnQxNl90ICopKCZlYWRkcls0XSkg
PSBDU1JfUkVBRF80KHNjLCBEQ19BTF9QQVIxKTsNCiAJCWJyZWFrOw0KIAlj
YXNlIERDX1RZUEVfQ09ORVhBTlQ6DQogCQliY29weShzYy0+ZGNfc3JvbSAr
IERDX0NPTkVYQU5UX0VFX05PREVBRERSLCAmZWFkZHIsIDYpOw0K
--0-615467604-1054511019=:46670--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030601235753.C46670-200000>