[nSLUG] NIC problem: 3C905B fails to connect
budman85 at eastlink.ca
Tue Nov 14 18:54:27 AST 2006
On Tue, 2006-11-14 at 01:59 -0400, Mike Spencer 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.
What speed is it eventually running at?
There was a problem with auto negotiation on these cards a while back.
Try setting it to 100 or 10 to see its toggling.
> 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.
Rich <budman85 at eastlink.ca>
More information about the nSLUG