[nSLUG] NIC problem: 3C905B fails to connect

Rich 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?
>          PEBKAC?
> 
> 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
>                  10/100
> 
> 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
>         autonegotiate.
> 
>     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>

!DSPAM:455a504d101213143815519!




More information about the nSLUG mailing list