[vortex] AST Bravo cannot detect 3c905B-TX (must be a PCI problem)

Alessandro Selli gaglioffo@interfree.it
Wed Nov 28 14:53:00 2001


  I apology if the following is too long, but I wanted to provide you with all
possible information concerning the problem I'm facing.  It cannot be a
drivers' fault and neither it is a net card malfunction, the culprit mus lie
in the motherboard/BIOSs' PCI bus setting.

  I tried to setup a LAN between two PCs, a Pentium 200 AST Bravo 5166 and
another one I assembled mostly from refuse/second hand parts (the mother board
is an MVP7598, VIA chipset and an AMDK6-2/400 cpu).  I have three 3Com
3c905B-TX  "Cyclone" cards.  On both computers I installed Debian 2.2r4,
kernel 2.2.20.  The AMD computer recognizes the network card correctly and
configures it to use io_add 0xe800 and irq 10, the AST just does not, as if the
card was not there.  I tried to swap the ethernet cards between the two
computers to no avail.  Both computers' BIOSes are set to "no PnP OS".

  On the AST I first tried to compile the driver built-in in the kernel.  In the
dmesg I find:

3c59x.c:v0.99U 7/30/2001 Donald Becker, becker@scyld.com http://www.scyld.com/network/vortex.html

but nothing about any eth0 3Com card.  Same result when I tried to pass the
driver the following parameters from Lilo:  ether=10,0xe800,0,0,eth0 .
So I made the driver a module to load it by hand.  I read in
http://scyld.com/network/vortex.html  that the correct parameter to pass the
driver for a 3c905B-Tx to set its media type is:

8    Cyclone internal transceiver (the correct type for most 3c905B chips)

So I try:

[root@obscuritas ~/problems/ethernet]# insmod 3c59x options=8
Using /lib/modules/2.2.20/net/3c59x.o
/lib/modules/2.2.20/net/3c59x.o: init_module: Device or resource busy
Hint: this error can be caused by incorrect module parameters, including invalid IO or IRQ parameters

  I also downloaded and compiled 3Coms' own driver:

[root@obscuritas ~/problems/ethernet]# insmod 3c90x media_select=4
Using /lib/modules/2.2.20/net/3c90x.o
/lib/modules/2.2.20/net/3c90x.o: init_module: Device or resource busy
Hint: this error can be caused by incorrect module parameters, including invalid IO or IRQ parameters


  I then updated the 3x59x driver with the latest one I found from
www.scyld.com/network/vortex.html:

[root@obscuritas /usr/src/modules]# gcc -DMODULE -D__KERNEL__ -O6 -c 3c59x.c -I/usr/src/linux/include -include /usr/src/linux/include/linux/modversions.h
[root@obscuritas /usr/src/modules]# gcc -DMODULE -D__KERNEL__ -O6 -c pci-scan.c -I/usr/src/linux/include -include /usr/src/linux/include/linux/modversions.h
In file included from pci-scan.c:53:
/usr/src/linux/include/linux/module.h:18: warning: `_set_ver' redefined
/usr/src/linux/include/linux/modsetver.h:9: warning: this is the location of the previous definition
[root@obscuritas /usr/src/modules]# insmod pci-scan.o
[root@obscuritas /usr/src/modules]# insmod 3c59x.o options=8
3c59x.o: init_module: Device or resource busy
Hint: this error can be caused by incorrect module parameters, including invalid IO or IRQ parameters



  I then checked the PCI bus:

Mon, 26 Nov 2001  18:46:57  Exit status: 0 Jobs: 5 tty: 2
ambapali@obscuritas ~/technical-stuff>$ /sbin/lspci -vx
00:00.0 Host bridge: Intel Corporation 430HX - 82439HX TXC [Triton II] (rev 03)
        Flags: bus master, medium devsel, latency 64
00: 86 80 50 12 06 01 00 22 03 00 00 06 00 40 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:07.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] (rev 01)
        Flags: bus master, medium devsel, latency 0
00: 86 80 00 70 0f 00 80 02 01 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:07.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] (prog-if 80 [Master])
        Flags: bus master, medium devsel, latency 64
        I/O ports at afa0
00: 86 80 10 70 05 00 80 02 00 80 01 01 00 40 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: a1 af 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:08.0 VGA compatible controller: ATI Technologies Inc 264VT [Mach64 VT] (rev 48) (prog-if 00 [VGA])
        Subsystem: ATI Technologies Inc: Unknown device 5654
        Flags: VGA palette snoop, stepping, medium devsel
        Memory at fd000000 (32-bit, non-prefetchable)
        I/O ports at fc00
00: 02 10 54 56 a3 00 80 02 48 00 00 03 00 00 00 00
10: 00 00 00 fd 01 fc 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 02 10 54 56
30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 01 00 00


  I'm not any expert in PCI configuration, even after reading the PCI-HOWTO,
but I see nothing concerning the 3Com card.  I do  man 8 lspci  and I find
about the -M switch and direct hardware access methods:

       -M     Invoke  bus mapping mode which scans the bus exten-
              sively to find all devices including  those  behind
              misconfigured bridges etc. Please note that this is
              intended only for debugging and as it can crash the
              machine  (only in case of buggy devices, but unfor-
              tunately these happen  to  exist),  it's  available
              only  to  root. Also using -M on PCI access methods
              which don't directly  touch  the  hardware  has  no
              sense  since the results are (modulo bugs in lspci)
              identical to normal listing modes.

       -H1    Use  direct hardware access via Intel configuration
              mechanism 1. (i386 and compatible only)

       -H2    Use direct hardware access via Intel  configuration
              mechanism  2.  Warning:  This  method  is  able  to
              address only first 16 devices on  any  bus  and  it
              seems  to  be very unrealiable in many cases. (i386
              and compatible only)


  I try them out:


[root@obscuritas ~/problems/ethernet]# lspci -H1 -M
lspci: This access method is not supported.
[root@obscuritas ~/problems/ethernet]# lspci -H2 -M
00:00.0 Host bridge: Intel Corporation 430HX - 82439HX TXC [Triton II] (rev 03)
00:07.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] (rev 01)
00:07.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:08.0 VGA compatible controller: ATI Technologies Inc 264VT [Mach64 VT] (rev 48)

Summary of buses:

00: Primary host bus


  Still no trace of the 3c905B.  I go back at Donald Beckers web page,
http://www.scyld.com/network/vortex.html, where I find his diagnostic tools:
vortex-diag, covering the 3c905B, pci-config and mii-diag.
I compile them with:

gcc -O -Wall -o pci-config pci-config.c
gcc -DMODULE -D__KERNEL__ -DEXPORT_SYMTAB -Wall -Wstrict-prototypes -O6 -c pci-scan.c
gcc -O3 -Wall -o vortex-diag vortex-diag.c -DLIBMII libmii.c  -DLIBFLASH libflash.c
gcc -Wall -Wstrict-prototypes -O mii-diag.c -DLIBMII libmii.c -o mii-diag

... and try them out:

[root@obscuritas ~/problems/ethernet]# vortex-diag
vortex-diag.c:v2.05 5/15/2001 Donald Becker (becker@scyld.com)
 http://www.scyld.com/diag/index.html
Unable to find a recognized card in /proc/pci.
If there is a card in the machine, explicitly set the I/O port address
  using '-p <ioaddr> -t <chip_type_index>'
 Use '-t -1' to see the valid chip types.


vortex-diag -t -1  tells me the right chip set index number for my card is:

   14    3c905B Cyclone 100baseTx


  I try it with the port number the AMD configured its 3c905B card to use:

[root@obscuritas ~/problems/ethernet]# vortex-diag -p 0xe800 -t 14
vortex-diag.c:v2.05 5/15/2001 Donald Becker (becker@scyld.com)
 http://www.scyld.com/diag/index.html
Assuming a 3c905B Cyclone 100baseTx adapter at 0xe800.
 Use '-a' or '-aa' to show device registers,
     '-e' to show EEPROM contents, -ee for parsed contents,
  or '-m' or '-mm' to show MII management registers.

[root@obscuritas ~/problems/ethernet]# vortex-diag -p 0xe800 -t 14 -ee
vortex-diag.c:v2.05 5/15/2001 Donald Becker (becker@scyld.com)
 http://www.scyld.com/diag/index.html
Assuming a 3c905B Cyclone 100baseTx adapter at 0xe800.
EEPROM contents (64 words, offset 0):
 0x000: ffff ffff ffff ffff ffff ffff ffff ffff
 0x008: ffff ffff ffff ffff ffff ffff ffff ffff
 0x010: ffff ffff ffff ffff ffff ffff ffff ffff
 0x018: ffff ffff ffff ffff ffff ffff ffff ffff
 0x020: ffff ffff ffff ffff ffff ffff ffff ffff
 0x028: ffff ffff ffff ffff ffff ffff ffff ffff
 0x030: ffff ffff ffff ffff ffff ffff ffff ffff
 0x038: ffff ffff ffff ffff ffff ffff ffff ffff
 The word-wide EEPROM checksum is 0xffc0.
Saved EEPROM settings of a 3Com Vortex/Boomerang:
 3Com Node Address FF:FF:FF:FF:FF:FF (used as a unique ID only).
 OEM Station address ff:FF:FF:FF:FF:FF (used as the ethernet address).
 Manufacture date (MM/DD/YYYY) 15/31/2027, division ÿ, product ÿÿ.
 Options: force full duplex, link beat check disabled.
  Vortex format checksum is incorrect (0000 vs. ffff).
  Cyclone format checksum is incorrect (00 vs. 0xff).
  Hurricane format checksum is incorrect (00 vs. 0xff).


 
[root@obscuritas ~/problems/ethernet]# vortex-diag -p 0xe800 -t 14 -a -f
vortex-diag.c:v2.05 5/15/2001 Donald Becker (becker@scyld.com)
 http://www.scyld.com/diag/index.html
Assuming a 3c905B Cyclone 100baseTx adapter at 0xe800.
Initial window 7, registers values by window:
  Window 0: ffff ffff ffff ffff ffff ffff ffff ffff.
  Window 1: ffff ffff ffff ffff ffff ffff ffff ffff.
  Window 2: ffff ffff ffff ffff ffff ffff ffff ffff.
  Window 3: ffff ffff ffff ffff ffff ffff ffff ffff.
  Window 4: ffff ffff ffff ffff ffff ffff ffff ffff.
  Window 5: ffff ffff ffff ffff ffff ffff ffff ffff.
  Window 6: ffff ffff ffff ffff ffff ffff ffff ffff.
  Window 7: ffff ffff ffff ffff ffff ffff ffff ffff.
Vortex chip registers at 0xe800
  0xE810: ffffffff ffffffff ffffffff ffffffff
  0xE820: ffffffff ffffffff ffffffff ffffffff
  0xE830: ffffffff ffffffff ffffffff ffffffff
 Indication enable is ffff, interrupt enable is ffff.
 Interrupt sources are pending.
   Interrupt latch indication.
   Adapter Failure indication.
   Tx Complete indication.
   Tx Available indication.
   Rx Complete indication.
   Rx Early Notice indication.
   Driver Intr Request indication.
   Statistics Full indication.
   DMA Done indication.
   Download Complete indication.
   Upload Complete indication.
   DMA in Progress indication.
   Command in Progress indication.
 Transceiver/media interfaces available:  100baseT4 100baseTx 100baseFx 10baseT 10base2 AUI MII .
Transceiver type in use:  undefined-15.
 MAC settings: full-duplex, Large packets permitted, 802.1Q flow control, VLT VLAN enabled.
Maximum packet size is 65535.
 Station address set to ff:ff:ff:ff:ff:ff.
 Configuration options ffff.


  Lastly:


[root@obscuritas ~/problems/ethernet]# mii-diag
Using the default interface 'eth0'.
SIOCGMIIPHY on eth0 failed: No such device



  At this point I gave up and started writing this message.
  Thank you for considering it.  I perused the mailing lists archive, but I
found nothing like what I'm experiencing in the past five or six months I
searched and continuing the search was quite time consuming.




  Sandro




-- 
Bellum se ipsum alet.
        La guerra nutre se stessa.

Livio, "Ab urbe condita", XXXIV,9