Working with Kernels

Listing Currently-Loaded Modules

You can list all kernel modules that are currently loaded into the kernel by running the lsmodcommand:

~]$ lsmod
Module                  Size  Used by
xfs                   803635  1
exportfs                3424  1 xfs
vfat                    8216  1
fat                    43410  1 vfat
tun                    13014  2
fuse                   54749  2
ip6table_filter         2743  0
ip6_tables             16558  1 ip6table_filter
ebtable_nat             1895  0
ebtables               15186  1 ebtable_nat
ipt_MASQUERADE          2208  6
iptable_nat             5420  1
nf_nat                 19059  2 ipt_MASQUERADE,iptable_nat
rfcomm                 65122  4
ipv6                  267017  33
sco                    16204  2
bridge                 45753  0
stp                     1887  1 bridge
llc                     4557  2 bridge,stp
bnep                   15121  2
l2cap                  45185  16 rfcomm,bnep
cpufreq_ondemand        8420  2
acpi_cpufreq            7493  1
freq_table              3851  2 cpufreq_ondemand,acpi_cpufreq
usb_storage            44536  1
sha256_generic         10023  2
aes_x86_64              7654  5
aes_generic            27012  1 aes_x86_64
cbc                     2793  1
dm_crypt               10930  1
kvm_intel              40311  0
kvm                   253162  1 kvm_intel
[output truncated]

Each row of lsmod output specifies:

the name of a kernel module currently loaded in memory;
the amount of memory it uses; and,
the sum total of processes that are using the module and other modules which depend on it, followed by a list of the names of those modules, if there are any. Using this list, you can first unload all the modules depending the module you want to unload.

Finally, note that lsmod output is less verbose and considerably easier to read than the content of the /proc/modules pseudo-file.

Displaying Information About a Module

You can display detailed information about a kernel module by running the modinfo <module_name> command.

Module names do not end in .ko

When entering the name of a kernel module as an argument to one of the module-init-toolsutilities, do not append a .ko extension to the end of the name. Kernel module names do not have extensions: their corresponding files do.

For example, to display information about the e1000e module, which is the Intel PRO/1000 network driver, run:

Example 25.1. Listing information about a kernel module with lsmod

~]# modinfo e1000e
filename:       /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/net/e1000e/e1000e.ko
version:        1.2.7-k2
license:        GPL
description:    Intel(R) PRO/1000 Network Driver
author:         Intel Corporation, <linux.nics@intel.com>
srcversion:     93CB73D3995B501872B2982
alias:          pci:v00008086d00001503sv*sd*bc*sc*i*
alias:          pci:v00008086d00001502sv*sd*bc*sc*i*
[some alias lines omitted]
alias:          pci:v00008086d0000105Esv*sd*bc*sc*i*
depends:
vermagic:       2.6.32-71.el6.x86_64 SMP mod_unload modversions
parm:           copybreak:Maximum size of packet that is copied to a new buffer on receive (uint)
parm:           TxIntDelay:Transmit Interrupt Delay (array of int)
parm:           TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int)
parm:           RxIntDelay:Receive Interrupt Delay (array of int)
parm:           RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int)
parm:           InterruptThrottleRate:Interrupt Throttling Rate (array of int)
parm:           IntMode:Interrupt Mode (array of int)
parm:           SmartPowerDownEnable:Enable PHY smart power down (array of int)
parm:           KumeranLockLoss:Enable Kumeran lock loss workaround (array of int)
parm:           WriteProtectNVM:Write-protect NVM [WARNING: disabling this can lead to corrupted NVM] (array of int)
parm:           CrcStripping:Enable CRC Stripping, disable if your BMC needs the CRC (array of int)
parm:           EEE:Enable/disable on parts that support the feature (array of int)

Here are descriptions of a few of the fields in modinfo output:

filename: The absolute path to the .ko kernel object file. You can use modinfo -n as a shortcut command for printing only the filename field.
description: A short description of the module. You can use modinfo -d as a shortcut command for printing only the description field.
alias: The alias field appears as many times as there are aliases for a module, or is omitted entirely if there are none.
depends: This field contains a comma-separated list of all the modules this module depends on.

Omitting the depends field

If a module has no dependencies, the depends field may be omitted from the output.
parm

Each parm field presents one module parameter in the form parameter_name:description, where:

parameter_name is the exact syntax you should use when using it as a module parameter on the command line, or in an option line in a .conf file in the /etc/modprobe.d/ directory; and,
description is a brief explanation of what the parameter does, along with an expectation for the type of value the parameter accepts (such as int, unit or array of int) in parentheses.

You can list all parameters that the module supports by using the -p option. However, because useful value type information is omitted from modinfo -p output, it is more useful to run:

Example 25.2. Listing module parameters

~]# modinfo e1000e | grep "^parm" | sort
parm:           copybreak:Maximum size of packet that is copied to a new buffer on receive (uint)
parm:           CrcStripping:Enable CRC Stripping, disable if your BMC needs the CRC (array of int)
parm:           EEE:Enable/disable on parts that support the feature (array of int)
parm:           InterruptThrottleRate:Interrupt Throttling Rate (array of int)
parm:           IntMode:Interrupt Mode (array of int)
parm:           KumeranLockLoss:Enable Kumeran lock loss workaround (array of int)
parm:           RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int)
parm:           RxIntDelay:Receive Interrupt Delay (array of int)
parm:           SmartPowerDownEnable:Enable PHY smart power down (array of int)
parm:           TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int)
parm:           TxIntDelay:Transmit Interrupt Delay (array of int)
parm:           WriteProtectNVM:Write-protect NVM [WARNING: disabling this can lead to corrupted NVM] (array of int)

Loading a Module

To load a kernel module, run modprobe <module_name> as root. For example, to load the wacom module, run:

~]# modprobe wacom

By default, modprobe attempts to load the module from /lib/modules/<kernel_version>/kernel/drivers/. In this directory, each type of module has its own subdirectory, such as net/ and scsi/, for network and SCSI interface drivers respectively.

Some modules have dependencies, which are other kernel modules that must be loaded before the module in question can be loaded. The modprobe command always takes dependencies into account when performing operations. When you ask modprobe to load a specific kernel module, it first examines the dependencies of that module, if there are any, and loads them if they are not already loaded into the kernel. modprobe resolves dependencies recursively: it will load all dependencies of dependencies, and so on, if necessary, thus ensuring that all dependencies are always met.

You can use the -v (or --verbose) option to cause modprobe to display detailed information about what it is doing, which may include loading module dependencies. The following is an example of loading the Fibre Channel over Ethernet module verbosely:

Example 25.3. modprobe -v shows module dependencies as they are loaded

~]# modprobe -v fcoe
insmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/scsi/scsi_tgt.ko
insmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/scsi/scsi_transport_fc.ko
insmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/scsi/libfc/libfc.ko
insmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/scsi/fcoe/libfcoe.ko
insmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/scsi/fcoe/fcoe.ko

Example 25.3, “modprobe -v shows module dependencies as they are loaded” shows that modprobeloaded the scsi_tgt, scsi_transport_fc, libfc and libfcoe modules as dependencies before finally loading fcoe. Also note that modprobe used the more “primitive” insmod command to insert the modules into the running kernel.

Always use modprobe instead of insmod!

Although the insmod command can also be used to load kernel modules, it does not resolve dependencies. Because of this, you should always load modules using modprobe instead.

Unloading a Module

You can unload a kernel module by running modprobe -r <module_name> as root. For example, assuming that the wacom module is already loaded into the kernel, you can unload it by running:

~]# modprobe -r wacom

However, this command will fail if a process is using:

the wacom module,
a module that wacom directly depends on, or,
any module that wacom—through the dependency tree—depends on indirectly.

Refer to Section 25.1, “Listing Currently-Loaded Modules” for more information about using lsmod to obtain the names of the modules which are preventing you from unloading a certain module.

For example, if you want to unload the firewire_ohci module (because you believe there is a bug in it that is affecting system stability, for example), your terminal session might look similar to this:

~]# modinfo -F depends firewire_ohci
depends:        firewire-core
~]# modinfo -F depends firewire_core
depends:        crc-itu-t
~]# modinfo -F depends crc-itu-t
depends:

You have figured out the dependency tree (which does not branch in this example) for the loaded Firewire modules: firewire_ohci depends on firewire_core, which itself depends on crc-itu-t.

You can unload firewire_ohci using the modprobe -v -r <module_name> command, where -r is short for --remove and -v for --verbose:

~]# modprobe -r -v firewire_ohci
rmmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/firewire/firewire-ohci.ko
rmmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/firewire/firewire-core.ko
rmmod /lib/modules/2.6.32-71.el6.x86_64/kernel/lib/crc-itu-t.ko

The output shows that modules are unloaded in the reverse order that they are loaded, given that no processes depend on any of the modules being unloaded.

Do not use rmmod directly!

Although the rmmod command can be used to unload kernel modules, it is recommended to use modprobe -r instead.

Setting Module Parameters

Like the kernel itself, modules can also take parameters that change their behavior. Most of the time, the default ones work well, but occasionally it is necessary or desirable to set custom parameters for a module. Because parameters cannot be dynamically set for a module that is already loaded into a running kernel, there are two different methods for setting them.

You can unload all dependencies of the module you want to set parameters for, unload the module using modprobe -r, and then load it with modprobe along with a list of customized parameters. This method is often used when the module does not have many dependencies, or to test different combinations of parameters without making them persistent, and is the method covered in this section.
Alternatively, you can list the new parameters in an existing or newly-created file in the /etc/modprobe.d/ directory. This method makes the module parameters persistent by ensuring that they are set each time the module is loaded, such as after every reboot or modprobe command. This method is covered in Section 25.6, “Persistent Module Loading”, though the following information is a prerequisite.

You can use modprobe to load a kernel module with custom parameters using the following command line format:

Example 25.4. Supplying optional parameters when loading a kernel module

~]# modprobe <module_name> [parameter=value]

When loading a module with custom parameters on the command line, be aware of the following:

You can enter multiple parameters and values by separating them with spaces.
Some module parameters expect a list of comma-separated values as their argument. When entering the list of values, do not insert a space after each comma, or modprobe will incorrectly interpret the values following spaces as additional parameters.
The modprobe command silently succeeds with an exit status of 0 if:
- it successfully loads the module, or
- the module is already loaded into the kernel.
Thus, you must ensure that the module is not already loaded before attempting to load it with custom parameters. The modprobe command does not automatically reload the module, or alert you that it is already loaded.

Here are the recommended steps for setting custom parameters and then loading a kernel module. This procedure illustrates the steps using the e1000e module, which is the network driver for Intel PRO/1000 network adapters, as an example:

Procedure 25.1. Loading a Kernel Module with Custom Parameters

First, ensure the module is not already loaded into the kernel:
```
~]# lsmod |grep e1000e
~]#
```
Output indicates that the module is already loaded into the kernel, in which case you must first unload it before proceeding. Refer to Section 25.4, “Unloading a Module” for instructions on safely unloading it.
Load the module and list all custom parameters after the module name. For example, if you wanted to load the Intel PRO/1000 network driver with the interrupt throttle rate set to 3000 interrupts per second for the first, second and third instances of the driver, and Energy Efficient Ethernet (EEE) turned on ^[6], you would run, as root:
```
~]# modprobe e1000e InterruptThrottleRate=3000,3000,3000 EEE=1
```
This example illustrates passing multiple values to a single parameter by separating them with commas and omitting any spaces between them.

Persistent Module Loading

As shown in Example 25.1, “Listing information about a kernel module with lsmod”, many kernel modules are loaded automatically at boot time. You can specify additional modules to be loaded by creating a new <file_name>.modules file in the /etc/sysconfig/modules/ directory, where <file_name> is any descriptive name of your choice. Your <file_name>.modules files are treated by the system startup scripts as shell scripts, and as such should begin with an interpreter directive (also called a “bang line”) as their first line:

Example 25.5. First line of a file_name.modules file

#!/bin/sh

Additionally, the <file_name>.modules file should be executable. You can make it executable by running:

modules]# chmod +x <file_name>.modules

For example, the following bluez-uinput.modules script loads the uinput module:

Example 25.6. /etc/sysconfig/modules/bluez-uinput.modules

#!/bin/sh

if [ ! -c /dev/input/uinput ] ; then
        exec /sbin/modprobe uinput >/dev/null 2>&1
fi

The if-conditional statement on the third line ensures that the /dev/input/uinput file doesnot already exist (the ! symbol negates the condition), and, if that is the case, loads the uinputmodule by calling exec /sbin/modprobe uinput. Note that the uinput module creates the /dev/input/uinput file, so testing to see if that file exists serves as verification of whether the uinput module is loaded into the kernel.

The following >/dev/null 2>&1 clause at the end of that line redirects any output to /dev/null so that the modprobe command remains quiet.

Working with Kernels

Listing Currently-Loaded Modules

Displaying Information About a Module

Loading a Module