Problems with the Netgear FA310TX - Broadcasts and TX Lockup

Donald Becker becker@scyld.com
Fri May 5 18:03:23 2000


On Fri, 5 May 2000, John Stoffel wrote:

> Cc: linux-tulip@beowulf.gsfc.nasa.gov

Please use linux-tulip@beowulf.org as the mailing list address -- the future
of the CESDIS machines is uncertain.

> Subject: Re: Problems with the Netgear FA310TX - Broadcasts and TX Lockup

>      - Linux 2.2.15pre13, NetGear FA310-TX PCI 10/100 carc, Pentium
>      - At the center of it all, NetGear DS108 Dual Speed Hub.  
..
> I've tried the following version of the tulip driver, with various
> levels of un-sucess:
> 
>        tulip-0.89H (old_tulip from 2.2.15pre13)

Note that this is a heavily modified version, not the "real" 89H.

>        tulip-0.90q
>        tulip-0.90z
>        tulip-0.91g (from 2.2.15pre??)
>        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.")

> Basically, when I ifconfig eth0 up, it auto-negotiates to be
> 100baseTx, which is great, this is exactly what the [pc] does as
...
> But I can't seem to send packets to either the classic or the pc
> without lots of timeouts and dropped packets.  The performance is

What is the timeout message?  I'm especially interested in the v92 driver
message.

> Here's the lspci -xxxvv output from [ jfslinux ], showing that this
> isn't a true tulip based FA310-TX board:
...
>     00:14.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
> 	    Interrupt: pin A routed to IRQ 10
> 	    Region 0: I/O ports at 6100

Grrr, it's not a "LNE100TX", it's a Lite-On PNIC.  Just a nit.
Everything else looks normal.

>     tulip.c:v0.89H 5/23/98 becker@cesdis.gsfc.nasa.gov 
>     eth0: Lite-On 82c168 PNIC at 0x6100, 00 a0 cc 57 9a c1, IRQ 10. 
>     eth0:  MII transceiver found at MDIO address 1, config 3000 status 7829. 

No link beat, but everything else looks normal.  Based on the 'mii-diag'
reports below, the no-link-beat indication was just the "sticky bit" setting
from boot time.

>     tulip.c:v0.90q 2/23/99 becker@cesdis.gsfc.nasa.gov 
>     tulip.c:v0.90z 4/7/99 becker@cesdis.gsfc.nasa.gov 
>     tulip.c:v0.91g 7/16/99 becker@cesdis.gsfc.nasa.gov 
>     tulip.c:v0.91g-ppc 7/16/99 becker@cesdis.gsfc.nasa.gov 

All had.

>     eth0: Lite-On 82c168 PNIC rev 32 at 0x6100, 00:A0:CC:57:9A:C1, IRQ 10. 
>     eth0:  MII transceiver #1 config 3000 status 782d advertising 01e1. 

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 :-<).

..And it works through a Intel InBusiness 10+100 repeater, which should be
the same type of hardware you have.


> Here's the log of doing an insmod, and then using the mii-diag and
> tulip-diag programs from Donald Becker's web site to try and see what the
> board reports on startup.  The mii-diag program was compiled with the
> libmii stuff as well, to make sure we got lots of debugging info.
> Unfortunately, the 0.89H version of the driver didn't work quite properly
> with mii-diag, so all we have is the info from the tulip-diag.

The '168 chip was originally documented with only SYM transceiver support,
although it had MII pins.  The MII boards didn't exist in May '98 for me to
have developed MII support, and when they did arrive (MII transceivers
became less expensive than SYM), the chip required a work-around for a
timing buglet.

>   mii-diag -f -a
> mii-diag.c:v1.07 10/14/99  Donald Becker (becker@cesdis.gsfc.nasa.gov)
>  MII PHY #1 transceiver registers:
>    1000 782d 0040 6212 01e1 40a1 0003 0000

Looks normal for a 10+100 bridged repeater.

> I'm more than willing to try out new patches and stuff, I'd just like
> to get this working properly if I can!

Donald Becker				becker@scyld.com
Scyld Computing Corporation
410 Severn Ave. Suite 210
Annapolis MD 21403


-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-tulip-request@beowulf.org