Any other associated stuff that didn't fit in anywhere else gets dumped here. It may not be relevant, and it may not be of general interest but it is here anyway.
Here are two generic kernel commands that can be passed to the kernel at boot time. This can be done with LILO, loadlin, or any other booting utility that accepts optional arguments.
For example, if the command was `blah' and it expected 3 arguments (say 123, 456, and 789) then, with LILO, you would use:
LILO: linux blah=123,456,789
Note: PCI cards have their i/o and IRQ assigned by the BIOS at boot. This means that any boot time arguments for a PCI card's IRQ or i/o ports are usually ignored.
For more information on (and a complete list of) boot time arguments, please see the BootPrompt-HOWTO
ether commandIn its most generic form, it looks something like this:
ether=IRQ,BASE_ADDR,PARAM_1,PARAM_2,NAME
All arguments are optional. The first non-numeric argument is taken as the NAME.
IRQ: Obvious. An IRQ value of `0' (usually the default) means to autoIRQ. It's a historical accident that the IRQ setting is first rather than the base_addr -- this will be fixed whenever something else changes.
BASE_ADDR: Also obvious. A value of `0' (usually the default) means to probe a card-type-specific address list for an ethercard.
PARAM_1: It was orginally used as an override value for the memory start for a shared-memory ethercard, like the WD80*3. Some drivers use the low four bits of this value to set the debug message level. 0 -- default, 1-7 -- level 1..7, (7 is maximum verbosity) 8 -- level 0 (no messages). Also, the LANCE driver uses the low four bits of this value to select the DMA channel. Otherwise it uses auto-DMA.
PARAM_2: The 3c503 driver uses this to select between the internal and external transceivers. 0 -- default/internal, 1 -- AUI external. The Cabletron E21XX card also uses the low 4 bits of PARAM_2 to select the output media. Otherwise it detects automatically.
NAME: Selects the network device the values refer to. The standard kernel uses the names `eth0', `eth1', `eth2' and `eth3' for bus-attached ethercards, and `atp0' for the parallel port `pocket' ethernet adaptor. The arcnet driver uses `arc0' as its name. The default setting is for a single ethercard to be probed for as `eth0'. Multiple cards can only be enabled by explicitly setting up their base address using these LILO parameters. The 1.0 kernel has LANCE-based ethercards as a special case. LILO arguments are ignored, and LANCE cards are always assigned `eth<n>' names starting at `eth0'. Additional non-LANCE ethercards must be explicitly assigned to `eth<n+1>', and the usual `eth0' probe disabled with something like `ether=0,-1,eth0'. ( Yes, this is bug. )
reserve commandThis next lilo command is used just like `ether=' above, ie. it is appended to the name of the boot select specified in lilo.conf
reserve=IO-base,extent{,IO-base,extent...}
In some machines it may be necessary to prevent device drivers from checking for devices (auto-probing) in a specific region. This may be because of poorly designed hardware that causes the boot to freeze (such as some ethercards), hardware that is mistakenly identified, hardware whose state is changed by an earlier probe, or merely hardware you don't want the kernel to initialize.
The reserve boot-time argument addresses this problem by specifying
an I/O port region that shouldn't be probed. That region is reserved
in the kernel's port registration table as if a device has already
been found in that region. Note that this mechanism shouldn't be
necessary on most machines. Only when there is a problem or special
case would it be necessary to use this.
The I/O ports in the specified region are protected against
device probes. This was put in to be used when some driver was
hanging on a NE2000, or misidentifying some other device
as its own. A correct device driver shouldn't probe a reserved
region, unless another boot argument explicitly specifies that
it do so. This implies that reserve will most often be used
with some other boot argument. Hence if you specify a reserve
region to protect a specific device, you must generally specify
an explicit probe for that device. Most drivers ignore the port
registration table if they are given an explicit address.
For example, the boot line
LILO: linux reserve=0x300,32 ether=0,0x300,eth0
keeps all device drivers except the ethercard drivers from probing 0x300-0x31f.
As usual with boot-time specifiers there is an 11 parameter limit,
thus you can only specify 5 reserved regions per reserve keyword.
Multiple reserve specifiers will work if you have an unusually
complicated request.
See the insmod(8) manual page for information on passing
arguments to the module as it is being loaded.
The command lsmod will show you what modules are
loaded, and rmmod will remove them.
At present, all the modules are put in the subdirectory
modules in your Linux kernel source tree (usually in
the form of symbolic links). To actually generate the modules,
you have to type make modules after you have finished building
the kernel proper. Earlier kernels built them automatically,
which wasn't fair to those compiling on 4MB 386sx-16 machines.
Most modules accept parameters like io=0x340 and
irq=12 on the insmod command line. It
is STRONGLY ADVISED that you supply these parameters
to avoid probing for the card. Unlike PCI and EISA devices,
there is no real safe way to do auto-probing for ISA devices,
and so it should be avoided when using drivers as modules.
A list of all the parameters that each module accepts can be found in the file:
/usr/src/linux/Documentation/networking/net-modules.txt
It is recommended that you read that to find out what options you can use for your particular card.
Once you have figured out the arguments/options you are going to use, you can insert the module by typing as root:
insmod mod_name.o [io=val1[,val2,...]] [irq=val7[,val8,...]]
Once a module is inserted, then you can use it just like normal,
and give ifconfig commands. If you set up your networking at
boot, then make sure your /etc/rc* files run the
insmod command(s) before getting to the ifconfig command.
Also note that a busy module can't be removed. That means
that you will have to ifconfig eth0 down (shut down the
ethernet card) before you can remove the module(s).
The present list of 8390 based drivers is: 3c503, ac3200, e2100, hp, hp-plus, ne, smc-ultra and wd. These cards were not supported as modules for kernel versions prior to 1.3.42. (This does not include some of the separately distributed PCMCIA drivers (e.g. de-650) that are also 8390 based, that have had module support for quite some time now.)
If you have an 8390 based card, you may have to insert
two modules, 8390.o and then the module for your card.
If 8390 support has been built into your kernel, then you
will not need to insert the 8390 module. (8390 support is
built in whenever an 8390 based card is selected to be built
into the kernel.) Doing a cat /proc/ksyms | grep 8390
will tell you if 8390 support is in your kernel.
For an 8390 based card, you will have to remove the card module before removing the 8390 module, as the 8390 module is used by the card module, and thus marked as busy.
The 8390 series of network drivers now support multiple card systems without reloading the same module multiple times (memory efficient!) This is done by specifying multiple comma separated values, such as:
insmod 3c503.o io=0x280,0x300,0x330,0x350 xcvr=0,1,0,1
The above would have the one module controlling four 3c503 cards, with card 2 and 4 using external transcievers.
It is *STRONGLY RECOMMENDED* that you supply "io=" instead of autoprobing. If an "io=" argument is not supplied, then the ISA 8390 drivers will complain about autoprobing being not recommended, and begrudgingly autoprobe for a *SINGLE CARD ONLY* -- if you want to use multiple cards you *have* to supply an "io=0xNNN,0xQQQ,..." argument.
The ne module is an exception to the above. A NE2000 is
essentially an 8390 chip, some bus glue and some RAM.
Because of this, the ne probe is more invasive than the
rest, and so at boot we make sure the ne probe is done
last of all the 8390 cards (so that it won't trip over
other 8390 based cards) With modules we can't ensure
that all other non-ne 8390 cards have already been
found. Because of this, the ne module REQUIRES an
io=0xNNN argument passed in via insmod. It
will refuse to autoprobe.
It is also worth noting that auto-IRQ probably isn't as
reliable during the flurry of interrupt activity on a
running machine. Cards such as the ne2000 that can't get
the IRQ setting from an EEPROM or configuration register
are probably best supplied with an irq=M argument as
well. The file
/usr/src/linux/Documentation/networking/net-modules.txt
also lists how the interrupt settings are determined for the
various cards if an irq=N value is not given.
If you have questions about your ethernet card, please READ this
document first. You may also want to join the NET channel of the
Linux mailing lists by sending mail to
majordomo@vger.rutgers.edu to get help with what lists
are available, and how to join them.
Furthermore keep in mind that the NET channel is for development discussions only. General questions on how to configure your system should be directed to comp.os.linux.setup unless you are actively involved in the development of part of the networking for Linux. We ask that you please respect this general guideline for content.
Also, the news groups comp.sys.ibm.pc.hardware.networking and comp.dcom.lans.ethernet should be used for questions that are not Linux specific.
Much of this info came from saved postings from the comp.os.linux groups, which shows that it is a valuable resource of information. Other useful information came from a bunch of small files by Donald himself. Of course, if you are setting up an Ethernet card, then you will want to read the NET-2 Howto so that you can actually configure the software you will use. Also, if you fancy yourself as a bit of a hacker, you can always scrounge some additional info from the driver source files as well. There is usually a paragraph or two in there describing any important points before any actual code starts..
For those looking for information that is not specific in any way to Linux (i.e. what is 10BaseT, what is AUI, what does a hub do, etc.) I strongly recommend the Ethernet-FAQ that is posted regularly to the newsgroup comp.dcom.lans.ethernet. You can grab it from RTFM which holds all the newsgroup FAQs at the following URL:
You can also have a look at the `Ethernet-HomePage' so to speak, which is at the following URL:
Other people who have contributed (directly or indirectly) to the Ethernet-Howto are, in alphabetical order:
Ross Biro <bir7@leland.stanford.edu>
Alan Cox <iialan@www.linux.org.uk>
David C. Davies <davies@wanton.enet.dec.com>
Bjorn Ekwall <bj0rn@blox.se>
David Hinds <dhinds@allegro.stanford.edu>
Michael Hipp <mhipp@student.uni-tuebingen.de>
Mike Jagdis <jaggy@purplet.demon.co.uk>
Duke Kamstra <kamstra@ccmail.west.smc.com>
Russell Nelson <nelson@crynwr.com>
Cameron Spitzer <camerons@NAD.3Com.com>
Dave Roberts <david.roberts@amd.com>
Glenn Talbott <gt@hprnd.rose.hp.com>
Many thanks to the above people, and all the other unmentioned testers out there.
This document is not gospel. However, it is probably the most up to date info that you will be able to find. Nobody is responsible for what happens to your hardware but yourself. If your ethercard or any other hardware goes up in smoke (...nearly impossible!) we take no responsibility. ie. THE AUTHORS ARE NOT RESPONSIBLE FOR ANY DAMAGES INCURRED DUE TO ACTIONS TAKEN BASED ON THE INFORMATION INCLUDED IN THIS DOCUMENT.
This document is Copyright (c) 1993, 1994, 1995 1996 by Donald Becker and Paul Gortmaker. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.
Permission is granted to copy and distribute modified versions of this document under the conditions for verbatim copying, provided that this copyright notice is included exactly as in the original, and that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.
Permission is granted to copy and distribute translations of this document into another language, under the above conditions for modified versions.
If you are intending to incorporate this document into a published work, please contact me, and I will make an effort to ensure that you have the most up to date information available. In the past, out of date versions of the Linux howto documents have been published, which caused the developers undue grief from being plagued with questions that were already answered in the up to date versions.
If you have found any glaring typos, or outdated info in this document, please let one of us know. It's getting big, and it is easy to overlook stuff.
Thanks,
Paul Gortmaker, Paul.Gortmaker@anu.edu.au
Donald J. Becker, becker@cesdis.gsfc.nasa.gov