Adaptec Quartet 4 port ethernet cards under Linux and other multiport cards

This page has information on using Multiport Ethernet Cards under Linux including those by Adaptec (Cogent), Znyx, Phobos, D-link, and Matrox (not-suported) but with emphasis on the Adaptec Quartets. Many of these cards are availible in single port, dual port, quad port and some are availible in compact PCI as well. There is an 8 port hot swap compact PCI board with a 64 bit PCI interface as well; although it requires a rear transition module instead of bringing the connections out on the main bracket.

Note: Adeptec might have discontinued the tulip based quartets (see below on the DuraLAN/starfire based quartet64s as well as other manufacturers of tulip based cards). They were not listed on adaptecs fast ethernet web page.

The adaptec/cogent Quartet 4 port ethernet cards do work under Linux with recent versions of the tulip driver and a decent bios. Note that there have been a number of revisions of the 21143 chip so if you have a board based on that chip, make sure you are using a recent driver version.

This page is primarily about the Adaptec ANA-6904 (Cogent EM964TP) and ANA-6944/TX because those are the models I am have actually used. it also applies to the following quartet cards as well as cards by many other manufacturers:

Adaptec	Cogent	Bus	Media
ANA-6944A/TX	n/a	PCI 2.1 (pentium pro)	4x100BaseTX/10BaseT
ANA-6944/T4	EM440T4-PCI	PCI	4x100BaseT4/10BaseT
ANA-6940/TX	EM400TX-PCI	PCI	4x100BaseTX
ANA-6904/BNC	EM964BNC	PCI	4x10Base2
ANA-6904	EM964TP	PCI	4x10BaseT

There are two names because Adaptec ate Cogent and changed the model numbers.

Make sure you are using a recent version of the driver. The version included in many linux distributions (such as redhat 4.0) is too old. Visit Don Becker's tulip driver page for the latest release versions and the development page for the latest beta versions.

You may have problems if you are using a machine with an AMIBIOS. AMIBIOS is guilty of, in their words, "A legal misinterpretation of the [PCI] spec" that adversely affects devices, such as the quartet cards, which use a PCI to PCI bridge chip. AMI numbers the devices on the other side of bridge in the wrong order. For the quartet cards, this is a problem because the quartet only has an address on the first ethernet port and expects the driver to consequetively number the other three. If you get four ethernet addresses which are not consequetive (perhaps three are and one isn't) this is probably your problem. Don may have put in a patch to work around the defective BIOS. The correct ethernet address on the last port (really the first) is likely to begin with "00 00 92". The incorrect ones will be consequtively numbered starting from the hex equivalent of the text string '\0Linux' (I may not have the capitalization right). I.E. it will begin with "00 4C" or "00 6C". It appears that you can compile the driver with "-DREVERSE_PROBE" or insmod the module with "reverse_probe=1" on more recent tulip drivers to work around this bios bug.

The message "EEPROM not present" is not a cause for concern unless it occurs on the first port listed (in which case, see above). It is normal to get this message on ports 2 throuth 4.

Your bios may set up the ports to use 4 different interupts. This is more likely to be a problem with an AMIBIOS. I believe the driver has two options, one to renumber the ports to use one interrupt and the other to leave them at existing settings. There is a "#define" in the source code which needs to be changed. I think there might also have been another bug in the AMIBIOS that may have lead to interrupts not being properly set on the ports themselves which the driver can fix.

Adaptec/Cogent spec sheets are availible via the Adaptec web site.

Here are some of the distquishing markings on one of the cards (and key chips) which I have:

Emaster+ PCI QUARTET P/N 964001-0001  S/N 436241530
Cogent Data Technologies, Inc. (C) Copyright 1994 Made in U.S.A.
Digital 9616 D486651 VY0687 DECchip 21050 DC7526C
4x Digital 21040-AA DC1012B 21-40593-03 (c) DEC 1995 S15999-25 A 9636
HALO FD12-101G HIPOTED 9628 (ethernet interface)
Linear Tech LT1086CT-3.3 9601

Some of the chips on the 100Mb/s tulips get quite hot. The 21140s aren't too bad but the bridge chip and the 4 other large chips do get pretty hot.

I am using these boards with an Asus motherboard with AWARD bios.

If you want to use more than one quartet in a system, or use the quartet with any other ethernet card, you should be aware that by default the linux kernel only supported 4 ethernet devices (8 in 2.0.x). The 2.2 kernels support 16 ethernet devices without recompilation. This requires a relatively simple kernel change modification to /usr/src/linux/drivers/net/Space.c to add entries for the extra devices.

static struct device eth7_dev = {
    "eth7", 0,0,0,0,0xffe0 /* I/O base*/, 0,0,0,0, NEXT_DEV, ethif_probe };
static struct device eth6_dev = {
    "eth6", 0,0,0,0,0xffe0 /* I/O base*/, 0,0,0,0, &eth7_dev, ethif_probe };
static struct device eth5_dev = {
    "eth5", 0,0,0,0,0xffe0 /* I/O base*/, 0,0,0,0, &eth6_dev, ethif_probe };
static struct device eth4_dev = {
    "eth4", 0,0,0,0,0xffe0 /* I/O base*/, 0,0,0,0, &eth5_dev, ethif_probe };
static struct device eth3_dev = {
    "eth3", 0,0,0,0,0xffe0 /* I/O base*/, 0,0,0,0, &eth4_dev, ethif_probe };
static struct device eth2_dev = {
    "eth2", 0,0,0,0,0xffe0 /* I/O base*/, 0,0,0,0, &eth3_dev, ethif_probe };
static struct device eth1_dev = {
    "eth1", 0,0,0,0,0xffe0 /* I/O base*/, 0,0,0,0, &eth2_dev, ethif_probe };

static struct device eth0_dev = {
    "eth0", 0, 0, 0, 0, ETH0_ADDR, ETH0_IRQ, 0, 0, 0, &eth1_dev, ethif_probe };

Don't forget to look in the Ethernet HOWTO for general information.

On Don's tulip web page you will find some references to some multiport ethernet cards made by Znyx. I don't think there is as much experience in the Linux community with these cards as the Adaptec/Cogent cards, but Znyx seems to be supported Linux and now has patched Linux tulip drivers for their tulip based 4 port ethernet adapters available for download from their web site and that kernels >2.0.34 support at least some of the the Zynx cards, such as the regular PCI ZX346. Note that Znyx has CompactPCI models as well.

Adaptec also makes 4 port ANA-62044 quartet64 ethernet adapters which are NOT tulip based. These are based on some AIC-6915 LAN controllers. This is an adaptec DuraLAN chip. There is no mention of these chips in the drivers/net source directory of the 2.2.5 kernel and a quick web search failed to show any info. Note: a reader (chris@onthe.net.au) sent me these URLs on the new DuraLAN/Starfire driver:

• starfire driver
• Mentioned on one of Don's pages

The Znyx ZX478 is an 8 port Hot Swap CompactPCI (using rear transition module only, unfortunately) based ethernet card. It is based on intel 21143 (tulip) controllers with a 21554 64 bit PCI to 64 bit PCI bridge. I think the 21143 has a 32 bit bus so I am a little dubious about the 64 bit bus; it might work to decrease overhead on the motherboard/backplane PCI bus if it buffers up bus master DMA bursts from the 21143 and then retransmits them at the higher 64 bit speed; but I doubt it increases the throughput from a given card to the CPU. Znyx claims Linux support on the data sheet, although I havent seen any drivers on their web site.

Phobos makes 4 port ethernet controllers and has advertised them directly to the Linux community. Unfortunately, they seem to be more interested in making their web page as tacky as possible than they are in providing information about the drivers on their web pages.

The matrox shark NS-100/4 is a four port tulip 21140 based card. To be truly asinine, they put the EEPROM on the second (or third if you probe backwards) chip so the tulip driver will not work correctly with or without reverse_probe=1. This was reportedly a deliberate incompatibility.

The D-Link DFE-570TX is a Tulip based 4-port ethernet adapter. There have been a number of reports of trouble with these cards on the tulip mailing list (check the archive). Compiling the driver with these options may help:

gcc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -c tulip.c \
`[ -f /usr/include/linux/modversions.h ] && echo -DMODVERSIONS`

The Compu-shack FastLine Quattro 10/100 4 port Ethernet cards reportedly work with the tulip driver. Visit the manufacturer's web site (german language) .

Redhat 6.0 comes with Tulip driver v0.89. Redhat 6.2beta comes with v0.91g-ppc 7/16/99.

Recent Tulip drivers come with a variable reverse_probe which is used to get around the AMIBIOS probe order bug. Add the argument "reverse_probe=1" to the insmod command when the driver is loaded.

Compex supposedly makes four port FL400TX cards. This page has some details on getting the single port FL100TX to work. They apparently used three different dec chips 21143PA, 21143PB, and 21143PD (probably different revisions of the same chip). The tulip 0.90 driver will now work with the 21143PD but the 21143PA apparently still doesn't work. Just because the single port may work, don't assume the four port will.

Note that the newer bridge chips used on some cards don't work on some dec alpha based systems without a patch. The newer bridge chips can pass 32 bits of address instead of just 16 to the remote PCI bus but the PCI code (not the tulip driver) in the alpha kernel does not know about this. On some machines the motherboard bios initializes a register on the bridge chip, enabling those extra bits. A small change to the PCI code resets this register.

Note that the Adaptec/Cogent cards are used in the Beowulf clusters at GSFC and LANL which connect Linux boxes together in a hypercube using 100Mbs Quartet cards to produce relatively inexpensive supercomputers. The principle investigator of the Linux beowulf project, Don Becker, is also the primary maintainer for the linux ethernet drivers. So the author of the tulip driver is very familiar with these cards; I think most of the problems other people may habe experienced have been caused by poor quality bioses.

Yes, I beleive the quartet cards support full duplex under linux, although you may need to issue some parameters to the driver to enable this.

Some of the older boards apparently did not have media descriptions in the EEPROM and did not support N-Way autonegotiation. I think the latter refers to negotiating 10 or 100Mbs and half or full duplex; which I suspect is likely to be even tricker if you are using crossover cables between two NIC's (for example if you are using them in a machine which functions as a bridge, router, hub, or switch or for dedicated communications links). If you have one of the old cards, see the development page for more information on media descriptions and try manually configuring the media type.

The tulip driver has a debug option which can be set at the time you insmod the module.

Some AMIBIOS defects:

• Reports PCI peripherals on the other side of a PCI bridge in the wrong order.
• Reports absurd values for interrupt assignments
• gives the user even less control over interrupt assignments.
• ami tech support does not return email.

Here is a sample of what the messages look like when the driver loads. I cut this from an old message which had a sample from a non-working system (although in this case I think the messags look fine except for the version number). I will have to cut some text from a working system when I get a chance. But I think it might be easier to understand some of the things I wrote here, if you have an example to look at.

tulip.c:v0.66 3/14/97 becker@cesdis.gsfc.nasa.gov
eth0: DEC21040 Tulip at 0x3000, 00 00 92 92 4a f4, IRQ 11
eth1: DEC21040 Tulip at 0x3080, EEPROM not present, 00 00 92 92 4a f5, IRQ 11
eth2: DEC21040 Tulip at 0x3400, EEPROM not present, 00 00 92 92 4a f6, IRQ 11
eth3: DEC21040 Tulip at 0x3480, EEPROM not present, 00 00 92 92 4a f7, IRQ 11

Don Becker, the primary author and maintainer of the Linux ethernet drivers, has a Gigabit and 100Mbps Ethernet Technology Page which describes the availible chipsets.

The DEC Tulip chips include the 21040, 21041, 21140, 21140A, 21142, and 21143. The Lite-On 82c168 "PNIC" PCI Network Interface Controller, and the Macronix MX98713, MX98715, and MX98725, are all tulip clones. These tulip driver has been modified to support these.

The following sections indicate the BIOS PCI probe results and the kernel messages resulting from having one 10/100Mb/s quartets and two 10Mb/s quartets in the same machine (detected in that order). Slots (at least on that ASUS motherboard) are detected from left to right. Note that the messages in /var/log/messages were interleaved (this will happen when you try to bring up 12 interfaces simultaneously) I had to rearange them to make them readable.

bus# dev# func#  vendorID Dev ID  Device Class             IRQ
---- ---- -----  -------- ------  -------------            ---
 0    1     1    8086     7111    IDE Controler            14/15
 0    1     2    8086     7112    Serial bus controller    5

 1    4     0    1011     0009    Network Controller       9
 1    5     0    1011     0009    Network Controller       5
 1    6     0    1011     0009    Network Controller       11
 1    7     0    1011     0009    Network Controller       12

 2    4     0    1011     0002    Network Controller       12
 2    5     0    1011     0002    Network Controller       9
 2    6     0    1011     0002    Network Controller       5
 2    7     0    1011     0002    Network Controller       11

 3    4     0    1011     0002    Network Controller       11
 3    5     0    1011     0002    Network Controller       12
 3    6     0    1011     0002    Network Controller        9
 3    7     0    1011     0002    Network Controller        5 

Note, however, that the interrupt settings above are apparently wrong (this
is a common bug in most BIOSes, including AWARD); all 4 interrupts on
each board are apparently mapped to the same interrupt.

 eth0: Digital DS21140 Tulip at 0xc800, 00 00 92 a7 d7 8c, IRQ 9. 
 eth0:  EEPROM default media type Autosense. 
 eth0:  Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block. 
 eth0: ***WARNING***: No MII transceiver found! 
   PCI latency timer (CFLT) is unreasonably low at 0.  Setting to 64 clocks. 
 eth0: Setting full-duplex based on MII Xcvr #1 parter capability of 41e1. 

 eth1: Digital DS21140 Tulip at 0xc400, EEPROM not present, 00 00 92 a7 d7 8d, IRQ 9. 
 eth1:  Controller 1 of multiport board. 
 eth1:  EEPROM default media type Autosense. 
 eth1:  Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block. 
 eth1: ***WARNING***: No MII transceiver found! 
   PCI latency timer (CFLT) is unreasonably low at 0.  Setting to 64 clocks. 
 eth1: No link beat on the MII interface, status then 7849 now 7849. 
 [message repeats]

 eth2: Digital DS21140 Tulip at 0xc000, EEPROM not present, 00 00 92 a7 d7 8e, IRQ 9. 
 eth2:  Controller 2 of multiport board. 
 eth2:  EEPROM default media type Autosense. 
 eth2:  Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block. 
 eth2: ***WARNING***: No MII transceiver found! 
   PCI latency timer (CFLT) is unreasonably low at 0.  Setting to 64 clocks. 
 eth2: No link beat on the MII interface, status then 7849 now 7849. 
 [message repeats]

 eth3: Digital DS21140 Tulip at 0xb800, EEPROM not present, 00 00 92 a7 d7 8f, IRQ 9. 
 eth3:  Controller 3 of multiport board. 
 eth3:  EEPROM default media type Autosense. 
 eth3:  Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block. 
 eth3: ***WARNING***: No MII transceiver found! 
   PCI latency timer (CFLT) is unreasonably low at 0.  Setting to 64 clocks. 
n eth3: No link beat on the MII interface, status then 7849 now 7849. 
 [ message repeats]

 eth4: Digital DC21040 Tulip at 0xa800, 00 00 92 92 4f 70, IRQ 12. 
   PCI latency timer (CFLT) is unreasonably low at 0.  Setting to 64 clocks. 
 eth4: No 10baseT link beat found, switching to AUI media. 

 eth5: Digital DC21040 Tulip at 0xa400, EEPROM not present, 00 00 92 92 4f 71, IRQ 12. 
   PCI latency timer (CFLT) is unreasonably low at 0.  Setting to 64 clocks. 
 eth5: No 10baseT link beat found, switching to AUI media. 

 eth6: Digital DC21040 Tulip at 0xa000, EEPROM not present, 00 00 92 92 4f 72, IRQ 12. 
   PCI latency timer (CFLT) is unreasonably low at 0.  Setting to 64 clocks. 
 eth6: No 10baseT link beat found, switching to AUI media. 

 eth7: Digital DC21040 Tulip at 0x9800, EEPROM not present, 00 00 92 92 4f 73, IRQ 12. 
   PCI latency timer (CFLT) is unreasonably low at 0.  Setting to 64 clocks. 
 eth7: No 10baseT link beat found, switching to AUI media. 

 eth8: Digital DC21040 Tulip at 0x8800, 00 00 92 92 54 cc, IRQ 11. 
   PCI latency timer (CFLT) is unreasonably low at 0.  Setting to 64 clocks. 
 eth8: No 10baseT link beat found, switching to AUI media. 

 eth9: Digital DC21040 Tulip at 0x8400, EEPROM not present, 00 00 92 92 54 cd, IRQ 11. 
   PCI latency timer (CFLT) is unreasonably low at 0.  Setting to 64 clocks. 
 eth9: No 10baseT link beat found, switching to AUI media. 

 eth10: Digital DC21040 Tulip at 0x8000, EEPROM not present, 00 00 92 92 54 ce, IRQ 11. 
   PCI latency timer (CFLT) is unreasonably low at 0.  Setting to 64 clocks. 
 eth10: No 10baseT link beat found, switching to AUI media. 

 eth11: Digital DC21040 Tulip at 0x7800, EEPROM not present, 00 00 92 92 54 cf, IRQ 11. 
   PCI latency timer (CFLT) is unreasonably low at 0.  Setting to 64 clocks. 
 eth11: No 10baseT link beat found, switching to AUI media. 

The Adaptec 2940 SCSI device driver apparently needs to be modified to remove the SA_INTERRUPT flag to the request_irq() call if it is going to share an interrupt with any other device.

Credits: Much of this information comes from my own tinkering. Some of it comes from a face to face conversation with Don Becker, who was very helpful. Some of it comes from the linux tulip driver mailing list. Some of it comes from the "ethernet HOWTO", some comes from Adaptec's web site, some comes from the Don's tulip web page and some comes from reading the driver source. Jeff Uphoff and Steve Friedman also participated in the tinkering with the tulip driver.

Disclaimer: some of the content of this page is from memory; unfortunately, the warranty on my memory expired quite some time ago. The organization of this page is rather rough.

/etc/conf.modules

alias eth0 tulip
alias eth1 tulip
alias eth2 tulip
alias eth3 tulip
options tulip reverse_probe=1

General (non-multiport specific) Ethernet information

Charles Spurgeon's Ethernet Web Site has general ethernet, fast ethernet, gigabit ethernet, and fiberchannel information.

High speed wiring is very sensitive. Crosstalk and reflections (echo) can be a significant problem. Cable length should be 100m or less. 100baseT wiring should be done using 4 pair category 5 wiring, wired according to EIA-568B, with a minimum bend radius of 10 times the cable diameter (some special cables may tolerate 4x). It is very important not to untwist the cable any more than is absolutely necessary to make the connection. Simple cable testers will not detect split pairs where the right pins are connected on each end but the wrong wires are paired together. Gigabit ethernet has similar wiring requirements but is even less forgiving; category 5e or Category 6 (not yet fully standardized) is preferred but some CAT5 wiring will work. The MOD-TAP website has a useful Cabling FAQ.

Problem Diagnosis and Reporting

Other reported multiport tulip boards

Speed Testing

Tulip variations

• DEC 21040
• DEC 21041
• DEC 21140
• DEC 21142
• DEC 21143 (which comes in 51 flavors :-) )
• Intel 211xx chips (Intel bought out DECs semiconductor division)
• LiteOn 82C168 PNIC (clone)
• ASIX (clone)
• MXIC (clone)
• Linksys (relabled PNIC)
• Netgear (relabled PNIC)

Cheap single port cards

Redhat network installation

• During Install, select NO for networking support or install a different networking card during install.
• Download the driver to a floppy disk on another machine that has working network connectivity. Beware of carriage return line feed vs. Newline problems is you use a Windoze box or mac; you will need to fix the line endings before compiling the program.
• Copy the driver to the system, compile it, and install in /lib/modules/`uname -r`/net/tulip.o
• Edit the file /etc/sysconfig/network. Unfortunately, if you did not install networking, you won't have an example to go by so I have included one here:

  NETWORKING=yes
  FORWARD_IPV4=false
  HOSTNAME=yourname.yourdomain.com
  DOMAINANME=yourdomain.com
  GATEWAY=1.2.3.1
  GATEWAYDEV=eth0
  

• Edit the file /etc/sysconfig/network-scripts/ifcfg-eth0. Repeat for "ifcfg-eth1", "ifcfg-eth2", "ifcfg-eth3", etc. as needed. Again, if you didn't install networking, you won't have an example file for reference so I have included one here. Note that you should not configure ethernet interfaces you will not actually be connecting or your log will be filled with "no link beat" messages.

  DEVICE=eth0
  IPADDR=1.2.3.2
  NETMASK=255.255.255.0
  BROADCAST=1.2.3.255
  ONBOOT=yes
  

• Edit /etc/conf.modules (see example above).
• If the network driver needs to be availible during the initial boot process, you will need to rebuild the initrd to include the tulip driver. See the man page for "mkinitrd". The existing initrd will have a name link /boot/initrd-`uname -r`.img; check the appropriate initrd line in /etc/lilo.conf. You will probably want to create a new entry in /etc/lilo.conf that references the new initrd and leave the old one alone; that way, you can boot off the old configuration if you screw up. It is also a good idea to have a rescue disk handy.
• Reboot

Alternative to multiport cards

Footing

My personal linux pages are located here.