[tulip] NetGear FA310TX Tulip card won't work with SiS730S chipset/bios

Tue, 09 Oct 2001 00:26:05 +0100

Hi there,
I usually manage to avoid having to post to newsgroups like this one, as
answers are often found in previous posts, but I've tried long and hard to
get my NetGear FA310TX card running with my new AMD 800 MHz Duron machine
(Bios: AMIBIOS, version 1.21.04), and have had absolutely no luck.

Previously, I had been running Linux (RedHat 7.0, kernel version 2.2.16) on
a Dell Optiplex Pentium 233MMX with a RealTek 8139c NIC card, talking to a
Windows 98 machine, and everything was fine.

However, with my new machine, I was unable to get any response when I
booted up the same version of Linux on the new AMD Sis730S machine and
tried to ping my Win98 machine, receiving "Destination Host Unreachable".
When I booted this new machine into Windows 98, everything was fine, and I
could see/ping the other Win98 machine.

Well, I thought maybe it was something to do with the card itself (there
was no link light - I later put this down to an old driver, as I was able
to get a link light after I recompiled the kernel), so I swapped it for a
new NetGear FA310TX card (I should point out that the new machine actually
has onboard networking support, but I couldn't get that going under Linux
either).

Looking through the How-Tos (particularly the "Linux Ehternet-Howto" by
Paul Gortmaker), I found a number of things to try:

1. Thinking the problem may be due to old drivers/kernel, I compiled a
newish kernel (version 2.4.8) with module support for the three networking
options I had:- the SiS900 driver (version 1.07.04a - fresh from the SiS
website) for the on-board SiS730S networking, RT8139too for the RealTek
8139c card, and tulip (version 0.9.15-pre6) for the FA310TX card.
Trying each combination of these cards/onboard networking (and in each PCI
slot) didn't work with this new Kernel, although the appropriate driver was
loaded when examining the results of "cat /proc/ioports" (and there were no
overlaps in the address ranges).
As the modules didn't seem to work, I recompiled the kernel, this time
building support for the three drivers into the kernel itself,
doublechecking in  modules.dep and modules.conf that Linux wasn't trying to
load the driver alongside the one on the kernel - still no joy.

2. Dmesg showed no problems during boot, and each time the correct driver
appeared to be loaded when looking at the results of "cat proc/ioports"
(when using the FA310TX card, the driver was reported as "Lite-On
Communications Inc LNE100TX" on one line for address range cc00-ccff, and
then as "tulip" for the same address range, slight indented, on the next
line down. Dmesg reports as follows:

Linix Tulip driver version 0.9.15-pre6 (July 2, 2001)
PCI: Found IRQ 11 for device 00:09:0
tulip0: MII transceiver #1 config 3000 status 7829 advertising 01e1.
eth0: Lite-On 82c168 PNIC rev 32 at 0xcc00, 00:A0:CC:DA:5D:51, IRQ 11.

3. I can bring eth0 up and down using ifconfig with no problems, and my
internet address is 192.168.0.1, netmask is 255.255.255.0, broadcast
address is 192.168.0.255, and reports that it is using Interrupt 11, Base
address:0xcc00. 

4. Looking at the results of "cat /proc/interrupts", I see an increase in
the number of interrupts for eth0 after each (failed) attempt to ping my
Win98 machine (which, incidentally can't ping back either). I am able to
ping myself sucessfully, but I don't think this is any real test.

5. Looking at the results of "cat /proc/net/dev", I see no errors or
dropped packets.

4. Reading that the "Plug and Play Aware O/S" BIOS setting might be
screwing things up, I set this to "No" - still no luck (I was quite hopeful
with this one).

Running the Tulip diagnostic program, I receive the results below (using
the -a, -ee, and -m switches in succession) - it does mention "EEPROM does
not contain transceiver control information" - maybe this is a clue?

The hub between the two machines is a Unex NexHub HA050, although I don't
think this is relevant.

I really need help with this one. Although I'm usually quite resourceful,
this one's got me beat - I figure it must be some issue with the BIOS/SiS
chipset that causing things to not work - any help would be appreciated.

Regards,

Jason Darwin

Tulip diagnostic program output: 

tulip-diag.c:v2.08 5/15/2001 Donald Becker (becker@scyld.com)
 http://www.scyld.com/diag/index.html
Index #1: Found a Lite-On 82c168 PNIC adapter at 0xcc00.
 * A potential Tulip chip has been found, but it appears to be active.
 * Either shutdown the network, or use the '-f' flag to see all values.
Lite-On 82c168 PNIC chip registers at 0xcc00:
 0x00: 00008000 01ff0000 00450008 06f7e000 06f7e200 02660010 814c2002 0001fbef
 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 'Idle'.
  The transmit threshold is 72. tulip-diag.c:v2.08 5/15/2001 Donald Becker
(becker@scyld.com)
 http://www.scyld.com/diag/index.html
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 'Idle'.
  The transmit threshold is 72.
 A simplifed EEPROM data table was found.
 The EEPROM does not contain transceiver control information.
EEPROM contents (64 words):
0x00:  00a0 ccda 5d51 f004 1385 00f1 0000 2f0c
0x08:  0000 0000 0000 0000 0000 0000 0000 0000
0x10:  0000 0000 0000 0000 0000 0000 0000 0000
0x18:  0000 0000 0000 0000 0000 0000 0000 0000
0x20:  0000 0000 0000 0000 0000 0000 0000 0000
0x28:  0000 0000 0000 0000 0000 0000 0000 0000
0x30:  0000 0000 0000 0000 0000 0000 0000 0000
0x38:  0000 0000 0000 0000 0000 0000 0000 0000
 ID block CRC 0x70 (vs. 00).
  Full contents CRC 0xa380 (read as 0x0000). tulip-diag.c:v2.08 5/15/2001
Donald Becker (becker@scyld.com)
 http://www.scyld.com/diag/index.html
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 'Idle'.
  The transmit threshold is 72.
 MII PHY found at address 1, status 0x782d.
 MII PHY #1 transceiver registers:
   1000 782d 0040 6212 01e1 0021 0000 0000
   0000 0000 0000 0000 0000 0000 0000 0000
   5000 0000 0000 0000 0000 0000 0400 0000
   0038 8006 0f00 ff00 0028 4000 0080 000b.