Miscellaneous.

# 9 Miscellaneous.

Contents of this section

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.

## 9.1 Passing Ethernet Arguments to the Kernel via LILO

Here are two generic kernel commands that would be typed after the name of your configuration in your lilo.conf file (usually `linux') For exmaple, if the command was `blah' and it expected 3 arguments (say 123, 456, and 789) then you would use:

`LILO: linux blah=123,456,789`

### The `ether` command

In 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).

PARAM_2: The 3c503 driver uses this select between the internal and external transceivers. 0 -- default/internal, 1 -- AUI external.

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/dl0' for parallel port `pocket' ethernet adaptors. 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. )

### The `reserve` command

This 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 machine, only when there is a problem or special case.

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 e.g. 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 usually complicated request.

## 9.2 Contributors

Other people who have contributed (directly or indirectly) to the Ethernet-Howto are, in alphabetical order:

            Peter Bauer             <pbauer@rnivh.rni.sub.org>
            Ross Biro               <bir7@leland.Stanford.EDU>
            Alan Cox                <iiitac@pyr.swan.ac.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.

## 9.3 Closing

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`

Next Chapter, Previous Chapter

Table of contents of this chapter, General table of contents

Top of the document, Beginning of this Chapter