[nSLUG] NIC problem: 3C905B fails to connect

Mike Spencer 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
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/                        ^^-^^

!DSPAM:45595b1a24781028517824!




More information about the nSLUG mailing list