15. Individual ModulesIn this chapter, I document individual LKMs. Where possible, I do this
by reference to more authoritative documentation for the particular LKM
(probably maintained by the same person who maintains the LKM code). 15.1. Executable InterpretersYou must have at least one executable interpreter bound into the
base kernel, because in order to load an executable interpreter LKM,
you have to run an executable and something has to interpret that
executable. That one bound-in executable interpreter is almost certainly the ELF
interpreter, since virtually all executables in a Linux system are
ELF. Historical note: Before ELF existed on Linux (c. 1995), the normal
executable format was a.out. For a while, part ELF/part a.out
systems were common. Some still exist. 15.1.1. binfmt_aout: executable interpreter for a.out formata.out is the venerable executable format that was common in Unix's
early history and originally Linux's only executable format. To this
day, the default name of the executable output file of the GNU
compiler is a.out (regardless of what it's format
is). If you try to run an a.out executable without this, your
exec system call fails with a "cannot execute
binary file" error. There are no LKM parameters. Example:
15.1.2. binfmt_elf: executable interpreter for ELF formatELF is the normal executable format on Linux systems. It's almost inconceivable that you wouldn't have this executable
interpreter bound into the base kernel (if for no other reason that
your insmod is probably an ELF executable).
However, it is conceptually possible to leave it out of the base
kernel and insert it as an LKM. There are no LKM parameters. Example:
15.1.3. binfmt_java: executable interpreter for Java bytecodeJava is a relatively modern object oriented programming language.
Java programs are traditionally compiled into "Java bytecode" which is
meant to be interpreted by a Java bytecode interpreter. The point of
this new object language is that the bytecode object files are
portable: Although different systems require different object formats,
as long as each system has a bytecode interpreter, it can run bytecode
object files. (This only works for a while, of course. If
portability were that easy, all systems today would use the same
object format anyway). While the intent was that the bytecode interpreter would run as a user
space program, with this LKM you can make the Linux kernel interpret
Java bytecode like any other executable format. So you can run a
program compiled from Java the same as you would run a program
compiled from C (e.g. type its name at a command shell prompt). In practice, the advantages of the intermediate bytecode language have
not been proven and it is quite common to compile Java directly to a
more traditional executable format, such as ELF. If you do that, you
don't need binfmt_java. There are no LKM parameters. Example:
15.2. Block Device Drivers15.2.1. floppy: floppy disk driverThis is the device driver for floppy disks. You need this in order to
access a floppy disk in any way. This LKM is documented in the file README.fd in
the linux/drivers/block
directory of the Linux source tree. For detailed up to date
information refer directly to this file. Note that if you boot (or might boot) from a floppy disk or with a
root filesystem on a floppy disk, you must have this driver bound into
the base kernel, because your system will need it before it has a
chance to insert the LKM. Example:
modprobe floppy 'floppy="daring two_fdc 0,thinkpad 0x8,fifo_depth"' |
There is only one LKM parameter: floppy. But
it contains many subparameters. The reason for this unusual parameter
format is to be consistent with the way you would specify the same
things in the kernel boot parameters if the driver were bound into the
base kernel. The value of floppy is a sequence of
blank-delimited words. Each of those words is one of the following
sequences of comma-delimited words: - asus_pci
Sets the bit mask of allowed drives to allow only units 0 and
1. Obsolete, as this is the default setting anyways
- daring
Tells the floppy driver that you have a well behaved floppy
controller. This allows more efficient and smoother
operation, but may fail on certain controllers. This may
speed up certain operations.
- 0,daring
Tells the floppy driver that your floppy controller should be used
with caution.
- one_fdc
Tells the floppy driver that you have only floppy controller
(default).
- address,two_fdc
Tells the floppy driver that you have two floppy
controllers. The second floppy controller is assumed to be
at address. This option is not needed if
the second controller is at address 0x370, and if you use
the 'cmos' option
- two_fdc
Like above, but with default address
- thinkpad
Tells the floppy driver that you have an IBM Thinkpad model
notebook computer. Thinkpads use an inverted convention for
the disk change line.
- 0,thinkpad
Tells the floppy driver that you don't have a Thinkpad.
- nodma
Tells the floppy driver not to use DMA for data transfers.
This is needed on HP Omnibooks, which don't have a workable
DMA channel for the floppy driver. This option is also
useful if you frequently get "Unable to allocate DMA
memory" messages. Indeed, DMA memory needs to be
continuous in physical memory, and is thus harder to find,
whereas non-DMA buffers may be allocated in virtual
memory. However, I advise against this if you have an FDC
without a FIFO (8272A or 82072). 82072A and later are
OK). You also need at least a 486 to use nodma. If you use
nodma mode, I suggest you also set the FIFO threshold to 10
or lower, in order to limit the number of data transfer
interrupts.
If you have a FIFO-able FDC, the floppy driver
automatically falls back on non DMA mode if it can't find
any DMA-able memory. If you want to avoid this, explicitly
specify "yesdma".
- omnibook
Same as nodma.
- yesdma
Tells the floppy driver that a workable DMA channel is available
(the default).
- nofifo
Disables the FIFO entirely. This is needed if you get "Bus
master arbitration error" messages from your Ethernet card (or
from other devices) while accessing the floppy.
- fifo
Enables the FIFO (default)
- threshold,fifo_depth
Sets the FIFO threshold. This is mostly relevant in DMA
mode. If this is higher, the floppy driver tolerates more
interrupt latency, but it triggers more interrupts (i.e. it
imposes more load on the rest of the system). If this is
lower, the interrupt latency should be lower too (faster
processor). The benefit of a lower threshold is fewer
interrupts.
To tune the fifo threshold, switch on over/underrun
messages using 'floppycontrol --messages'. Then access a
floppy disk. If you get a huge amount of "Over/Underrun -
retrying" messages, then the fifo threshold is too low.
Try with a higher value, until you only get an occasional
Over/Underrun.
The value must be between 0 and 0xf, inclusive.
As you insert and remove the LKM to try different values,
remember to redo the 'floppycontrol --messages' every time
you insert the LKM. You shouldn't normally have to tune
the fifo, because the default (0xa) is reasonable.
- drive,type,cmos
Sets the CMOS type of drive to
type. This is mandatory if you have
more than two floppy drives (only two can be described in
the physical CMOS), or if your BIOS uses non-standard CMOS
types. The CMOS types are:
- 0
Use the value of the physical CMOS
- 1
5 1/4 DD - 2
5 1/4 HD - 3
3 1/2 DD - 4
3 1/2 HD - 5
3 1/2 ED - 6
3 1/2 ED - 16
unknown or not installed
(Note: there are two valid types for ED drives. This is
because 5 was initially chosen to represent floppy
tapes, and 6 for ED drives. AMI
ignored this, and used 5 for ED drives. That's why the
floppy driver handles both)
- unexpected_interrupts
Print a warning message when an unexpected interrupt is received.
(default behavior)
- no_unexpected_interrupts
Don't print a message when an unexpected interrupt is
received. This is needed on IBM L40SX laptops in certain
video modes. (There seems to be an interaction between
video and floppy. The unexpected interrupts only affect
performance, and can safely be ignored.)
- L40SX
Same as no_unexpected_interrupts.
- broken_dcl
Don't use the disk change line, but assume that the disk
was changed whenever the device node is reopened. Needed
on some boxes where the disk change line is broken or
unsupported. This should be regarded as a stopgap measure,
indeed it makes floppy operation less efficient due to
unneeded cache flushings, and slightly more unreliable.
Please verify your cable, connection and jumper settings if
you have any DCL problems. However, some older drives, and
also some laptops are known not to have a DCL.
- debug
Print debugging messages
- messages
Print informational messages for some operations (disk change
notifications, warnings about over and underruns, and about
autodetection)
- silent_dcl_clear
Uses a less noisy way to clear the disk change line (which
doesn't involve seeks). Implied by daring.
- nr,irq
Tells the driver to expect interrupts on IRQ
nr instead of the conventional IRQ 6.
- nr,dma
Tells the driver to use DMA channel nr
instead of the
conventional DMA channel 2.
- slow
Use PS/2 stepping rate: PS/2 floppies have much slower step
rates than regular floppies. It's been recommended that
take about 1/4 of the default speed in some more extreme
cases.
- mask,allowed_drive_mask
Sets the bitmask of allowed drives to mask.
By default,
only units 0 and 1 of each floppy controller are allowed.
This is done because certain non-standard hardware (ASUS
PCI motherboards) mess up the keyboard when accessing units
2 or 3. This option is somewhat obsoleted by the 'cmos'
option.
- all_drives
Sets the bitmask of allowed drives to all drives. Use this
if you have more than two drives connected to a floppy
controller.
15.2.2. loop: loop device driverThis module lets you mount a filesystem that is stored in a regular
file (in another filesystem). That other file is called the backing file. One use of this is to test an ISO 9660 filesystem before irreversibly
burning it onto a CD. You build the filesystem in a 650 MB regular
file. That file will be the input to the CD burning program. But you
can define a loopback device based on that file as backing file and
then mount the filesystem right from the backing file. It can also
give you a handy way to transmit collections of files over a network.
It's like a tar file, only you don't have to pack and unpack it -- you
just mount the original file. Some people use loop devices on a machine that sometimes runs Windows
and sometimes runs Linux to allow them to maintain the Linux system
via the Windows system: put a Linux root filesystem in a file in a FAT
filesystem that Windows can access, then mount the Linux root
filesystem via a loop device when Linux is running. You can keep the filesystem encrypted or compressed, or encoded in any
arbitrary way, in the backing file. The loop device encodes (e.g. encrypts)
as you write to it, and decodes (e.g. decrypts) as you read. (An
alternative more popular strategy for encrypting and compressing a
filesystem is to use an encrypted or compressed filesystem type,
either a native one or one backed by a normal filesystem. Cfs, Tcfs,
and Stegfs are examples of such filesystem types). An encoding system is based on a "transfer function". There
are two tranfer functions built into the loop module: the
identify transfer function (which is for the normal no-encoding case
-- What you see in the loop device is exactly what is in the backing
file) and a simple XOR encryption function. A separate kernel module
can add any transfer function by calling the loop
module's exported loop_register_transfer() function. There appear to be various modules floating around
that provide transfer functions to do compression and encryption (DES,
IDEA, Fish, etc.).
Some of them appear to be part of current Linux kernel distributions.
In addition, there appear to be various alternative loop device drivers,
many of them also called loop, that have such transfer
functions built in. Do not confuse these loop devices with the "loopback device"
used for network connections from the machine to itself. That isn't
actually a device at all - it's a network interface. This module is a block device driver. You set up a loop device by
issuing an ioctl to it to bind a file to it. The typical program to
issue this ioctl is losetup. See the documentation
of losetup for more details. There are also options
on the normal 'mount' command to do loop device setup under the covers,
but because that confuses the logically separate operations of setting
up a loop device and mounting a filesystem, for the sake of clarity
you're probably better off using losetup. Example:
Module Parameters:
- max_loop
Number of loop devices that will exist. Contrary to what its
name suggests, the number you specify is the number of loop
devices that always exist. An existing device is not
necessarily configured (bound to a backing file), though,
so this number can be thought of as the maximum number of
loop devices that you can configure.
The minor numbers for these loop devices are consecutive
starting at 0.
There is more information on loop devices in the Loopback Encrypted Filesystem HOWTO and the Loopback Root Filesystem HOWTO and the manual for losetup. 15.2.3. linear: linear (non-RAID) disk array device driverThis driver lets you combine several disk partitions into one
logical block device. If you use this, then your multiple devices driver will be able to use
the so-called linear mode, i.e. it will combine the disk
partitions by simply appending one to the other. See Software-RAID-HOWTO. Example:
There are no module parameters. 15.2.4. raid0: RAID-0 device driverThis driver lets you combine several disk partitions into one logical
block device. If you use this, then your multiple devices driver will be able to use
the so-called raid0 mode, i.e. it will combine the disk partitions
into one logical device in such a fashion as to fill them up evenly,
one chunk here and one chunk there. This will increase the throughput
rate if the partitions reside on distinct disks. See Software-RAID-HOWTO. Example:
There are no module parameters. 15.2.5. rd: ramdisk device driverA ramdisk is a block device whose storage is composed of system memory
(real memory; not virtual). You can use it like a very fast disk
device and also in circumstances where you need a device, but don't
have traditional hardware devices to play with. A common example of the latter is for a rescue system -- a system
you use to diagnose and repair your real system. Since you don't
want to mess with your real disks, you run off ramdisks. You might
load data into these ramdisks from external media such as floppy
disks. Sometimes, you have your boot loader (e.g. lilo)
create a ramdisk and load it with data (perhaps from a floppy disk).
Of course, if you do this, you cannot use the LKM version of the
ramdisk driver because the driver will have to be in the kernel at
boot time. A ramdisk is actually conceptually simple in Linux. Disk devices
operate through memory because of the buffer cache. The only
difference with a ramdisk is that you never actually get past the
buffer cache to a real device. This is because with a ramdisk, 1)
when you first access a particular block, Linux just assumes it is
all zeroes; and 2) the device's buffer cache blocks are never
written to the device, ergo never stolen for use with other devices.
This means reads and writes are always to the buffer cache and never
reach the device. There is additional information about ramdisks in the file
Documentation/ramdisk.txt in the Linux source
tree. Example:
There are no module parameters that you can supply to the LKM, but
if you bind the module into the base kernel, there are kernel parameters
you can pass to it. See BootPrompt-HOWTO. 15.2.6. xd: XT disk device driverVery old 8 bit hard disk controllers used in the IBM XT computer. No,
the existence of XT disk support does NOT mean that you can run Linux
on an IBM XT :). Example:
There are no module parameters. 15.3. SCSI DriversDetailed information about SCSI drivers is in
SCSI-2.4-HOWTO. Linux's SCSI function is implemented in three layers, and there are
LKMs for all of them. In the middle is the mid-level driver or SCSI core. This consists of
the scsi_mod LKM. It does all those things that
are common among SCSI devices regardless of what SCSI adapter you use
and what class of device (disk, scanner, CD-ROM drive, etc.) it is. There is a low-level driver for each kind of SCSI adapter --
typically, a different driver for each brand. For example, the
low-level driver for Advansys adapters (made by the company which is
now Connect.com) is named advansys. (If you are
comparing ATA (aka IDE) and SCSI disk devices, this is a major
difference -- ATA is simple and standard enough that one driver works
with all adapters from all companies. SCSI is less standard and as a
result you should have less confidence in any particular adapter being
perfectly compatible with your system). High-level drivers present to the rest of the kernel an interface
appropriate to a certain class of devices. The SCSI high-level driver
for tape devices, st, for example, has ioctls to
rewind. The high-level SCSI driver for CD-ROM drives,
sr, does not. Note that you rarely need a high-level driver specific to a certain
brand of device. At this level, there is little room for one brand to
be distinguishable from another. One SCSI high-level driver that deserves special mention is
sg. This driver, called the "SCSI generic" driver,
is a fairly thin layer that presents a rather raw representation of
the SCSI mid-level driver to the rest of the kernel. User space
programs that operate through the SCSI generic driver (because they
access device special files whose major number is the one registered
by sg (to wit, 21)) have a detailed understanding
of SCSI protocols, whereas user space programs that operate through
other SCSI high-level drivers typically don't even know what SCSI is.
SCSI-Programming-HOWTO has complete
documentation of the SCSI generic driver. The layering order of the SCSI modules belies the way the LKMs depend
upon each other and the order in which they must be loaded. You
always load the mid-level driver first and unload it last. The
low-level and high-level drivers can be loaded and unloaded in any
order after that, and they hook themselves into and establish
dependency on the mid-level driver at both ends. If you don't have a
complete set, you will get a "device not found" error when you try to
access a device. Most SCSI low-level (adapter) drivers don't have LKM parameters; they
do generally autoprobe for card settings. If your card responds to
some unconventional port address you must bind the driver into the
base kernel and use kernel "command line" options. See
BootPrompt-HOWTO. Or you can twiddle The
Source and recompile. Many SCSI low-level drivers have documentation in the drivers/scsi directory in the Linux
source tree, in files called README.*. 15.3.1. scsi_mod: SCSI mid-level driverExample:
There are no module parameters. 15.3.2. sd_mod: SCSI high-level driver for disk devicesExample:
There are no module parameters. 15.3.3. st: SCSI high-level driver for tape devicesExample:
There are no module parameters for the LKM, but if you bind this module
into the base kernel, you can pass some parameters via the Linux boot
parameters. See BootPrompt-HOWTO. 15.3.4. sr_mod: SCSI high-level driver for CD-ROM drivesExample:
There are no module parameters. 15.3.5. sg: SCSI high-level driver for generic SCSI devicesSee the explanation of this special high-level driver above. Example:
There are no module parameters. 15.3.6. wd7000: SCSI low-level driver for 7000FASSTExample:
There are no module parameters for the LKM, but if you bind this module
into the base kernel, you can pass some parameters via the Linux boot
parameters. See BootPrompt-HOWTO. This driver atoprobes the card and requires installed BIOS. 15.3.7. aha152x: SCSI low-level driver for Adaptec AHA152X/2825Example:
There are no module parameters for the LKM, but if you bind this module
into the base kernel, you can pass some parameters via the Linux boot
parameters. See BootPrompt-HOWTO. This driver atoprobes the card and requires installed BIOS. 15.3.8. aha1542: SCSI low-level driver for Adaptec AHA1542Example:
There are no module parameters for the LKM, but if you bind this module
into the base kernel, you can pass some parameters via the Linux boot
parameters. See BootPrompt-HOWTO. This driver autoprobes the card at 0x330 and 0x334 only. 15.3.9. aha1740: SCSI low-level driver for Adaptec AHA1740 EISAExample:
There are no module parameters. This driver autoprobes the card. 15.3.10. aic7xxx: SCSI low-level driver for Adaptec AHA274X/284X/294XExample:
There are no module parameters for the LKM, but if you bind this module
into the base kernel, you can pass some parameters via the Linux boot
parameters. See BootPrompt-HOWTO. This driver autoprobes the card and BIOS must be enabled. 15.3.11. advansys: SCSI low-level driver for AdvanSys/Connect.comExample:
modprobe advansys asc_iopflag=1 asc_ioport=0x110,0x330 asc_dbglvl=1 |
Module Parameters:
- asc_iopflag
- 1
enable port scanning - 0
disable port scanning
- asc_ioport
I/O port addresses to scan for Advansys SCSI adapters - asc_dbglvl
debugging level:
- 0
Errors only - 1
High level tracing - 2-N
Verbose tracing
If you bind this driver into the base kernel, you can pass parameters
to it via the kernel boot parameters. See
BootPrompt-HOWTO. 15.3.12. in2000: SCSI low-level driver for Always IN2000Example:
There are no module parameters. This driver autoprobes the card. No BIOS is required. 15.3.13. BusLogic: SCSI low-level driver for BusLogicThe list of BusLogic cards this driver can drive is long. Read file
drivers/scsi/README.BusLogic in the Linux source
tree to get the total picture. Example:
There are no module parameters. If you bind this driver into the base kernel, you can pass parameters
to it via the kernel boot parameters. See
BootPrompt-HOWTO. 15.3.14. dtc: SCSI low-level driver for DTC3180/3280Example:
There are no module parameters for the LKM, but if you bind this module
into the base kernel, you can pass some parameters via the Linux boot
parameters. See BootPrompt-HOWTO. This driver autoprobes the card. 15.3.15. eata: SCSI low-level driver for EATA ISA/EISAThis driver handles DPT PM2011/021/012/022/122/322. Example:
There are no module parameters for the LKM, but if you bind this module
into the base kernel, you can pass some parameters via the Linux boot
parameters. See BootPrompt-HOWTO. 15.3.16. eata_dma: SCSI low-level driver for EATA-DMAThis driver handles DPT, NEC, AT&T, SNI, AST, Olivetti, and Alphatronix. This driver handles DPT Smartcache, Smartcache III and SmartRAID. Example:
There are no module parameters. Autoprobe works in all configurations. 15.3.17. eata_pio: SCSI low-level driver for EATA-PIOThis driver handles old DPT PM2001, PM2012A. Example:
There are no module parameters. 15.3.18. fdomain: SCSI low-level driver for Future Domain 16xxExample:
There are no module parameters. This driver autoprobes the card and requires installed BIOS. 15.3.19. NCR5380: SCSI low-level driver for NCR5380/53c400Example:
modprobe NCR5380 ncr_irq=xx ncr_addr=xx ncr_dma=xx ncr_5380=1 \
ncr_53c400=1 |
for a port mapped NCR5380 board:
modprobe g_NCR5380 ncr_irq=5 ncr_addr=0x350 ncr_5380=1 |
for a memory mapped NCR53C400 board with interrupts disabled:
modprobe g_NCR5380 ncr_irq=255 ncr_addr=0xc8000 ncr_53c400=1 |
Parameters:
- ncr_irq
the irq the driver is to service. 255 means no or DMA interrupt.
254 to autoprobe for an IRQ line if overridden on the command line.
- ncr_addr
the I/O port address or memory mapped I/O address, whichever
is appropriate, that the driver is to drive
- ncr_dma
the DMA channel the driver is to use
- ncr_5380
1 = set up for a NCR5380 board
- ncr_53c400
1 = set up for a NCR53C400 board
If you bind this driver into the base kernel, you can pass parameters
to it via the kernel boot parameters. See
BootPrompt-HOWTO. 15.3.20. NCR53c406a: SCSI low-level driver for NCR53c406aExample:
There are no module parameters for the LKM, but if you bind this module
into the base kernel, you can pass some parameters via the Linux boot
parameters. See BootPrompt-HOWTO. 15.3.21. 53c7,8xx.o: SCSI low-level driver for NCR53c7,8xxExample:
There are no module parameters for the LKM, but if you bind this module
into the base kernel, you can pass some parameters via the Linux boot
parameters. See BootPrompt-HOWTO. This driver autoprobes the card and requires installed BIOS. 15.3.22. ncr53c8xx: SCSI low-level driver for PCI-SCS NCR538xx familyExample:
There are no module parameters. 15.3.23. ppa: low-level SCSI driver for IOMEGA parallel port ZIP driveSee the file drivers/scsi/README.ppa in the Linux
source tree for details. Example:
modprobe ppa ppa_base=0x378 ppa_nybble=1 |
Parameters:
- ppa_base
Base address of the PPA's I/O port. Default 0x378.
- ppa_speed_high
Delay used in data transfers, in microseconds. Default is 1.
- ppa_speed_low
Delay used in other operations, in microseconds. Default is 6.
- ppa_nybble
1 = Use 4-bit mode. 0 = don't. Default is 0.
15.3.24. pas16: SCSI low-level driver for PAS16Example:
There are no module parameters for the LKM, but if you bind this module
into the base kernel, you can pass some parameters via the Linux boot
parameters. See BootPrompt-HOWTO. This driver autoprobes the card. No BIOS is required. 15.3.25. qlogicfas: SCSI low-level driver for Qlogic FASExample:
There are no module parameters for the LKM, but if you bind this module
into the base kernel, you can pass some parameters via the Linux boot
parameters. See BootPrompt-HOWTO. 15.3.26. qlogicisp: SCSI low-level driver for Qlogic ISPExample:
There are no module parameters for the LKM, but if you bind this module
into the base kernel, you can pass some parameters via the Linux boot
parameters. See BootPrompt-HOWTO. Requires firmware. 15.3.27. seagate: SCSI low-level driver for Seagate, Future DomainThis driver is for Seagate ST-02 and Future Domain TMC-8xx. Example:
There are no module parameters for the LKM, but if you bind this module
into the base kernel, you can pass some parameters via the Linux boot
parameters. See BootPrompt-HOWTO. This driver autoprobes for address only. The IRQ is fixed at 5.
The driver requires installed BIOS. 15.3.28. t128: SCSI low-level driver for Trantor T128/T128F/T228Example:
There are no module parameters for the LKM, but if you bind this module
into the base kernel, you can pass some parameters via the Linux boot
parameters. See BootPrompt-HOWTO. This driver autoprobes the card. The driver requires installed BIOS. 15.3.29. u14-34f: SCSI low-level driver for UltraStor 14F/34FExample:
There are no module parameters for the LKM, but if you bind this module
into the base kernel, you can pass some parameters via the Linux boot
parameters. See BootPrompt-HOWTO. This driver autoprobes the card, but not the
0x310 port. No BIOS is required. 15.3.30. ultrastor: low-level SCSI driver for UltraStorExample:
There are no module parameters for the LKM, but if you bind this module
into the base kernel, you can pass some parameters via the Linux boot
parameters. See BootPrompt-HOWTO. 15.4. Network Device Drivers15.4.1. bsd_comp: optional BSD compressor for PPPExample:
There are no module parameters. This module depends on module ppp. 15.4.2. slhc: SLHC compressor for PPPThis module contains routines to compress and uncompress tcp packets
(for transmission over low speed serial lines). These routines are required by PPP (also ISDN-PP) and SLIP protocols,
and are used by the LKMs that implement those protocols. Example:
There are no module parameters. 15.4.3. dummy: Dummy network interface driverThis is said to be a bit-bucket device (i.e. traffic you send to this
device is consigned into oblivion) with a configurable IP address. It
is most commonly used in order to make your currently inactive SLIP
address seem like a real address for local programs. However, it also functions as a sort of loopback device. You
configure it for a particular IP address and any packet you send to
that IP address via this interface comes back and appears as a packet
received by that interface for that IP address. This is especially
handy for an IP address that would normally be reflected by another
interface (a PPP interface, perhaps), but that interface is down right
now. You can have multiple dummy interfaces. They are named
dummy0, dummy1,
etc. Example:
There are no module parameters. 15.4.4. eql: serial line load balancerIf you have two serial connections to some other computer (this
usually requires two modems and two telephone lines) and you use PPP
(a protocol for sending internet traffic over telephone lines) or SLIP
(an older alternative to PPP) on them, you can make them behave like
one double speed connection using this driver. Example:
There are no module parameters. 15.4.5. dlci: frame relay DLCI driverThis implements the frame relay protocol; frame relay is a fast
low-cost way to connect to a remote internet access provider or to
form a private wide area network. The one physical line from your box
to the local "switch" (i.e. the entry point to the frame relay
network) can carry several logical point-to-point connections to other
computers connected to the frame relay network. To use frame relay,
you need supporting hardware (FRAD) and certain programs from the net-
tools package as explained in
Documentation/networking/framerelay.txt in the
Linux source tree. Example:
There are no module parameters. 15.4.6. sdla: Sangoma S502A FRAD driverThis is a driver for the Sangoma S502A, S502E and S508 Frame Relay
Access Devices. These are multi-protocol cards, but this driver can
drive only frame relay right now. Please read
Documentation/networking/framerelay.txt in the
Linux source tree. Example:
There are no module parameters. This module depends on module dlci. 15.4.7. plip: PLIP network interface driverPLIP (Parallel Line Internet Protocol) is used to create a mini
network consisting of two (or, rarely, more) local machines. The
parallel ports (the connectors virtually all ISA-descendant computers
have that are normally used to attach printers) are connected using
"null printer" or "Turbo Laplink" cables which can transmit 4 bits at
a time or using special PLIP cables, to be used on bidirectional
parallel ports only, which can transmit 8 bits at a time. The cables
can be up to 15 meters long. This works also if one of the machines
runs DOS/Windows and has some PLIP software installed, e.g. the
Crynwr PLIP packet driver and winsock or
NCSA's telnet. See PLIP-Install-HOWTO. Example:
modprobe plip io=0x378 irq=7 |
Parameters:
- io
Port address of parallel port driver is to drive.
- irq
IRQ number of IRQ driver is to service. Default is IRQ 5 for
port at 0x3bc, IRQ 7 for port at 0x378, and IRQ 9 for port
at 0x278.
If you don't specify the io parameter, the
driver probes addresses 0x278, 0x378, and 0x3bc. 15.4.8. ppp: PPP network protocol driverPPP (Point to Point Protocol) is the most common protocol to use over
a serial port (with or without a modem attached) to create an IP
network link between two computers. Along with this kernel driver, you need the user space program
pppd running. See PPP-HOWTO. Example:
There are no module parameters. This module depends on module slhc. The module also accesses serial devices, which are driven by the
serial module, so it depends on that module too.
This dependency is not detected by depmod, so you
either have to declare it manually or load serial
explicitly. 15.4.9. slip: SLIP network protocol driverSLIP (Serial Line Internet Protocol) is like PPP, only older and simpler. Example:
modprobe slip slip_maxdev=1 |
Parameters:
- slip_maxdev
Maximum number of devices the driver may use at one time. Default
is 256.
This module depends on module slhc. The module also accesses serial devices, which are driven by the
serial module, so it depends on that module too.
This dependency is not detected by depmod, so you
either have to declare it manually or load serial
explicitly. 15.4.10. baycom: BAYCOM AX.25 amateur radio driverThis is a driver for Baycom style simple amateur radio modems that
connect to either a serial interface or a parallel interface. The
driver works with the ser12 and par96 designs. For more information, see http://www.baycom.org/~tom. Example:
modprobe baycom modem=1 iobase=0x3f8 irq=4 options=1 |
Parameters:
- major
major number the driver should use; default 60
- modem
modem type of the first channel (minor 0):
- iobase
base address of the port the driver is to drive. Common
values are for ser12 0x3f8, 0x2f8, 0x3e8, 0x2e8 and for
par96/par97 0x378, 0x278, 0x3bc.
- irq
IRQ the driver is to service. Common values are 3 and 4 for ser12
and 7 for for par96/par97.
- options
- 0
use hardware DCD - 1
use software DCD
15.4.11. strip: STRIP (Metricom starmode radio IP) driverSTRIP is a radio protocol developed for the MosquitoNet project to
send Internet traffic using Metricom radios. Metricom radios are
small, battery powered, 100kbit/sec packet radio transceivers, about
the size and weight of a wireless telephone. (You may also have heard
them called "Metricom modems" but we avoid the term "modem" because it
misleads many people into thinking that you can plug a Metricom modem
into a phone line and use it as a modem.) You can use STRIP on any
Linux machine with a serial port, although it is obviously most useful
for people with laptop computers. Example:
There are no module parameters. 15.4.12. wavelan: WaveLAN driverWaveLAN card are for wireless ethernet-like networking. This driver
drives AT&T GIS and NCR WaveLAN cards. Example:
modprobe wavelan io=0x390 irq=0 |
Parameters:
- io
Address of I/O port on the card. Default is 0x390. You can set
a different address on the card, but it is not recommended.
- irq
IRQ the driver is to service. Default is 0. Any other value
is ignored and the card still services IRQ 0.
15.4.13. wic: WIC Radio IP bridge driverThis is a driver for the WIC parallel port radio bridge. Example:
It appears that devices wic0,
wic1 and wic2 are directly
related to corresponding lpN
ports. 15.4.14. scc: Z8530 SCC kiss emulation driverThese cards are used to connect your Linux box to an amateur radio in
order to communicate with other computers. If you want to use this,
read Documentation/networking/z8530drv.txt in the
Linux kernel source tree and HAM-HOWTO. Example:
There are no module parameters. 15.4.15. 8390: General NS8390 Ethernet driver coreThis is driver code for the 8390 Ethernet chip on which many Ethernet
adapters are based. This is not a complete interface driver; the
routines in this module are used by drivers for particular Ethernet
adapters, such as ne and 3c503. Example:
There are no module parameters. 15.4.16. ne: NE2000/NE1000 driverThis is a driver for the venerable NE2000 Ethernet adapter, its
NE1000 forerunner, and all the generic Ethernet adapters that emulate
this de facto standard card.
This is an ISA bus card. For the PCI version, see the ne2k-pci module.
Example:
modprobe ne io=0x300 irq=11 |
Parameters:
- io
Address of I/O port on the card. This parameter is mandatory,
but you may specify 0x000 to have the driver autoprobe 0x300,
0x280, 0x320, 0x340, and 0x360.
- irq
IRQ the driver is to service. If you don't specify this, the
driver determines it by autoIRQ probing.
- bad
The value 0xBAD means to assume the card is poorly designed in
that it does not acknowledge a reset or does not have a valid
0x57,0x57 signature. If you have such a card and do not specify
this option, the driver will not recognize it.
With any other value, the option has no effect.
You can repeat the options to specify additional cards. The
nth occurence of an option applies to the
nth card. This module depends on module 8390. 15.4.17. ne2k-pci: NE2000 PCI DriverThis is a driver for the PCI version of the venerable NE2000 Ethernet
adapter, and all the generic Ethernet adapters that emulate this de
facto standard card. Example:
modprobe ne io=0x300 irq=11 |
Parameters:
- debug
Level of debug messages. 0 means no messages. 1 is the default.
Higher numbers mean more debugging messages.
- options
The value of this option determines what options are set in the
network adapter. Each bit of the value, expressed as a binary
number, controls one option. The only option defined is full
duplex, which is the 6th least significant bit. It is much
easier to use the full_duplex option
instead.
- full_duplex
A "1" value sets the adapter in full duplex mode.
A "0" value sets it in half duplex mode. If you include
the full duplex flag in the flags you specify with the
options parameter, the
full_duplex has no effect.
You may repeat the options and
full_duplex parameters once per network
adapter, for up to 8 network adapter. This driver can drive the following chipsets:
RealTek RTL-8029 Winbond 89C940 Winbond W89C940F KTI ET32P2 NetVin NV5000SC Via 86C926 SureCom NE34 Holtek HT80232 Holtek HT80229 Compex RL2000
This module depends on module 8390. 15.4.18. 3c501: 3COM 3c501 Ethernet driverThis is a driver for 3COM's 3c501 Ethernet adapter. Example:
modprobe 3c501 io=0x280 irq=5
Parameters:
- io
Address of I/O port on the card.
- irq
IRQ the driver is to service. Default is 5.
If you don't specify an I/O port, the driver probes addresses 0x280
and 0x300. 15.4.19. 3c503: 3COM 3c503 driverThis is a driver for 3COM's 3c503 Ethernet adapter. Example:
modprobe 3c503 io=0x300 irq=5 xcvr=0 |
Parameters:
- io
Address of I/O port on the card.
- irq
IRQ the driver is to service.
- xcvr
Determines whether to use external tranceiver.
If you don't specify an I/O port, the driver probes addresses 0x300,
0x310, 0x330, 0x350, 0x250, 0x280, 0x2A0, and 0x2E0.
This module depends on module 8390. 15.4.20. 3c505: 3COM 3c505 driverThis is a driver for 3COM's 3c505 Ethernet adapter. Example:
modprobe 3c503 io=0x300 irq=5 xcvr=0 |
Parameters:
- io
Address of I/O port on the card.
- irq
IRQ the driver is to service.
If you don't specify an I/O port, the driver probes addresses 0x300,
0x280, and 0x310.
This module depends on module 8390. 15.4.21. 3c507: 3COM 3c507 driverThis is a driver for 3COM's 3c507 Ethernet adapter. Example:
modprobe 3c503 io=0x300 irq=5 xcvr=0 |
Parameters:
- io
Address of I/O port on the card.
- irq
IRQ the driver is to service.
If you don't specify an I/O port, the driver probes addresses 0x300,
0x320, 0x340, and 0x280.
This module depends on module 8390. 15.4.22. 3c509: 3COM 3c509/3c579 driverThis is a driver for 3COM's 3c507 and 3c579 Ethernet adapters. Example:
modprobe 3c503 io=0x300 irq=5 xcvr=0 |
Parameters:
- io
Address of I/O port on the card.
- irq
IRQ the driver is to service.
Module load-time probing Works reliably only on EISA, ISA ID-PROBE IS
NOT RELIABLE! Bind this driver into the base kernel for now, if you
need it auto-probing on an ISA-bus machine. 15.4.23. 3c59x: 3COM 3c590 series "Vortex" driverThis is a driver for the following 3COM Ethernet adapters:
Example:
modprobe 3c59x debug=1 options=0,,12 |
Parameters:
- debug
A number selecting the level of debug messages.
- options
This is a string of options numbers separated by commas.
There is one option number for each adapter that the driver
drives (for the case that you have multiple Ethernet adapters
in the system of types driven by this driver). The order of
the option numbers is the order of the cards assigned by the
PCI BIOS.
Each number represents a binary value. In that value, the
lower 3 bits is the media type:
- 0
10baseT - 1
10Mbs AUI - 2
undefined - 3
10base2 (BNC) - 4
100base-TX - 5
100base-FX - 6
MII (not yet available) - 7
Use default setting
The next bit (the "8" bit) is on for full duplex, off for half.
The next bit (the "16" bit) is on to enable bus-master, which is
for experimental use only.
Details of the device driver implementation are at the top of the
source file. 15.4.24. wd: Western Digital/SMC WD80*3 driverThis is a driver for the Western Digital WD80*3 Ethernet adapters. Example:
modprobe wd io=0x300 irq=5 mem=0x0D0000 mem_end=0x0D8000 |
Parameters:
- io
Address of I/O port on the card. - irq
IRQ the driver is to service. - mem
Shared memory address - mem_end
End of shared memory (address of next byte after it).
If you don't specify an I/O port, the driver probes 0x300, 0x280, 0x380,
and 0x240. If you don't specify an IRQ, the driver reads it from the adapter's EEPROM
and with ancient cards that don't have it, the driver uses autoIRQ. The driver depends on module 8390. 15.4.25. smc-ultra: SMC Ultra/EtherEZ driverThis is a driver for the SMC Ultra/EtherEZ Ethernet adapters. Example:
modprobe smc-ultra io=0x200 irq=5 |
Parameters:
- io
Address of I/O port on the card. If you don't specify this,
the adapter probes 0x200, 0x220, 0x240, 0x280, 0x300, 0x340,
and 0x380.
- irq
IRQ the driver is to service. Default is the value read from the
adapter's EEPROM.
This driver depends on module 8390. 15.4.26. smc9194: SMC 9194 driverThis is a driver for SMC's 9000 series of Ethernet cards. Example:
modprobe smc9194 io=0x200 irq=5 ifport=0 |
Parameters:
- io
Address of I/O port on the card. If you don't specify this,
the adapter probes 0x200, 0x220, etc. up through 0x3E0.
- irq
IRQ the driver is to service.
- ifport
Type of Ethernet.
- 0
autodetect - 1
TP - 2
AUI (or 10base2)
The debug level is settable in the source code. 15.4.27. at1700: AT1700 driverThis is a driver for the AT1700 Ethernet adapter. Example:
modprobe at1700 io=0x260 irq=5 |
Parameters:
- io
Address of I/O port on the card. If you don't specify this,
the adapter probes 0x260, 0x280, 0x2A0, 0x240, 0x340, 0x320,
0x380, and 0x300.
- irq
IRQ the driver is to service.
15.4.28. e2100: Cabletron E21xx driverExample:
modprobe e2100 io=0x300 irq=5 mem=0xd0000 xcvr=0 |
Parameters:
- io
Address of I/O port on the card. If you don't specify this,
the adapter probes 0x300, 0x280, 0x380, and 0x220.
- irq
IRQ the card is to generate and the driver is to service. (The
driver sets this value in the card).
- mem
shared memory address. Default is 0xd0000.
- xcvr
- 0
Don't select external transceiver
- 1
Select external transceiver
This module depends on module 8390. 15.4.29. depca: DEPCA, DE10x, DE200, DE201, DE202, DE422 driverThis is a driver for the DEPCA, DE10x, DE200, DE201, DE202, and DE422
Ethernet adapters. Example:
modprobe depca io=0x200 irq=7 |
Parameters:
- io
Address of I/O port on the card. If you don't specify this,
the adapter probes 0x300, and 0x200 on an ISA machine or
0x0c00 on an EISA machine.
- irq
IRQ the driver is to service. Default is 7.
15.4.30. ewrk3: EtherWORKS 3 (DE203, DE204, DE205) driverThis is a driver for the EtherWORKS 3 (DE203, D3204, and DE205)
Ethernet adapters. Example:
modprobe ewrk3 io=0x300 irq=5 |
- io
Address of I/O port on the card. Default is 0x300.
- irq
IRQ the driver is to service. Default is 5.
On an EISA bus, this driver does EISA probing. On an ISA bus, this driver does no autoprobing when loaded as an LKM.
However, if you bind it into the base kernel, it probes addresses
0x100, 0x120, etc. up through 0x3C0 except 0x1E0 and 0x320. 15.4.31. eexpress: EtherExpress 16 driverThis is a driver for the EtherExpress 16 Ethernet adapter. Example:
modprobe eexpress io=0x300 irq=5 |
Parameters:
- io
Address of I/O port on the card. If you don't specify this,
the adapter probes 0x300, 0x270, 0x320, and 0x340.
1 - irq
IRQ the driver is to service. The default is the value read
from the adapter's EEPROM.
15.4.32. eepro: EtherExpressPro driverThis is a driver for the EtherExpressPro Ethernet adapter. Example:
modprobe eepro io=0x200 irq=5 |
Parameters:
- io
Address of I/O port on the card. If you don't specify this,
the adapter probes 0x200, 0x240, 0x280, 0x2C0, 0x300, 0x320, 0x340,
and 0x360.
- irq
IRQ the driver is to service.
15.4.33. fmv18k: Fujitsu FMV-181/182/183/184 driverThis is a driver for the Fujitsu FMV-181, FMV-182, FMV-183, FMV-183,
and FMV-184 Ethernet adapters. Example:
modprobe fmv18x io=0x220 irq=5 |
Parameters:
- io
Address of I/O port on the card. If you don't specify this,
the adapter probes 0x220, 0x240, 0x260, 0x280, 0x2a0, 0x2c0,
0x300, and 0x340.
- irq
IRQ the driver is to service.
15.4.34. hp-plus: HP PCLAN+ (27247B and 27252A) driverThis is a driver for HP's PCLAN+ (27247B and 27252A) Ethernet adapters. Example:
modprobe hp-plus io=0x200 irq=5 |
Parameters:
- io
Address of I/O port on the card. If you don't specify this,
the adapter probes 0x200, 0x240, 0x280, 0x2C0, 0x300, 0x320, and
0x340.
- irq
IRQ the driver is to service. The default is the value the driver
reads from the adapter's configuration register.
This module depends on module 8390. 15.4.35. hp: HP PCLAN (27245, 27xxx) driverThis is a driver for HP's PCLAN (27245 and other 27xxx series) Ethernet
adapters. Example:
modprobe hp io=0x300 irq=5 |
Parameters:
- io
Address of I/O port on the card. If you don't specify this,
the adapter probes 0x300, 0x320, 0x340, 0x280, 0x2C0, 0x200,
and 0x240.
- irq
IRQ the driver is to service. If you don't specify this, the
driver determines it by autoIRQ probing.
This module depends on module 8390. 15.4.36. hp100: HP 10/100VG PCLAN (ISA, EISA, PCI) driverThis is a driver for HP's 10/100VG PCLAN Ethernet adapters. It works with
the ISA, EISA, and PCI versions. Example:
modprobe hp100 hp100_port=0x100 |
Parameters:
- hp100_port
Base address of I/O ports on the card. If you don't specify this,
the driver autoprobes 0x100, 0x120, etc. up through 0x3E0 on an
ISA bus. It does EISA probing on an EISA bus.
15.4.37. eth16i: ICL EtherTeam 16i/32 driverThis is a driver for ICL's EtherTeam 16i (eth16i) and 32i (eth32i)
Ethernet adapters. Example:
modprobe eth16i io=0x2a0 irq=5 |
Parameters:
- io
Address of I/O port on the card. If you don't specify this,
the adapter probes the following adddresses. For the eth16i
adapter: 0x260, 0x280, 0x2A0, 0x340, 0x320, 0x380, and 0x300.
For the eth32i: 0x1000, 0x2000, 0x3000, 0x4000, 0x5000,
0x6000, 0x7000, 0x8000, 0x9000, 0xA000, 0xB000, 0xC000,
0xD000, 0xE000, and 0xF000.
- irq
IRQ the driver is to service. If you don't specify this, the
driver determines it by autoIRQ probing.
15.4.38. ni52: NI5210 driverThis is a driver for the NI5210 Ethernet adapter. Example:
modprobe ni52 io=0x360 irq=9 memstart=0xd0000 memend=0xd4000 |
15.4.39. ac3200: Ansel Communications EISA 3200 driverThis is a driver for the Ansel Communications EISA 3200 Ethernet
adapter. Example:
This module depends on module 8390. 15.4.40. apricot: Apricot Xen-II on board ethernet driverExample:
modprobe apricot io=0x300 irq=10 |
Parameters:
- io
address of base I/O port on card.
- irq
IRQ that driver is to service.
15.4.41. de4x5: DE425, DE434, DE435, DE450, DE500 driverThis is a driver for the DE425, DE434, DE435, DE450, and DE500
Ethernet adapters. Example:
modprobe de4x5 io=0x000b irq=10 is_not_dec=0 |
Parameters:
- io
address of base I/O port.
- irq
IRQ the driver is to service.
- is_not_dec
For a non-DEC card using the DEC 21040, 21041, or 21140 chip,
set this to 1.
15.4.42. tulip: DECchip Tulip (dc21x4x) PCI driverExample:
Read Documentation/networking/tulip.txt in the Linux
source tree. 15.4.43. dgrs: Digi Intl RightSwitch SE-X driverThis is a driver for the Digi International RightSwitch SE-X EISA and
PCI boards. These boards have a 4 (EISA) or 6 (PCI) port Ethernet
switch and a NIC combined into a single board. There is a tool for setting up input and output packet filters on each
port, called dgrsfilt. The management tool lets you watch the performance graphically, as
well as set the SNMP agent IP and IPX addresses, IEEE Spanning Tree,
and Aging time. These can also be set from the command line when the
driver is loaded. There is also a companion management tool, called
xrightswitch. Examples:
modprobe dgrs debug=1 dma=0 spantree=0 hashexpire=300 ipaddr=199,86,8,221
modprobe ipxnet=111 |
Parameters:
- debug
Level of debugging messages to print
- dma
- 0
Disable DMA on PCI card
- 1
Enable DMA on PCI card
- spantree
- 0
Disable IEEE spanning tree
- 1
Enable IEEE spanning tree
- hashexpire
Change address aging time, in seconds. Defaults is 300.
- ipaddr
SNMP agent IP address. Value is IP address in dotted decimal
notation, except with commas instead of periods.
- ipxnet
SNMP agent IPX network number
15.4.44. de600: D-Link DE600 pocket adapter driverThis is a driver for the D-Link DE600 pocket Ethernet adapter. Example:
modprobe de600 de600_debug=0 |
Parameters:
- de600_debug
The driver expects the adapter to be at port 0x378 and
generate IRQ 7. This is the same as the DOS
lpt1 device. These are compile time
options.
15.4.45. de620: D-Link DE620 pocket adapter driverThis is a driver for the D-Link DE620 pocket Ethernet adapter. Example:
modprobe de620 bnc=0 utp=0 io=0x378 irq=7 |
Parameters:
- bnc
- 1
Network is 10Base2
- 0
Network is not 10Base2
- utp
- 1
Network is 10BaseT
- 0
Network is not 10BaseT
- io
I/O port address of port driver is to drive. Default is 0x378.
- irq
IRQ driver is to service. Default is 7.
You can't specify both bnc=1 and
utp=1. 15.4.46. ibmtr: Tropic chipset based token ring adapter driverExample: modprobe ibmtr io=0xa20 irq=5 |
Parameters:
- io
I/O port address of port driver is to drive. Default is 0xa20.
- irq
IRQ driver is to service. By default, the driver determines the
IRQ by autoIRQ probing.
15.4.47. arcnet: ARCnet driverRead The Fine Information in
Documentation/networking/arcnet.txt in the Linux
source tree. Also Arcnet hardware information
arcnet-hardware.txt is found in same place. Example:
modprobe arcnet io=0x300 irq=2 shmem=0xd0000 device=arc1 |
Parameters:
- io
I/O port address of port driver is to drive. If you don't
specify this, the driver probes addresses 0x300, 0x2E0, 0x2F0,
0x2D0, 0x200, 0x210, 0x220, 0x230, 0x240, 0x250, 0x260, 0x270,
0x280, 0x290, 0x2A0, 0x2B0, 0x2C0, 0x310, 0x320, 0x330, 0x340,
0x350, 0x360, 0x370, 0x380, 0x390, 0x3A0, 0x3E0, and 0x3F0.
- irq
IRQ driver is to service. By default, the driver determines the
IRQ by autoIRQ probing.
- device
device name.
15.4.48. isdn: basic ISDN functionsThis module provides ISDN functions used by ISDN adapter drivers. Setting up ISDN networking is a complicated task. Read documentation
found in Documentation/isdn in the Linux source
tree. Example:
There are no module parameters. This module depends on module slhc. 15.4.49. icn: ICN 2B and 4B driverThis is a driver for the ICN 2B and ICN 4B ISDN adapters. Example:
modprobe icn portbase=0x320 membase=0xd0000 icn_id=idstring icn_id2=idstring2 |
Parameters:
- portbase
Address of the base I/O port on the adapter. Defaults is 0x320.
- membase
Address of shared memory. Default is 0xd0000.
- icn_id
idstring for the first adapter. Must start with a character!
This parameter is required.
- icn_id2
idstring for the second adapter. Must start with a character!
This parameter is required with the double card.
This module depends on module isdn. 15.4.50. pcbit: PCBIT-D driverThis is a driver for the PCBIT-D ISDN adapter driver. Example:
modprobe pcbit mem=0xd0000 irq=5 |
Parameters:
- mem
Shared memory address. Default is 0xd0000
- irq
IRQ the driver is to service. Default is 5.
This module depend on module isdn. 15.4.51. teles: Teles/NICCY1016PC/Creatix driverThis is a driver for the Teles/NICCY1016PC/Creatix ISDN adapter.
It can drive up to 16 cards. Example:
modprobe teles io=0xd0000,15,0xd80,2 teles_id=idstring |
Parameters:
- io
This is a whole collection of parameters in one. It's syntax is
io=card1options
[,card2options
,...]
where card1options is a set of options
for the first card, etc.
The syntax of card1options, etc. is
sharedmem,
irq,
portbase,
dprotocol
- sharedmem
Address of shared memory. Default 0xd0000
- irq
IRQ driver is to service.
- portbase
Address of base I/O port.
- dprotocol
D-channel protocol of the card
- 1
1TR6 - 2
EDSS1. This is the default.
- teles_id
Driver ID for accessing with utilities and identification
when using a line monitor. Value must start with a
character! Default: none.
The driver determines the type of card from the port, irq and shared
memory address:
port == 0, shared memory != 0 -> Teles S0-8
port != 0, shared memory != 0 -> Teles S0-16.0
port != 0, shared memory == 0 -> Teles S0-16.3
This module depends on module isdn. 15.5. CDROM Device Drivers15.5.1. aztcd: Aztech/Orchid/Okano/Wearnes/TXC/CDROM driverThis is a driver for the Aztech, Orchid, Okano, Wearnes, TXC, and
CDROM devices (which have special non-SCSI non-ATA interfaces). Example:
modprobe aztcd aztcd=0x340 |
Parameters:
- aztcd
address of base I/O port
Read Documentation/cdrom/aztcd in the Linux
source tree for full information. 15.5.2. gscd: Goldstar R420 CDROM driverThis is a driver for the Goldstar R420 CDROM drive, which does not use
either an ATA or SCSI interface. Example:
Parameters:
- gscd
address of base I/O port. Default is 0x340, which will
work for most applications. You select the address of the
drive with the PN801-1 through PN801-4 jumpers on the
Goldstar Interface Card. Appropriate settings are: 0x300,
0x310, 0x320, 0x330, 0x340, 0x350, 0x360, 0x370, 0x380,
0x390, 0x3A0, 0x3B0, 0x3C0, 0x3D0, 0x3E0, and 0x3F0.
15.5.3. sbpcd: Sound Blaster CDROM driverThis is a driver for the Matsushita, Panasonic, Creative, Longshine, and
TEAC CDROM drives that don't attach via ATA or SCSI. Example:
modprobe sbpcd sbpcd=0x340 |
Parameters:
- sbpcd
address of base I/O port
An additional parameter is an SBPRO setting, as described in
Documentation/cdrom/sbpcd in the Linux source tree. 15.5.4. mcd: Mitsumi CDROM driverThis is a driver for Mitsumi CDROM drives that don't attach via ATA
or SCSI. It does not handle XA or multisession. Example:
modprobe mcd mcd=0x300,11,0x304,5 |
Parameters:
- mcd
This is a comma separated list of i/o base addresses and IRQs,
in pairs.
15.5.5. mcdx: Mitsumi XA/MultiSession driverThis driver is like mcd, only it has XA and
multisession functions. Example:
modprobe mcdx mcdx=0x300,11,0x304,5 |
15.5.6. optcd: Optics Storage DOLPHIN 8000AT CDROM driverThis is the driver for the so-called "dolphin" CDROM drive form Optics
Storage, with the 34-pin Sony-compatible interface. For the
ATA-compatible Optics Storage 8001 drive, you will want the ATAPI
CDROM driver. The driver also seems to work with the Lasermate
CR328A. Example:
modprobe optcd optcd=0x340 |
Parameters:
- optcd
address of base I/O port
15.5.7. cm206: Philips/LMS CM206 CDROM driverThis is the driver for the Philips/LMS cm206 CDROM drive in
combination with the cm260 host adapter card. Example:
modprobe cm206 cm206=0x300,11 |
Parameters:
- cm206
The address of the base I/O port the driver is to drive and
the IRQ the driver is to service, separated by a comma. It doesn't
matter what order you put them in, and you may specify just one,
in which case the other defaults.
15.5.8. sjcd: Sanyo CDR-H94A CDROM driverExample:
modprobe sjcd sjcd_base=0x340 |
Parameters:
- sjcd_base
address of the base I/O port the driver is to drive.
Default is 0x340.
The driver uses no IRQ and no DMA channel. 15.5.9. isp16: ISP16/MAD16/Mozart soft configurable cdrom driverThis is a driver for the ISP16 or MAD16 or Mozart soft configurable
cdrom interface. Example:
modprobe isp16 isp16_cdrom_base=0x340 isp16_cdrom_irq=3
isp16_cdrom_dma=0 isp16_cdrom_type=Sanyo |
Parameters:
- isp16_cdrom_base
address of base I/O port the driver is to drive. Valid values
are 0x340, 0x320, 0x330, and 0x360.
- isp16_cdrom_irq
IRQ the driver is to service. Valid values are 0, 3, 5, 7, 9, 10,
and 11.
- isp16_cdrom_dma
DMA channel the driver is to use with the device. Valid
values are 0, 3, 5, 6, and 7.
- isp16_cdrom_type
Type of device being driven. Valid values are
noisp16, Sanyo,
Panasonic, Sony and
Mitsumi. Note that these values are
case sensitive.
15.5.10. cdu31a: Sony CDU31A/CDU33A CDROM driverExample:
modprobe cdu31a cdu31a_port=0x340 cdu31a_irq=5 |
Parameters:
- cdu31a_port
address of base I/O port the driver is to drive. This parameter
is mandatory.
- cdu31a_irq
IRQ the driver is to service. If you don't specify this,
the driver does not use interrupts.
15.5.11. sonycd535: Sony CDU535 CDROM driverExample:
modprobe sonycd535 sonycd535=0x340 |
Parameters:
- sonycd535
address of the base I/O port the driver is to drive.
15.6. Filesystem Drivers15.6.1. minix: Minix filesystem driverExample:
There are no module parameters. 15.6.2. ext: "Extended" filesystem driverExample:
There are no module parameters. 15.6.3. ext2: "Second extended" filessystem driverExample:
There are no module parameters. 15.6.4. xiafs: xiafs filesystem driverExample:
There are no module parameters. 15.6.5. fat: DOS FAT filesystem functionsThis module provides services for use by the MSDOS and VFAT
filesystem drivers. Example:
There are no module parameters. 15.6.6. msdos: MSDOS filesystem driverExample:
There are no module parameters. This module depends on the module fat. 15.6.7. vfat: VFAT (Windows-95) filesystem driverExample:
There are no module parameters. This module depends on module fat. 15.6.8. umsdos: UMSDOS filesystem driverThis is a driver for the UMSDOS filesystem type, which is a unix style
filesystem built on top of an MSDOS FAT filesystem. Example:
There are no module parameters. This module depends on the fat and
msdos modules. 15.6.9. nfs: NFS filesystem driverExample:
There are no module parameters. 15.6.10. smbfs: SMB filesystem driverSMBFS is a filesystem type which has an SMB protocol interface. This
is the protocol Windows for Workgroups, Windows NT or Lan Manager use
to talk to each other. SMBFS was inspired by Samba, the program
written by Andrew Tridgell that turns any unix host into a file server
for DOS or Windows clients. See ftp://nimbus.anu.edu.au/pub/tridge/samba/ for this interesting
program suite and lots of more information on SMB and NetBIOS over
TCP/IP. There you also find explanation for concepts like netbios name
or share. To use SMBFS, you need a special mount program, which can be found
in the ksmbfs package, found on
ftp://ibiblio.org/pub/Linux/system/Filesystems/smbfs. Example:
There are no module parameters 15.6.11. ncpfs: NCP (Netware) filesystem driverNCPFS is a filesystem type which has an NCP protocol interface,
designed by the Novell Corporation for their NetWare product. NCP is
functionally similar to the NFS used in the TCP/IP community. To
mount a Netware filesystem, you need a special mount program, which
can be found in the ncpfs package.
Homesite for ncpfs is
ftp.gwdg.de/pub/linux/misc/ncpfs, but Ibiblio and its many
mirrors will have it as well. Related products are Linware and
Mars_nwe, which will give Linux partial
NetWare Server functionality. Mars_nwe can be found on ftp.gwdg.de/pub/linux/misc/ncpfs. Example:
There are no module parameters. This module depends on module ipx. 15.6.12. isofs: ISO 9660 (CDROM) filesystem driverExample:
There are no module parameters. 15.6.13. hpfs: OS/2 HPFS filesystem driverThis filesystem driver for OS/2's HPFS filesystem provides only read-only
access. Example:
There are no module parameters. 15.6.14. sysv: System V and Coherent filesystem driverThis is the implementation of the SystemV/Coherent filesystem type for
Linux. It implements all of
Xenix FS SystemV/386 FS Coherent FS
Example:
There are no module parameters. 15.6.15. affs: Amiga FFS filesystem driverExample:
There are no module parameters. 15.6.16. ufs: UFS filesystem driverApparently for mounting disks with FreeBSD and/or Sun partitions. No
documentation exists, apart from The Source. This filesystem driver provides only read-only access. Example:
There are no module parameters. 15.7. Miscellaneous Device Driver15.7.1. misc: device driver for "miscellaneous" character devicesA whole bunch of device types that don't appear in large enough numbers on
a system to deserve major numbers of their own share Major Number 10 and
are collectively called "miscellaneous" character devices. This module
provides the common interface to serve that major number, but there are
individual drivers for the specific device types. Those drivers register
themselves with this driver. Example:
There are no module parameters. 15.8. Serial Device Drivers15.8.1. serial: serial communication port (UART) device driverThis driver drives conventional serial ports (UARTs), but not some
of the specialized high performance multi-port devices. NOTE: serial is required by other modules, such as
ppp and slip. Also it is
required by serial mice and accordingly by
gpm. However this isn't the regular kind
of dependency that is detected by module handling tools, so you must
load serial manually. Example:
There are no module parameters. 15.8.2. cyclades: Cyclades async mux device driverExample:
There are no module parameters. The intelligent boards also need to have their firmware code
downloaded to them. This is done via a user level application supplied
in the driver package called
stlload. Compile this program where ever
you dropped the package files, by typing make. In
its simplest form you can then type stlload in this
directory and that will download firmware into board 0 (assuming board
0 is an EasyConnection 8/64 board). To download to an ONboard, Brumby
or Stallion do: Read the information in the file
Documentation/stallion.txt in the Linux source
tree. 15.8.3. stallion: Stallion EasyIO or EC8/32 device driverThe intelligent boards also need to have their firmware code
downloaded to them. This is done via a user level application supplied
in the driver package called stlload. Read the information in the file
Documentation/stallion.txt in the Linux source
tree. Example:
There are no module parameters. 15.8.4. istallion: Stallion EC8/64, ONboard, Brumby device driverThe intelligent boards also need to have their firmware code
downloaded to them. This is done via a user level application supplied
in the driver package called stlload. Read the information at /usr/src/linux/drivers/char/README.stallion. Example:
There are no module parameters. 15.8.5. riscom8: SDL RISCom/8 card device driverExample:
modprobe riscom8 iobase=0xXXX iobase1=0xXXX iobase2=... |
This driver can drive up to 4 boards at time. 15.9. Parallel Device Drivers15.9.1. lp: Parallel printer device driverExample:
modprobe lp.o io=0x378 irq=0 |
This driver probes ports 0x278, 0x378, and 0x3bc. Note: loading lp without any parameters will
grab all parallel ports. 15.10. Bus Mouse Device Drivers15.10.1. atixlmouse: ATIXL busmouse driverExample:
There are no parameters. This module depends on module misc. 15.10.2. busmouse: Logitech busmouse driverExample:
There are no module parameters. This module depends on module misc.
15.10.3. msbusmouse: Microsoft busmouse driverExample:
There are no module parameters. This module depends on module misc. 15.10.4. psaux: PS/2 mouse (aka "auxiliary device") driverExample:
There are no module parameters. This module depends on module misc. 15.11. Tape Device DriversFor SCSI tape device drivers, see Section 15.3. There are no
LKMs for QIC-02 tape devices, but there is a device driver you can
bind into the base kernel. 15.11.1. ftape: floppy tape (QIC-80/Travan) device driverExample:
Optional parameter tracing can take following
values
- 0
bugs - 1
+ errors - 2
+ warnings - 3
+ information - 4
+ more information - 5
+ program flow - 6
+ fdc/dma info - 7
+ data flow - 8
+ everything else
The default is 3. 15.12. Watchdog Timers15.12.1. WDT: WDT Watchdog timer device driverExample:
There are no module parameters. The device address is hardcoded as 0x240. The IRQ is hardcoded as 14. This module depends on module misc. 15.12.2. softdog: Software Watchdog TimerExample:
There are no module parameters. This module depends on module misc. 15.12.3. pcwd: Berkshire Products PC Watchdog DriverExample:
There are no module parameters. This module depends on module misc. 15.13. Sound Device DriversConfiguring sound is a complex task. Read the files in
directory Documention/sound in
the Linux source tree. Example:
Option: dma_buffsize=32768 |
|