[vortex] Problems detecting 100Mbps with 3c59x (Vortex)

CJ Kucera pez@apocalyptech.com
Mon Dec 30 11:35:00 2002


Hello, everyone...

I've got a couple of "3c595 100BaseTX [Vortex]" cards which have to be
coerced very strongly into believing they're on a 100BaseTx-FD network.
I've got a 100Mbps hub/swtich (just some cheap thing from Netgear) which
works fine for my other 100Mbps network cards (my other PCs autodetect
the rate just fine).  Here's the output from mii-diag on another PC on
the network plugged into the same switch as the 3c595 card:

> Using the default interface 'eth0'.
> Basic registers of MII PHY #1:  1000 782d 02a8 0150 05e1 45e1 0001 ffff.
>  The autonegotiated capability is 01e0.
> The autonegotiated media type is 100baseTx-FD.
>  Basic mode control register 0x1000: Auto-negotiation enabled.
>  You have link beat, and everything is working OK.
>  Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control.
>    End of basic transceiver information.

I tried swapping cables with one that I know works fine on the network,
and most recently I've moved one of the cards to another PC, just to make
sure that the problem wasn't with the PC itself.  Here's the card's entry
from /proc/pci:

>   Bus  0, device   9, function  0:
>     Ethernet controller: 3Com Corporation 3c595 100BaseTX [Vortex] (rev 0).
>       IRQ 10.
>       Master Capable.  Latency=32.  Min Gnt=3.Max Lat=8.
>       I/O at 0xb800 [0xb81f].

This is on a Linux Debian system running kernel 2.4.20.  The box the card
is currently in is a 233MHz Cyrix MII processor; the other machine is
a 90MHz Pentium.

At first, I was using the 3c59x driver included in the sources for the
2.4.20 kernel, which reports its version as "LK1.1.16."  Using these
sources, I could *not* get the card to respond to 100Mbps traffic at all.
The link light on the card itself was stuck at 10Mbps.  I have tried both
using the driver as a module and compiled directly into the kernel.
Since the autodetection wasn't working, I tried passing options into the
module as "options=4 full_duplex=1."  When inserting the module, things
looked promising:

> 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
> 00:09.0: 3Com PCI 3c595 Vortex 100baseTx at 0xb800. Vers LK1.1.16
> 00:09.0: Overriding PCI latency timer (CFLT) setting of 32, new value is 248.
> 00:09.0:  Media override to transceiver type 4 (100baseTX).

However, running "mii-diag -v" produced less than stellar results:

> mii-diag.c:v2.07 11/15/2002 Donald Becker (becker@scyld.com)
>  http://www.scyld.com/diag/index.html
>   Using the new SIOCGMIIPHY value on PHY 0 (BMCR 0x0000).
>  The autonegotiated capability is 0000.
> No common media type was autonegotiated!
> This is extremely unusual and typically indicates a configuration error.
> Perhaps the advertised capability set was intentionally limited.
>  Basic mode control register 0x0000: Auto-negotiation disabled, with
>  Speed fixed at 10 mbps, half-duplex.
>  Basic mode status register 0xffff ... ffff.
>    Link status: established.
>    This transceiver is capable of  100baseT4 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
>    Able to perform Auto-negotiation, negotiation complete.
>  Remote fault detected!
>    *** Link Jabber! ***
>  Your link partner advertised ffff: Flow-control 100baseT4 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control.
>    End of basic transceiver information.
> 
>  MII PHY #0 transceiver registers:
>    0000 ffff 0000 ffff 0000 ffff 0000 ffff
>    0000 ffff 0000 ffff 0000 ffff 0000 ffff
>    0000 ffff 0000 ffff 0000 ffff 0000 ffff
>    0000 ffff 0000 ffff 0000 ffff 0000 ffff

So there's definitely some kind of problem there.  Running
"vortex-diag -aef", I notice that it gives me conflicting kinds of
transceivers:

> vortex-diag.c:v2.13a 12/15/2002 Donald Becker (becker@scyld.com)
>  http://www.scyld.com/diag/index.html
> Index #1: Found a 3Com 3c595 Vortex 10/100baseTx adapter at 0xb800.
>  Station address 00:a0:24:a4:2b:2b.
>   Receive mode is 0x07: Normal unicast and all multicast.
> Initial window 4, registers values by window:
>   Window 0: 0000 0000 0000 0000 0000 00bf 0000 0000.
>   Window 1: ffff 02d5 0000 0c80 0001 8882 0200 8000.
>   Window 2: a000 a424 2b2b 0000 0000 0000 00de 4000.
>   Window 3: 001b 0041 0000 0020 e10a bfff 3fff 6000.
>   Window 4: 0000 02d5 0000 0c80 0001 8882 0200 8000.
>   Window 5: 1ffc 1ffc 00de 1ffc 0007 02de 00de a000.
>   Window 6: 0000 0000 0000 5f00 0000 16d5 0089 c000.
>   Window 7: 0000 0000 0000 0000 8000 00ff 0000 e000.
> Vortex chip registers at 0xb800
>   0xB810: 00002020 00000000 00008000 00003ffc
>  Indication enable is 00de, interrupt enable is 02de.
>  No interrupt sources are pending.
>  Transceiver/media interfaces available:  100baseTx 10baseT.
> Transceiver type in use:  100baseTX.
>  MAC settings: full-duplex.
> Maximum packet size is 0.
>  Station address set to 00:a0:24:a4:2b:2b.
>  Configuration options 00de.
> Setting the EEPROM BIOS ROM field to 0000, new checksum ff.
>  Would write new 19 entry 0xff01 (old value 0x0001).
>  Would write new 32 entry 0x00ff (old value 0x0000).
> Saved EEPROM settings of a 3Com Vortex/Boomerang:
>  3Com Node Address 00:A0:24:A4:2B:2B (used as a unique ID only).
>  OEM Station address 00:A0:24:A4:2B:2B (used as the ethernet address).
>   Device ID 5950,  Manufacturer ID 6d50.
>   Manufacture date (MM/DD/YYYY) 6/5/1996, division 6, product BU.
>   No BIOS ROM is present.
>  Transceiver selection: 10baseT.
>    Options: negotiated duplex, link beat required.
>   Vortex format checksum is correct (ee vs. ee).
>   Cyclone format checksum is correct (00 vs. 00).
>   Hurricane format checksum is correct (00 vs. 00).

Looking around on the Vortex homepage at scyld.org, I noticed that
the version of the driver shipped with 2.4.20 is a bit out of date,
so I downloaded the "current" version (labeled "0.99Xf") and tried that
one out.  Without giving any options to the insmod or modprobe line,
this driver functioned the same as the older driver.  The link light
on the back of the NIC was giving me 10Mbps, and the mii-diag and
vortex-diag programs gave similar results.  However, adding the
"options=4 full_duplex=1" arguments into the module seemed to produce
the correct results.  Here's the modprobe:

> pci-scan.c:v1.11 8/31/2002  Donald Becker <becker@scyld.com> http://www.scyld.com/linux/drivers.html
> 3c59x.c:v0.99Xf 11/17/2002 Donald Becker, becker@scyld.com
>   http://www.scyld.com/network/vortex.html
> eth0: Overriding PCI latency timer (CFLT) setting of 32, new value is 248.
> eth0: 3Com 3c595 Vortex 100baseTx at 0xb800,  00:a0:24:a4:2b:2b, IRQ 10
>   64K buffer 1:1 Rx:Tx split, autoselect/10baseT interface.
>   Media override to transceiver type 4 (100baseTX).
> PCI: Setting latency timer of device 00:09.0 to 32

And here's the output of "mii-diag -v":

> Using the default interface 'eth0'.
> mii-diag.c:v2.07 11/15/2002 Donald Becker (becker@scyld.com)
>  http://www.scyld.com/diag/index.html
>   Using the new SIOCGMIIPHY value on PHY 32 (BMCR 0x2100).
>  Basic mode control register 0x2100: Auto-negotiation disabled, with
>  Speed fixed at 100 mbps, full-duplex.
>  You have link beat, and everything is working OK.
>    This transceiver is capable of  100baseTx-FD 100baseTx 10baseT-FD 10baseT.
>    Unable to perform Auto-negotiation, negotiation not complete.
>  Link partner information is not exchanged when in fixed speed mode.
>    End of basic transceiver information.
> 
>  MII PHY #32 transceiver registers:
>    2100 7804 0280 9000 0000 0000 0000 0000
>    0000 0000 0000 0000 0000 0000 0000 0000
>    0000 0000 0000 0000 0000 0000 0000 0000
>    0000 0000 0000 0000 0000 0000 0000 0000

And here's "vortex-diag -aef" (though note that there seems to be the
same kind of transciever mismatch as before):

> vortex-diag.c:v2.13a 12/15/2002 Donald Becker (becker@scyld.com)
>  http://www.scyld.com/diag/index.html
> Index #1: Found a 3Com 3c595 Vortex 10/100baseTx adapter at 0xb800.
>  Station address 00:a0:24:a4:2b:2b.
>   Receive mode is 0x07: Normal unicast and all multicast.
> Initial window 4, registers values by window:
>   Window 0: 0000 0000 0000 0000 0000 00bf 0000 0000.
>   Window 1: 00cc 02d4 0000 0c80 0000 8882 0000 8000.
>   Window 2: a000 a424 2b2b 0000 0000 0000 00de 4000.
>   Window 3: 001b 0041 0000 0020 e10a bfff 3fff 6000.
>   Window 4: 0000 02d4 0000 0c80 0000 8882 0000 8000.
>   Window 5: 1ffc 1ffc 00de 1ffc 0007 02de 00de a000.
>   Window 6: 0000 0000 0000 3000 0000 0b40 0000 c000.
>   Window 7: 0000 0000 0000 0000 8000 00ff 0000 e000.
> Vortex chip registers at 0xb800
>   0xB810: 00000105 00000000 00008000 00003ffc
>  Indication enable is 00de, interrupt enable is 02de.
>  No interrupt sources are pending.
>  Transceiver/media interfaces available:  100baseTx 10baseT.
> Transceiver type in use:  100baseTX.
>  MAC settings: full-duplex.
> Maximum packet size is 0.
>  Station address set to 00:a0:24:a4:2b:2b.
>  Configuration options 00de.
> Setting the EEPROM BIOS ROM field to 0000, new checksum ff.
>  Would write new 19 entry 0xff01 (old value 0x0001).
>  Would write new 32 entry 0x00ff (old value 0x0000).
> Saved EEPROM settings of a 3Com Vortex/Boomerang:
>  3Com Node Address 00:A0:24:A4:2B:2B (used as a unique ID only).
>  OEM Station address 00:A0:24:A4:2B:2B (used as the ethernet address).
>   Device ID 5950,  Manufacturer ID 6d50.
>   Manufacture date (MM/DD/YYYY) 6/5/1996, division 6, product BU.
>   No BIOS ROM is present.
>  Transceiver selection: 10baseT.
>    Options: negotiated duplex, link beat required.
>   Vortex format checksum is correct (ee vs. ee).
>   Cyclone format checksum is correct (00 vs. 00).
>   Hurricane format checksum is correct (00 vs. 00).

Using the newer driver, the link light on the back of the NIC is on
100Mbps.

Now, you may be asking yourselves, "Why is this guy complaining now
that everything seems to be working fine?"  Basically, because the box
these NICs are going to be in will be functioning as a firewall machine,
and I don't want to enable loadable modules on that box.  There are a
number of Linux rootkits which function by loading a module into the kernel,
which makes things much more difficult to recover from, so I typically
leave modules off on firewall-like systems, in the event it's ever
compromised.  My problem is that I've had relatively little luck getting
the newer driver to compile into the kernel itself.  So, here are my
questions:

  1) Is it possible to have the newer 3c59x driver compile into the kernel,
     not as a module?

  2) If not, is there some way to get the older 3c59x driver to behave
     properly?

  3) At any rate, why isn't the proper speed of the network being
     autodetected by *either* of the drivers?  The only way I've been able
     to get things running properly is by forcing the options.

Any help you could give would be much appreciated.  And of course, let
me know if there's any other commands I can run to help shed some more light
on my setup here.

Thanks in advance,
CJ

-- 
WOW: Kakistocracy        |  "The ships hung in the sky in much the same
apocalyptech.com/wow     |    way that bricks don't." - Douglas Adams,
pez@apocalyptech.com     |     _The Hitchhiker's Guide To The Galaxy_