Problems with the Netgear FA310TX - Broadcasts and TX Lockup

[Steven Fosdick]

Dear List Members,

Since I discovered the Netgear FA310TX I recently purchased didn't
work reliably I have been looking back through the archives of this
list and I'm fairly sure that the problems I am about to describe are
not unique but I wonder if anyone has any ideas as to how to solve
them.

The configuration where the problems have been most apparent is with
the follwing two PCs:

Pelvoux is a 750Mhz AMD Athlon with the MSI K7-Pro motherboard (AMD
chipset) and a Netgear FA310TX Rev. D2 which is based on a Netgear
badged LC82C169C

Bonehead is a 200Mhz AMD K6 with a First Mainboard VA-503+ and an
Intel EtherExpress 16 NIC (which AFAIK is 10Mbit/sec only).

These two machines are connected back to back with a cross-pinned
cable.  After bring up the interfaces on both machines, running
tulip-diag on pelvoux reports using the MII port, half-duplex,
transmitter idle and receiver waiting for packets.

The first problem is that pelvoux cannot ping bonehead at this stage.
After trying the ping, pelvoux (with the FA310TX) reports the correct
number of packets transmitted (though each would presumably be an ARP
request rather than the ICMP request) but bonehead doesn't report
receiving them!  Looks like it could be problem with the FA310TX
sending broadcasts.

If I go to bonehead and ping pelvoux it works, and after that I can
ping bonehead from pelvoux, presumably because pelvoux has discovered
the correct ethernet address from the incomming packets.

The next test that fails is to send a long stream of TCP data from
pelvoux (with the FA310TX) to bonehead.  Initially I noticed this
problem with FTP, but to reproduce it reliably I found the following
quite effective:

pelvoux$ rsh bonehead "cat > /dev/null" < /dev/zero

Whilst this transfer is going on, querying eth0 on pelvoux shows an
alarming large number of collisions, e.g:

pelvoux:~# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:A0:CC:5E:F4:3D  
          inet addr:10.0.0.1  Bcast:10.0.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:119706 errors:0 dropped:0 overruns:0 frame:0
          TX packets:244596 errors:54 dropped:0 overruns:0 carrier:0
          collisions:212030 txqueuelen:100 
          Interrupt:11 Base address:0xcc00 

Not long after that pelvoux reports:

May  4 21:50:58 localhost kernel: eth0: Transmit timeout using MII device.

and the transfer halts.  This message is repeated at intervals but
nothing seems to fix the problem short of taking the interface down
and bring it up again.  At this stage tulip-diag reports:

 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.

At about the same time, bonehead reports:

  eth0: tx interrupt but no status

After a quick look at tulip.c I found where it stops and restarts the
transmitter upon getting the timeout but even after waiting 100 bus
cycles between the stop and re-start the transmitter remains in state
"waiting for TX to finish".

The driver I have is tulip.c:v0.91g-ppc 7/16/99 which is bundled with
the 2.2.14 kernel I am using.  I have also tried the modified one
supplied by Netgear - it fixes neither of the two problems
(broadcast/ARP and the transmitter lockup).

Has anyone else made any progress on these problems or have any ideas
what I can try next in an effort to fix them?




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