[nSLUG] NIC problem: 3C905B fails to connect
D G Teed
donald.teed at gmail.com
Tue Nov 14 21:29:44 AST 2006
When I lived in Northern Ontario I would spend that much time
trying to get a NIC card up, because the alternative was hunting
down an inexpensive NIC in the boonies. But today I'd pick
up a $12 PCI card a little bigger than a baby spoon and
toss the other one away.
This problem reminds me of one I saw before in an ISA
3COM card handled by the same driver. In that case, I
had to use 3COM's dos utilities diskette and explore the
I/O address and IRQ, and assign to the same in LILO
arguments. I don't know if you can do the same for
a PCI part.
3COM's diagnostic diskette allows you to run a NIC
tester from the bootable diskette, and if there is a Windows
box around, you can run the other half of the
peer to peer test to see if the hardware is reliable.
Look at /usr/src/linux-2.6.18/Documentation/networking/3c509.txt
(or whatever kernel source and path works for you)
for more hints. It discusses checking
full duplex, no received packets conditions
and interrupts problems.
But overall, I'd think it just isn't worth the effort.
There is a good chance a NIC this old is just
On 11/14/06, Mike Spencer <mspencer at tallships.ca> wrote:
> I have a NIC problem.
> A 3Com 3C905B in an IBM NetVista PIII box with driver 3c59x.o
> INTERMITTENTLY fails to contact my router at boot. When the connection
> comes up, it works perfectly. When it doesn't, nothing I can do will
> make it connect. Nothing I've tried will cause it to reboot to a
> working connection.
> Sometimes, apparently independent of anything I've done, it will just
> start working. Then it continues to work perfectly until shutdown.
> If I ping another box on my LAN when it's not working, tcpdump -i eth0
> shows arp who-has requests going through eth0 but no replies coming
> in. Subsequently arp -a shows the target host as "at <incomplete> on
> eth0". [More boring details below.]
> So: I've thought of these questions:
> Does an IBM NetVista PIII have known problems with Linux, PCI
> handling, NICs, whatever?
> Jim Haliburton wrote deprecatingly of 3Com NICs a couple-three years
> ago. Any new info that would help me, Jim? Or anyone else?
> What's the most likely source of the problem?
> Router bug or failure?
> NetVista IBM bug or defect?
> NIC bug or defect?
> Driver bug?
> Cable? (But the cable works fine on another box.)
> Kernel incompatibility?
> Grateful for any pointers,
> - Mike
> Boring details for the intrepid
> Box: IBM NetVista
> Everything else works fine (except I haven't tried sound yet).
> CPU: Intel PIII
> System: Slackware 10.1, Linux kernel 2.4.29
> HD: I forget but I think it's a newish 80G
> Router: D-Link DL713P wireless/wired 10/100
> NIC: 3C905B vortex-diag says: 3c905B Cyclone 100BaseTX
> lspci says: 3Com 3C905B Fast Etherlink XL
> dmesg: Shows nothing helpful
> NIC IRQ: lspci -v shows IRQ5, not shared with anything else.
> Driver: 3c59x.o (Donald Becker et al.)
> Start-up alternatives:
> + Via hotplug: driver module loads ok but... doesn't work
> + alias eth0 3c59x in /etc/modules.conf doesn't work
> + alias eth0 3c59x full_duplex=1 in /etc/modules.conf doesn't work
> Log shows kernel setting full_duplex on eth0
> + manual modprobe, with or without options, doesn't work
> + manual modprobe, debug=7 doesn't work
> --> Puts "kernel: eth0: vortex_error, status=0xe081" in syslog
> many times. Googling for that, I get 6 hits, none of which
> helps any.
> Cat 5 cable works on another machine.
> Tried different cable: doesn't work
> Tried cable in different router port no change
> Rebooting the router: no change.
> Router works fine with 3 other wired and 2 other wireless connections.
> (I don't have a spare router to swap in.)
> Tried NIC in differnt PCI slot no change
> Donald Becker's vortex-diag:
> Output is mostly too technical and terse for me to grok.
> Reports (only in part, of course):
> Vortex format checksum is incorrect (001a vs. 10b7)
> Cyclone format checksum is correct
> Hurricane format checksum is correct
> Since this is a Cyclone card, I have no idea whether the
> "vortex format checksum" matters or means anything. Googling on
> "vortex format checksum incorrect" wasn't helpful.
> vortex-diag -v -R (reset chip) has no detectable effect.
> [ NOTE: It appears from the source that -R has no
> [ effect unless -v is also used. YMMV, caveat hackor etc.
> Known problems:
> Donald Becker's 3c59x.o doc (vortex.txt) says:
> Transmit error, Tx status register 82
> This is a common error which is almost always caused by
> another host on the same network being in full-duplex mode,
> while this host is in half-duplex mode. You need to find that
> other host and make it run in half-duplex mode or fix this
> host to run in full-duplex mode.
> As a last resort, you can force the 3c59x driver into
> full-duplex mode with
> options 3c59x full_duplex=1
> but this has to be viewed as a workaround for broken network
> gear and should only really be used for equipment which cannot
> That option workaround hasn't fixed the problem. I have no idea
> how to tell if the router is doing full-duplex or how force to do
> so if it isn't doing it automatically. And the error message in
> syslog is 0xe081, not 82.
> Michael Spencer Nova Scotia, Canada .~.
> mspencer at tallships.ca /( )\
> http://home.tallships.ca/mspencer/ ^^-^^
> nSLUG mailing list
> nSLUG at nslug.ns.ca
More information about the nSLUG