[nSLUG] NIC problem: 3C905B fails to connect

Rick Burdon burdonrc at gmail.com
Tue Nov 14 14:45:50 AST 2006


My bet is you have a bad card.  We have had numerous 3com cards, where I
work, that do just that.  The funny thing is, if you remove it from power
long enough, try it again and it will work for a while.

Rick

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?
>          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.
>
>
> --
> Michael Spencer                  Nova Scotia, Canada       .~.
>                                                            /V\
> mspencer at tallships.ca                                     /( )\
> http://home.tallships.ca/mspencer/                        ^^-^^
>
>
>
> _______________________________________________
> nSLUG mailing list
> nSLUG at nslug.ns.ca
> http://nslug.ns.ca/cgi-bin/mailman/listinfo/nslug
>
> 
>
>


-- 
Thanks

Rick Burdon
PC Headquarters (pchq.ca)
Burdon Network One (BnetOne)


!DSPAM:455b0125157481601320927!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nslug.ns.ca/mailman/private/nslug/attachments/20061114/9b566523/attachment-0002.html>


More information about the nSLUG mailing list