In 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).
You 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.
a.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:
modprobe binfmt_aout |
ELF 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:
modprobe binfmt_elf |
Java 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:
modprobe binfmt_java |
This 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:
Sets the bit mask of allowed drives to allow only units 0 and 1. Obsolete, as this is the default setting anyways
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.
Tells the floppy driver that your floppy controller should be used with caution.
Tells the floppy driver that you have only floppy controller (default).
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
Like above, but with default address
Tells the floppy driver that you have an IBM Thinkpad model notebook computer. Thinkpads use an inverted convention for the disk change line.
Tells the floppy driver that you don't have a Thinkpad.
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".
Same as nodma.
Tells the floppy driver that a workable DMA channel is available (the default).
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.
Enables the FIFO (default)
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.
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:
Use the value of the physical CMOS
5 1/4 DD
5 1/4 HD
3 1/2 DD
3 1/2 HD
3 1/2 ED
3 1/2 ED
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)
Print a warning message when an unexpected interrupt is received. (default behavior)
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.)
Same as no_unexpected_interrupts.
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.
Print debugging messages
Print informational messages for some operations (disk change notifications, warnings about over and underruns, and about autodetection)
Uses a less noisy way to clear the disk change line (which doesn't involve seeks). Implied by daring.
Tells the driver to expect interrupts on IRQ nr instead of the conventional IRQ 6.
Tells the driver to use DMA channel nr instead of the conventional DMA channel 2.
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.
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.
Sets the bitmask of allowed drives to all drives. Use this if you have more than two drives connected to a floppy controller.
This 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:
modprobe loop |
Module Parameters:
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.
This 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:
modprobe linear |
There are no module parameters.
This 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:
modprobe raid0 |
There are no module parameters.
A 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:
modprobe rd |
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.
Detailed 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.*.
Example:
modprobe sd_mod |
There are no module parameters.
Example:
modprobe st |
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.
Example:
modprobe sr_mod |
There are no module parameters.
See the explanation of this special high-level driver above.
Example:
modprobe sg |
There are no module parameters.
Example:
modprobe wd7000 |
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.
Example:
modprobe aha152x |
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.
Example:
modprobe aha1542 |
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.
Example:
modprobe aha1740 |
There are no module parameters.
This driver autoprobes the card.
Example:
modprobe aic7xxx |
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.
Example:
modprobe advansys asc_iopflag=1 asc_ioport=0x110,0x330 asc_dbglvl=1 |
Module Parameters:
enable port scanning
disable port scanning
I/O port addresses to scan for Advansys SCSI adapters
debugging level:
Errors only
High level tracing
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.
Example:
modprobe in2000 |
There are no module parameters.
This driver autoprobes the card. No BIOS is required.
The 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:
modprobe BusLogic |
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.
Example:
modprobe dtc |
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.
This driver handles DPT PM2011/021/012/022/122/322.
Example:
modprobe eata |
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 handles DPT, NEC, AT&T, SNI, AST, Olivetti, and Alphatronix.
This driver handles DPT Smartcache, Smartcache III and SmartRAID.
Example:
modprobe eata_dma |
There are no module parameters.
Autoprobe works in all configurations.
This driver handles old DPT PM2001, PM2012A.
Example:
modprobe eata_pio |
There are no module parameters.
Example:
modprobe fdomain |
There are no module parameters.
This driver autoprobes the card and requires installed BIOS.
Example:
modprobe NCR5380 ncr_irq=xx ncr_addr=xx ncr_dma=xx ncr_5380=1 \
ncr_53c400=1 |
modprobe g_NCR5380 ncr_irq=5 ncr_addr=0x350 ncr_5380=1 |
modprobe g_NCR5380 ncr_irq=255 ncr_addr=0xc8000 ncr_53c400=1 |
Parameters:
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.
the I/O port address or memory mapped I/O address, whichever is appropriate, that the driver is to drive
the DMA channel the driver is to use
1 = set up for a NCR5380 board
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.
Example:
modprobe NCR53c406a |
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.
Example:
modprobe 53c7,8xx |
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.
Example:
modprobe ncr53c8xx |
There are no module parameters.
See the file drivers/scsi/README.ppa in the Linux source tree for details.
Example:
modprobe ppa ppa_base=0x378 ppa_nybble=1 |
Parameters:
Base address of the PPA's I/O port. Default 0x378.
Delay used in data transfers, in microseconds. Default is 1.
Delay used in other operations, in microseconds. Default is 6.
1 = Use 4-bit mode. 0 = don't. Default is 0.
Example:
modprobe pas16 |
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.
Example:
modprobe qlogicfas |
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.
Example:
modprobe qlogicisp |
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.
This driver is for Seagate ST-02 and Future Domain TMC-8xx.
Example:
modprobe seagate |
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.
Example:
modprobe t128 |
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.
Example:
modprobe u14-34f |
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.
Example:
modprobe bsd_comp |
There are no module parameters.
This module depends on module ppp.
This 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:
modprobe slhc |
There are no module parameters.
This 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:
modprobe dummy |
There are no module parameters.
If 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:
modprobe eql |
There are no module parameters.
This 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:
modprobe dlci |
There are no module parameters.
This 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:
modprobe sdla |
There are no module parameters.
This module depends on module dlci.
PLIP (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:
Port address of parallel port driver is to drive.
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.
PPP (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:
modprobe ppp |
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.
SLIP (Serial Line Internet Protocol) is like PPP, only older and simpler.
Example:
modprobe slip slip_maxdev=1 |
Parameters:
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.
This 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 number the driver should use; default 60
modem type of the first channel (minor 0):
ser12
par96/par97
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 the driver is to service. Common values are 3 and 4 for ser12 and 7 for for par96/par97.
use hardware DCD
use software DCD
STRIP 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:
modprobe strip |
There are no module parameters.
WaveLAN 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:
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 the driver is to service. Default is 0. Any other value is ignored and the card still services IRQ 0.
This is a driver for the WIC parallel port radio bridge.
Example:
modprobe wic |
It appears that devices wic0, wic1 and wic2 are directly related to corresponding lpN ports.
These 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:
modprobe scc |
There are no module parameters.
This 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:
modprobe 8390 |
There are no module parameters.
This 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:
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 the driver is to service. If you don't specify this, the driver determines it by autoIRQ probing.
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.
This 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:
Level of debug messages. 0 means no messages. 1 is the default. Higher numbers mean more debugging messages.
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.
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.
This is a driver for 3COM's 3c501 Ethernet adapter.
Example: modprobe 3c501 io=0x280 irq=5
Parameters:
Address of I/O port on the card.
IRQ the driver is to service. Default is 5.
This is a driver for 3COM's 3c503 Ethernet adapter.
Example:
modprobe 3c503 io=0x300 irq=5 xcvr=0 |
Parameters:
Address of I/O port on the card.
IRQ the driver is to service.
Determines whether to use external tranceiver.
no
yes
This module depends on module 8390.
This is a driver for 3COM's 3c505 Ethernet adapter.
Example:
modprobe 3c503 io=0x300 irq=5 xcvr=0 |
Parameters:
Address of I/O port on the card.
IRQ the driver is to service.
This module depends on module 8390.
This is a driver for 3COM's 3c507 Ethernet adapter.
Example:
modprobe 3c503 io=0x300 irq=5 xcvr=0 |
Parameters:
Address of I/O port on the card.
IRQ the driver is to service.
This module depends on module 8390.
This is a driver for 3COM's 3c507 and 3c579 Ethernet adapters.
Example:
modprobe 3c503 io=0x300 irq=5 xcvr=0 |
Parameters:
Address of I/O port on the card.
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.
This is a driver for the following 3COM Ethernet adapters:
3c590 Vortex 10Mbps.
3c595 Vortex 100baseTX.
3c595 Vortex 100baseT4.
3c595 Vortex 100base-MII.
EISA Vortex 3c597.
Example:
modprobe 3c59x debug=1 options=0,,12 |
Parameters:
A number selecting the level of debug messages.
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:
10baseT
10Mbs AUI
undefined
10base2 (BNC)
100base-TX
100base-FX
MII (not yet available)
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.
This is a driver for the Western Digital WD80*3 Ethernet adapters.
Example:
modprobe wd io=0x300 irq=5 mem=0x0D0000 mem_end=0x0D8000 |
Parameters:
Address of I/O port on the card.
IRQ the driver is to service.
Shared memory address
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.
This is a driver for the Western Digital WD80*3 Ethernet adapters.
Example:
modprobe smc-ultra io=0x200 irq=5 |
Parameters:
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 the driver is to service. Default is the value read from the adapter's EEPROM.
This driver depends on module 8390.
This is a driver for SMC's 9000 series of Ethernet cards.
Example:
modprobe smc9194 io=0x200 irq=5 ifport=0 |
Parameters:
Address of I/O port on the card. If you don't specify this, the adapter probes 0x200, 0x220, etc. up through 0x3E0.
IRQ the driver is to service.
Type of Ethernet.
autodetect
TP
AUI (or 10base2)
The debug level is settable in the source code.
This is a driver for the AT1700 Ethernet adapter.
Example:
modprobe at1700 io=0x260 irq=5 |
Parameters:
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 the driver is to service.
Example:
modprobe e2100 io=0x300 irq=5 mem=0xd0000 xcvr=0 |
Parameters:
Address of I/O port on the card. If you don't specify this, the adapter probes 0x300, 0x280, 0x380, and 0x220.
IRQ the card is to generate and the driver is to service. (The driver sets this value in the card).
shared memory address. Default is 0xd0000.
Don't select external transceiver
Select external transceiver
This module depends on module 8390.
This is a driver for the DEPCA, DE10x, DE200, DE201, DE202, and DE422 Ethernet adapters.
Example:
modprobe depca io=0x200 irq=7 |
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 the driver is to service. Default is 7.
This is a driver for the EtherWORKS 3 (DE203, D3204, and DE205) Ethernet adapters.
Example:
modprobe ewrk3 io=0x300 irq=5 |
Address of I/O port on the card. Default is 0x300.
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.
This is a driver for the EtherExpress 16 Ethernet adapter.
Example:
modprobe eexpress io=0x300 irq=5 |
Parameters:
Address of I/O port on the card. If you don't specify this, the adapter probes 0x300, 0x270, 0x320, and 0x340. 1
IRQ the driver is to service. The default is the value read from the adapter's EEPROM.
This is a driver for the EtherExpressPro Ethernet adapter.
Example:
modprobe eepro io=0x200 irq=5 |
Parameters:
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 the driver is to service.
This 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:
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 the driver is to service.
This is a driver for HP's PCLAN+ (27247B and 27252A) Ethernet adapters.
Example:
modprobe hp-plus io=0x200 irq=5 |
Parameters:
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 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.
This is a driver for HP's PCLAN (27245 and other 27xxx series) Ethernet adapters.
Example:
modprobe hp io=0x300 irq=5 |
Parameters:
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 the driver is to service. If you don't specify this, the driver determines it by autoIRQ probing.
This module depends on module 8390.
This 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:
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.
This is a driver for ICL's EtherTeam 16i (eth16i) and 32i (eth32i) Ethernet adapters.
Example:
modprobe eth16i io=0x2a0 irq=5 |
Parameters:
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 the driver is to service. If you don't specify this, the driver determines it by autoIRQ probing.
This is a driver for the NI5210 Ethernet adapter.
Example:
modprobe ni52 io=0x360 irq=9 memstart=0xd0000 memend=0xd4000 |
This is a driver for the Ansel Communications EISA 3200 Ethernet adapter.
Example:
modprobe ac3200 |
This module depends on module 8390.
Example:
modprobe apricot io=0x300 irq=10 |
Parameters:
address of base I/O port on card.
IRQ that driver is to service.
This 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:
address of base I/O port.
IRQ the driver is to service.
For a non-DEC card using the DEC 21040, 21041, or 21140 chip, set this to 1.
Example:
modprobe tulip |
Read Documentation/networking/tulip.txt in the Linux source tree.
This 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:
Level of debugging messages to print
Disable DMA on PCI card
Enable DMA on PCI card
Disable IEEE spanning tree
Enable IEEE spanning tree
Change address aging time, in seconds. Defaults is 300.
SNMP agent IP address. Value is IP address in dotted decimal notation, except with commas instead of periods.
SNMP agent IPX network number
This is a driver for the D-Link DE600 pocket Ethernet adapter.
Example:
modprobe de600 de600_debug=0 |
Parameters:
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.
This is a driver for the D-Link DE620 pocket Ethernet adapter.
Example:
modprobe de620 bnc=0 utp=0 io=0x378 irq=7 |
Parameters:
Network is 10Base2
Network is not 10Base2
Network is 10BaseT
Network is not 10BaseT
I/O port address of port driver is to drive. Default is 0x378.
IRQ driver is to service. Default is 7.
You can't specify both bnc=1 and utp=1.
Example:
modprobe ibmtr io=0xa20 irq=5 |
Parameters:
I/O port address of port driver is to drive. Default is 0xa20.
IRQ driver is to service. By default, the driver determines the IRQ by autoIRQ probing.
Read 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:
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 driver is to service. By default, the driver determines the IRQ by autoIRQ probing.
device name.
This 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:
modprobe isdn |
There are no module parameters.
This module depends on module slhc.
This 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:
Address of the base I/O port on the adapter. Defaults is 0x320.
Address of shared memory. Default is 0xd0000.
idstring for the first adapter. Must start with a character! This parameter is required.
idstring for the second adapter. Must start with a character! This parameter is required with the double card.
This module depends on module isdn.
This is a driver for the PCBIT-D ISDN adapter driver.
Example:
modprobe pcbit mem=0xd0000 irq=5 |
Parameters:
Shared memory address. Default is 0xd0000
IRQ the driver is to service. Default is 5.
This module depend on module isdn.
This 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:
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
Address of shared memory. Default 0xd0000
IRQ driver is to service.
Address of base I/O port.
D-channel protocol of the card
1TR6
EDSS1. This is the default.
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.
This 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:
address of base I/O port
Read Documentation/cdrom/aztcd in the Linux source tree for full information.
This is a driver for the Goldstar R420 CDROM drive, which does not use either an ATA or SCSI interface.
Example:
modprobe gscd gscd=0x340 |
Parameters:
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.
This 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:
address of base I/O port
An additional parameter is an SBPRO setting, as described in Documentation/cdrom/sbpcd in the Linux source tree.
This 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:
This is a comma separated list of i/o base addresses and IRQs, in pairs.
This driver is like mcd, only it has XA and multisession functions.
Example:
modprobe mcdx mcdx=0x300,11,0x304,5 |
This 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:
address of base I/O port
This 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:
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.
Example:
modprobe sjcd sjcd_base=0x340 |
Parameters:
address of the base I/O port the driver is to drive. Default is 0x340.
The driver uses no IRQ and no DMA channel.
This 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:
address of base I/O port the driver is to drive. Valid values are 0x340, 0x320, 0x330, and 0x360.
IRQ the driver is to service. Valid values are 0, 3, 5, 7, 9, 10, and 11.
DMA channel the driver is to use with the device. Valid values are 0, 3, 5, 6, and 7.
Type of device being driven. Valid values are noisp16, Sanyo, Panasonic, Sony and Mitsumi. Note that these values are case sensitive.
Example:
modprobe cdu31a cdu31a_port=0x340 cdu31a_irq=5 |
Parameters:
address of base I/O port the driver is to drive. This parameter is mandatory.
IRQ the driver is to service. If you don't specify this, the driver does not use interrupts.
Example:
modprobe ext2 |
There are no module parameters.
This module provides services for use by the MSDOS and VFAT filesystem drivers.
Example:
modprobe fat |
There are no module parameters.
Example:
modprobe msdos |
There are no module parameters.
This module depends on the module fat.
Example:
modprobe vfat |
There are no module parameters.
This module depends on module fat.
This is a driver for the UMSDOS filesystem type, which is a unix style filesystem built on top of an MSDOS FAT filesystem.
Example:
modprobe vfat |
There are no module parameters.
This module depends on the fat and msdos modules.
SMBFS 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:
modprobe smbfs |
There are no module parameters
NCPFS 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:
modprobe ncpfs |
There are no module parameters.
This module depends on module ipx.
Example:
modprobe isofs |
There are no module parameters.
This filesystem driver for OS/2's HPFS filesystem provides only read-only access.
Example:
modprobe hpfs |
There are no module parameters.
A 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:
modprobe misc |
There are no module parameters.
This 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:
modprobe serial |
There are no module parameters.
Example:
modprobe cyclades |
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.
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.
Read the information in the file Documentation/stallion.txt in the Linux source tree.
Example:
modprobe stallion |
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.
Read the information at /usr/src/linux/drivers/char/README.stallion.
Example:
modprobe istallion |
There are no module parameters.
Example:
modprobe atixlmouse |
There are no parameters.
This module depends on module misc.
Example:
modprobe busmouse |
There are no module parameters.
This module depends on module misc.
For SCSI tape device drivers, see Section 13.3. There are no LKMs for QIC-02 tape devices, but there is a device driver you can bind into the base kernel.
Example:
modprobe wdt |
There are no module parameters.
The device address is hardcoded as 0x240. The IRQ is hardcoded as 14.
This module depends on module misc.