[nSLUG] NIC problem: 3C905B fails to connect
mspencer at tallships.ca
Tue Nov 14 01:59:06 AST 2006
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
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?
Cable? (But the cable works fine on another box.)
Grateful for any pointers,
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.)
+ 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
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.
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 /( )\
More information about the nSLUG