[NTLUG:Discuss] quick NIC question

gandalf.middleearth@verizon.net gandalf.middleearth at verizon.net
Fri Sep 20 00:05:04 CDT 2002


Shamelessly copied from the  "Mini-HowTo on using multiple Ethernet adapters with Linux " v2.00

****************************************************************************************************************************************
This is an short note on configuring Linux to recognize multiple ethernet adapters. 

Quick-start: Driver Modules

PCI drivers

PCI devices have safe probes, so you can just add the following line to /etc/conf.modules:

alias eth1 tulip
where 'tulip' is the name of the correct driver. 

ISA drivers

ISA devices tend to have dangerous probes, so you must specify the I/O address of the cards. Multiple cards supported by a single driver requires specifying 
all of the I/O address. Add the following lines to /etc/conf.modules: 

 alias eth0 ne  alias eth1 ne  alias eth2 ne  options ne io=0x280,0x300,0x220
where 'ne' is the name of the correct driver. 

Quick-start: Built-in Drivers

For systems running a Linux distribution with built-in device drivers, just add this line to the top of your /etc/lilo.conf file and re-run `lilo': 

append = "ether=0,0,eth1 ether=0,0,eth2 ether=0,0,eth3"

That's all there is to it. The next time you boot Linux should probe for up to four ethercards. 

Driver Modules

For distributions such as RedHat that use loadable device driver modules exclusively the situation is slightly more complex, and distribution-specific. You can 
tell if your distribution is using network driver modules by looking for a network module in /proc/modules, which reports all loaded modules. 

Device drivers modules are loaded either by a process called 'kerneld' which handles the kernel's request for a network device, or 'modprobe' which attempts 
to load every device driver module in the hope that one will find a valid device. 

The 'kerneld' process reads a configuration file /etc/conf.modules which describes the device driver to load when a request is made for a specific capability. 
For Ethernet drivers the name of the capability is the interface name e.g. "eth0" or "eth1". In order to load the proper driver, the "eth*" name must be mapped 
("aliased") to the driver name. For ISA devices (except the 3c509), the I/O addresses must also be supplied. 

An example /etc/conf.modules loading the device driver module 'ne' to support two additional NE2000 adapters at I/O 0x280 and 0x240 on a system that uses 
a WD8013 card at 0x300 as its primary interface:

alias eth0 wd options wd io=0x300 alias eth1 ne alias eth2 ne options ne io=0x280,0x240

Built-in Drivers: What you did, and how you did it.

By default a stock Linux kernel probes for a single ethercard, and once one is found the probe ceases. There are three defined ways to cause the kernel to 
probe for additional cards. In increasing order of difficulty and permanence they are: 

Passing parameters to your kernel at boot time.
Configuring your boot loader to always pass those parameters.
Modifying the kernel netcard probe tables in drivers/net/Space.c.

For most people the second method is most appropriate, and it's the one that was described above. 

Passing parameters using your boot loader

In the following instructions it's assumed that you are using the standard Linux boot loader, `LILO'. 

The Linux kernel recognizes certain parameters passed at boot-time. Most often these parameters specify aspects of the configuration that cannot be 
determined at boot-time. For network adaptors the following parameter is recognized: 

ether=,,,,
Valid numeric arguments may be in decimal, octal (with a leading '0') or hexadecimal (preceded by a '0x'). The first non-numeric argument is taken to be the 
NAME of the device. Empty arguments are taken to be zero, and any omitted arguments before the name are left unchanged.

IRQ
This entry specifies the IRQ value to be set (on boards with software-settable IRQs) or used (on boards with jumpered IRQs). A value of '0' means to read the 
IRQ line from the board (if possible) or use autoIRQ if the board doesn't provide a way to read the IRQ.
IO-ADDR
This entry specifies a single base I/O address to probe. A value of zero specifies that all reasonable I/O address are to be probed.

Normally an I/O region reservation map is used to decide if a location can be probed. This map is ignored if an I/O address is specified. This allows the 
"reserve=," parameter to exclude other device probes from an IO region. 

PARAM1,PARAM2
Originally these entries were for specifying the memory address of adaptors that use shared memory, like the WD8013. Over time they have been extended to 
provide other driver-specific information. 
NAME
The name of a predefined device. The stock kernel defines at least "eth0", "eth1", "eth2", and "eth3". Other devices names (e.g. for PPP, SLIP, or a pocket 
ethernet device) may exist but will have different semantics.

LILO provides two ways to pass these boot-time parameters to the kernel. The most common way to do this is to type them immediately after specifying the 
name of the boot image. The following example enables all four of the available probe slots.

linux ether=0,0,eth1 ether=0,0,eth2 ether=0,0,eth3

Of course this is pretty complicated to type in at each boot, and would preclude unattended reboots. You can make the kernel parameters permanent by 
adding an "append" line to your LILO configuration file, /etc/lilo.conf, and running LILO to install your updated configuration.

append = "ether=0,0,eth1  ether=0,0,eth2  ether=0,0,eth3"

Modifying your kernel

If it's possible for you to configure your system without modifying the kernel source, I recommend that you do so. Modifying the source code isn't self-
documenting and results in extra complications at upgrade time. Still there are a few instances where it is appropriate:

When you need to enable more than four devices. (The drivers/net/Space.c in older kernels only has entries for eth0...eth3.)
When you must limit the probe types to a subset of possible card types e.g. when a probe confuses a different type of device.
When you want a device name other than ethN.

If you've decided to go this route, edit the device list in drivers/net/Space.c to insert your desired values. If you need to add a new device take care that you 
preserve the chaining: use the existing list entries as a guide.

Special notes on the specific device probes

PCI cards

PCI (and EISA) cards are safe and reliable to probe for, so most PCI device drivers find all supported cards with no additional parameters. The exceptions are 
device drivers that support both ISA and PCI versions of a card: the NE2000 and the older LANCE/PCnet drivers. 

LANCE/PCnet cards

The kernel v1.2.13 and earlier LANCE driver requires special low-memory DMA buffers, and so the LANCE probe occurs earlier than the other network device 
probes. The upside of this is that you could ignore this section: multiple LANCE cards were automatically probed for. The downside is that the earlier LANCE 
driver did't use the LILO parameters e.g. IRQ. 

The 3c509 in ISA mode

The 3c509 has a unique feature that allows truly safe probing on the ISA bus. It's an activation mechanism that is similar to (and predates) ISA Plug-and-Play. 
This is great, but unfortunately for us this method doesn't mix well with the rest of the probes. 

The most noticeable aspect is that it's difficult to predict a priori which card will be accepted "first" -- the order is based on the hardware ethernet address. That 
means that the ethercard with the lowest ethernet address will be assigned to "eth0", and the next to "eth1", etc. If the "eth0" ethercard is removed, they all shift 
down one number. 

A related aspect is that it's not possible to leave an "earlier" card disabled, enable a card at an address or IRQ different than the EEPROM setting, or enable a 
card at a specific address.
*******************************************************************************************************************************************************


Hope this helps
The only prerequisite for using Linux,
 is a true desire to be smarter than
 the equipment you are trying to operate !





More information about the Discuss mailing list