Subject: kern/11863: Linksys LNE100TX (ADMtek AN983) support broken
To: None <gnats-bugs@gnats.netbsd.org>
From: None <bstark@qwest.net>
List: netbsd-bugs
Date: 01/01/2001 00:15:20
>Number: 11863
>Category: kern
>Synopsis: PCI network interface for Linksys LNE100TX card doesn't work.
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon Jan 01 00:15:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator: Brian Stark
>Release: NetBSD 1.5Q
>Organization:
Brian Stark
bstark@qwest.net
>Environment:
System: NetBSD callisto.niangua.net 1.5Q NetBSD 1.5Q (CALLISTO) #0: Sun Dec 31 01:23:23 CST 2000 bstark@callisto.niangua.net:/usr/local/current/src/sys/arch/i386/compile/CALLISTO i386
>Description:
There are a few problems. First, the ADMtek AN983 chip which is found
in the newer versions of the Linksys LNE100TX PCI ethernet card is not
correctly identified (it is reported as an ADMtek AN985).
Second, there seems to be some problem in correctly determining the number
of available PHYs. The code for this driver in OpenBSD notes that the MII
interface is buggy in that you can read from any MII address (0-31), but
only one address behaves normally.
Third, the driver issues error/warning messages about the receive process
failing to idle.
Fourth, there is an error message about 'ifmedia_match' from the kernel
(see output below...).
Fifth, the LAN is not accesible when the card is installed.
>How-To-Repeat:
Install a Linksys LNE100TX PCI ethernet card and attempt to use it to
access a network. Since older versions of this card used other chip sets
that are supported by NetBSD, it is important to work with cards that
are version 4.1 or higher (my card is a 4.1).
When this card is installed, the output from 'dmesg' shows the following:
tlp0 at pci0 dev 14 function 0: ADMtek AN985 Ethernet, pass 1.1
tlp0: interrupting at irq 10
tlp0: Ethernet address 00:20:78:0d:d9:b5
ukphy0 at tlp0 phy 1: Generic IEEE 802.3u media interface
ukphy0: OUI 0x000895, model 0x0001, rev. 0
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy1 at tlp0 phy 2: Generic IEEE 802.3u media interface
ukphy1: OUI 0x1e125e, model 0x0004, rev. 9
ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy2 at tlp0 phy 3: Generic IEEE 802.3u media interface
ukphy2: OUI 0x1e125e, model 0x0004, rev. 9
ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy3 at tlp0 phy 4: Generic IEEE 802.3u media interface
ukphy3: OUI 0x1e125e, model 0x0004, rev. 9
ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy4 at tlp0 phy 5: Generic IEEE 802.3u media interface
ukphy4: OUI 0x1e125e, model 0x0004, rev. 9
ukphy4: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy5 at tlp0 phy 6: Generic IEEE 802.3u media interface
ukphy5: OUI 0x1e125e, model 0x0004, rev. 9
ukphy5: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy6 at tlp0 phy 7: Generic IEEE 802.3u media interface
ukphy6: OUI 0x1e125e, model 0x0004, rev. 9
ukphy6: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy7 at tlp0 phy 8: Generic IEEE 802.3u media interface
ukphy7: OUI 0x1e125e, model 0x0004, rev. 9
ukphy7: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy8 at tlp0 phy 9: Generic IEEE 802.3u media interface
ukphy8: OUI 0x1e125e, model 0x0004, rev. 9
ukphy8: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy9 at tlp0 phy 10: Generic IEEE 802.3u media interface
ukphy9: OUI 0x1e125e, model 0x0004, rev. 9
ukphy9: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy10 at tlp0 phy 11: Generic IEEE 802.3u media interface
ukphy10: OUI 0x1e125e, model 0x0004, rev. 9
ukphy10: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy11 at tlp0 phy 12: Generic IEEE 802.3u media interface
ukphy11: OUI 0x1e125e, model 0x0004, rev. 9
ukphy11: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy12 at tlp0 phy 13: Generic IEEE 802.3u media interface
ukphy12: OUI 0x1e125e, model 0x0004, rev. 9
ukphy12: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy13 at tlp0 phy 14: Generic IEEE 802.3u media interface
ukphy13: OUI 0x1e125e, model 0x0004, rev. 9
ukphy13: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy14 at tlp0 phy 15: Generic IEEE 802.3u media interface
ukphy14: OUI 0x1e125e, model 0x0004, rev. 9
ukphy14: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy15 at tlp0 phy 16: Generic IEEE 802.3u media interface
ukphy15: OUI 0x1e125e, model 0x0004, rev. 9
ukphy15: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy16 at tlp0 phy 17: Generic IEEE 802.3u media interface
ukphy16: OUI 0x1e125e, model 0x0004, rev. 9
ukphy16: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy17 at tlp0 phy 18: Generic IEEE 802.3u media interface
ukphy17: OUI 0x1e125e, model 0x0004, rev. 9
ukphy17: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy18 at tlp0 phy 19: Generic IEEE 802.3u media interface
ukphy18: OUI 0x1e125e, model 0x0004, rev. 9
ukphy18: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy19 at tlp0 phy 20: Generic IEEE 802.3u media interface
ukphy19: OUI 0x1e125e, model 0x0004, rev. 9
ukphy19: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy20 at tlp0 phy 21: Generic IEEE 802.3u media interface
ukphy20: OUI 0x1e125e, model 0x0004, rev. 9
ukphy20: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy21 at tlp0 phy 22: Generic IEEE 802.3u media interface
ukphy21: OUI 0x1e125e, model 0x0004, rev. 9
ukphy21: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy22 at tlp0 phy 23: Generic IEEE 802.3u media interface
ukphy22: OUI 0x1e125e, model 0x0004, rev. 9
ukphy22: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy23 at tlp0 phy 24: Generic IEEE 802.3u media interface
ukphy23: OUI 0x1e125e, model 0x0004, rev. 9
ukphy23: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy24 at tlp0 phy 25: Generic IEEE 802.3u media interface
ukphy24: OUI 0x1e125e, model 0x0004, rev. 9
ukphy24: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy25 at tlp0 phy 26: Generic IEEE 802.3u media interface
ukphy25: OUI 0x1e125e, model 0x0004, rev. 9
ukphy25: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy26 at tlp0 phy 27: Generic IEEE 802.3u media interface
ukphy26: OUI 0x1e125e, model 0x0004, rev. 9
ukphy26: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy27 at tlp0 phy 28: Generic IEEE 802.3u media interface
ukphy27: OUI 0x1e125e, model 0x0004, rev. 9
ukphy27: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy28 at tlp0 phy 29: Generic IEEE 802.3u media interface
ukphy28: OUI 0x1e125e, model 0x0004, rev. 9
ukphy28: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy29 at tlp0 phy 30: Generic IEEE 802.3u media interface
ukphy29: OUI 0x1e125e, model 0x0004, rev. 9
ukphy29: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy30 at tlp0 phy 31: Generic IEEE 802.3u media interface
ukphy30: OUI 0x1e125e, model 0x0004, rev. 9
ukphy30: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ifmedia_match: multiple match for 0x20/0xffffffff
tlp0: receive process failed to idle: state RUNNING - WAIT
tlp0: receive process failed to idle: state RUNNING - WAIT
tlp0: receive process failed to idle: state RUNNING - WAIT
tlp0: receive process failed to idle: state RUNNING - WAIT
tlp0: receive process failed to idle: state RUNNING - WAIT
>Fix:
Change /usr/src/sys/dev/pci/pcidevs so that the correct codes are used
for the ADMtek AN983 and AN985. In revision 1.281 of this file, the
section that defines this information looks like this:
/* ADMtek products */
product ADMTEK AL981 0x0981 ADMtek AL981 10/100 Ethernet
product ADMTEK AN985 0x0985 ADMtek AN985 10/100 Ethernet
When it should look like this:
/* ADMtek products */
product ADMTEK AL981 0x0981 ADMtek AL981 10/100 Ethernet
product ADMTEK AN983 0x0985 ADMtek AN983 10/100 Ethernet
product ADMTEK AN985 0x1985 ADMtek AN985 10/100 Ethernet
For a reference to these codes, please refer to the following documents
available from http://www.admtek.com:
Centaur-P
AN983 PCI/mini-PCI 10/100 Fast Ethernet Controller With Integrated PHY
Revision 1.2, May 2000, page 21
Centaur-C
AN985-Cardbus 10/100 Fast Ethernet Controller With Integrated PHY
Revision 1.2, May 2000, page 21
NOTE: There seems to be a bit of confusion as to the exact device id
code for the AN985 chip. According the information from ADMtek, the
device id number is the same as the one for the AL981 chip -- 0x0981.
During my research on this, I came across some information at
http://www.scyld.com/network/tulip.html which appears to be a support
page for Linux and the DEC "Tulip" Chip and clones. According to the
information from that web site, the code demos are using 0x1985 as the
device id for the AN985. Since I do not have a network interface that
uses the AN985, I can't verify which code is correct. However, I am
more inclined to believe what is used in the code demo than what is
in a document (documents are always subject to change, and it doesn't
make much sense to use a code that is already in use for the AL981).
Perhaps someone with a AN985-based network interface can comment on
this issue...
Change /usr/src/sys/dev/pci/if_tlp_pci.c so that it is updated with this
information. In revision 1.48 of this file, the section that defines this
information looks like this:
{ PCI_VENDOR_ADMTEK, PCI_PRODUCT_ADMTEK_AL981,
TULIP_CHIP_AL981 },
{ PCI_VENDOR_ADMTEK, PCI_PRODUCT_ADMTEK_AN985,
TULIP_CHIP_AN985 },
When it should look like this:
{ PCI_VENDOR_ADMTEK, PCI_PRODUCT_ADMTEK_AL981,
TULIP_CHIP_AL981 },
{ PCI_VENDOR_ADMTEK, PCI_PRODUCT_ADMTEK_AN983,
TULIP_CHIP_AN983 },
{ PCI_VENDOR_ADMTEK, PCI_PRODUCT_ADMTEK_AN985,
TULIP_CHIP_AN985 },
Also in if_tlp_pci.c, the section that trys to detect the ADMtek chip
type for AN983/AN985 needs to be changed. This sections currently looks
like this:
case TULIP_CHIP_AN985:
/*
* The AN983 and AN985 are very similar, and are
* differentiated by a "signature" register that
* is like, but not identical, to a PCI ID register.
*/
reg = pci_conf_read(pc, pa->pa_tag, 0x80);
switch (reg) {
case 0x09811317:
sc->sc_chip = TULIP_CHIP_AN985;
break;
case 0x09851317:
sc->sc_chip = TULIP_CHIP_AN983;
break;
default:
/* Unknown -- use default. */
}
break;
I think it should be changed to look like this:
case TULIP_CHIP_AN983:
sc->sc_chip = TULIP_CHIP_AN983;
break;
case TULIP_CHIP_AN985:
sc->sc_chip = TULIP_CHIP_AN985;
break;
The reason for this change is that both the AN983 and AN985 contain a
device ID at offset 80h (bits 31-16), and bits 15-0 contain the vendor
id. NetBSD can correctly detect the device id, so no extra checking
is necessary.
In regard to my statement about the code in OpenBSD reporting the MII
interface as being buggy, the following comment can be found in the
OpenBSD source code for the dc network interface -- 'dc.c',
revision 1.14:
/*
* Note: both the AL981 and AN983 have internal PHYs,
* however the AL981 provides direct access to the PHY
* registers while the AN983 uses a serial MII interface.
* The AN983's MII interface is also buggy in that you
* can read from any MII address (0 to 31), but only address 1
* behaves normally. To deal with both cases, we pretend
* that the PHY is at MII address 1.
*/
N.B.: this comment appears in function dc_miibus_readreg()
In regard to the fifth item I mentioned, the network is not accessible
via the LNE100TX card. On my system I see:
callisto:bstark$ ifconfig tlp0
tlp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 192.168.1.11 netmask 0xffffff00 broadcast 192.168.1.255
inet6 fe80::220:78ff:fe0d:d9b5%tlp0 prefixlen 64 scopeid 0x1
callisto:bstark$
and I can't ping to another machine I have on the same LAN (IP Filter
is not running so outbound packets to the 192.168.X.X network should
go out...)
>Release-Note:
>Audit-Trail:
>Unformatted: