Problems with the Netgear FA310TX - Broadcasts and TX Lockup
Steven Fosdick
fozzy@pelvoux.demon.co.uk
Fri May 5 20:14:44 2000
On Fri, May 05, 2000 at 06:02:09PM -0400, Donald Becker wrote:
>> tulip-0.91g-ppc (from 2.2.15pre13)
>
> These versions should work the PNIC-I, although I tested the original
> code not the modified versions in the kernel. ("With many eyes, all bugs
> are shallow. With many fingers, all bugs exist.")
I tried the above tulip-0.91g-ppc and the new tulip.c:v0.92 4/17/2000
downloaded from your web site. Unfortunately 0.92 doesn't seem to fix
the transmitter lock up problem I was having.
The ARP/broadcast problem I reported seems to be a problem with the
Intel Etherexpress 16 (ISA) at the othr end as:
1. The ARP/broadcast problem also exists when the Intel
EtherExpress 16 is paired with an OEM Intel EtherExpress
100 Pro.
2. ARP works fine initiated from the FA310TX when the other end is
an NE1000.
The TX lockup problem does seem to be down to the FA310TX:
1. The OEM Intel EtherExpress100 Pro doesn't experience TX lockups
when paired with the Intel EtherExpress 16 (ISA).
2. The FA310TX still experiences TX lockups when the other end is
an NE1000.
Interestingly with the OEM Intel EtherExpress100 and the FA310TX back
to back (full duplex) I haven't been able to reproduce the lockup
problem.
> What is the timeout message? I'm especially interested in the v92
> driver message.
I get (from 0.92):
eth0: MII link partner 0021, negotiated 0021.
eth0: Transmit timeout using MII device.
As long as there is still an open TCP connection trying to send data
the two messages keep appearing, and examining the TX counter with
ifconfig shows that no packets have been transmitted in between two
timeout messages.
At this point tulip-diag reports:
tulip-diag.c:v1.19 10/2/99 Donald Becker (becker@cesdis.gsfc.nasa.gov)
Index #1: Found a Lite-On 82c168 PNIC adapter at 0xcc00.
Port selection is MII, half-duplex.
Transmit started, Receive started, half-duplex.
The Rx process state is 'Waiting for packets'.
The Tx process state is 'Waiting for Tx to finish'.
The transmit threshold is 72.
Use '-a' or '-aa' to show device registers,
'-e' to show EEPROM contents, -ee for parsed contents,
or '-m' or '-mm' to show MII management registers.
and mii-diag -v reports:
mii-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
MII PHY #1 transceiver registers:
3000 782d 0040 6212 01e1 0021 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
5000 0001 0000 0000 0000 0000 0100 0000
003c d006 0f00 ff00 002c 4000 0080 000b.
Basic mode control register 0x3000: Auto-negotiation enabled.
You have link beat, and everything is working OK.
This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation complete.
Your link partner is generating 10baseT link beat (no autonegotiation).
MII PHY #1 transceiver registers:
3000 782d 0040 6212 01e1 0021 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
5000 0000 0000 0000 0000 0000 0200 0000
003c 8006 0f00 ff00 002c 4000 0080 000b.
Basic mode control register 0x3000: Auto-negotiation enabled.
Basic mode status register 0x782d ... 782d.
Link status: established.
Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation complete.
Vendor ID is 00:10:18:--:--:--, model 33 rev. 2.
No specific information is known about this transceiver type.
I'm advertising 01e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT
Advertising no additional info pages.
IEEE 802.3 CSMA/CD protocol.
Link partner capability is 0021: 10baseT.
Negotiation did not complete.
if take the card down and run tulip-diag -a I get:
tulip-diag.c:v1.19 10/2/99 Donald Becker (becker@cesdis.gsfc.nasa.gov)
Index #1: Found a Lite-On 82c168 PNIC adapter at 0xcc00.
Lite-On 82c168 PNIC chip registers at 0xcc00:
00008000 01ff0000 00450008 004fe000 004fe200 02200110 814c0000 00000000
00000000 00000000 004fe250 004fe250 00000025 00000000 00000000 10000001
00000000 00000000 f0041385 000000bf 6086782d 004fe070 06717010 0201f878
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Port selection is MII, half-duplex.
Transmit stopped, Receive stopped, half-duplex.
The Rx process state is 'Stopped'.
The Tx process state is 'Waiting for Tx to finish'.
The transmit threshold is 72.
The lspci -v command reports my card as:
00:0a.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
Subsystem: Netgear FA310TX
Flags: bus master, medium devsel, latency 64, IRQ 11
I/O ports at cc00
Memory at effffe00 (32-bit, non-prefetchable)
Expansion ROM at eff80000 [disabled]
and your tulip driver 0.92 reports it as:
eth0: Lite-On 82c168 PNIC rev 32 at 0xc88c8e00, 00:A0:CC:5E:F4:3D, IRQ 11.
eth0: MII transceiver #1 config 3000 status 782d advertising 01e1.
i.e. identical to John's
The chip has "Netgear LC82C169C" printed on it.
> Looks normal. I traced this down to a 82c169 board produced around mid-'98.
> The same board layout was sold under Kingston, Linksys and Netgear brands.
>
> I tried out the Linksys version (thanks to Linksys for providing a sample!),
> and it works fine with tulip.c v092 in a BP6 (dual Celeron 440BX) talking to
> a Linksys 5 port 10/100 switch (purchased, not a sample :-<).
Talking to the switch at full or half duplex?
> ..And it works through a Intel InBusiness 10+100 repeater, which should be
> the same type of hardware you have.
Mine seems to work fine full duplex to the other 100 Mbit card I
borrowed but not to either of the 10 Mbit cards (each time connected
with the same cross pinned cable).
It also locks up when connected to the LAN at work (which is 10 Mbit HD).
It can lock up very quickly, or it can take up to half an hour of
continuous transmitting.
Thanks for taking the time to look at this. I hope something I have
said will give you a clue what's going on.
Steve Fosdick
-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-tulip-request@beowulf.org