5 Kernel Modules

WARNING:

Oracle Linux 7 is now in Extended Support. See Oracle Linux Extended Support and Oracle Open Source Support Policies for more information.

Migrate applications and data to Oracle Linux 8 or Oracle Linux 9 as soon as possible.

This chapter describes how to load, unload, and modify the behavior of kernel modules.

About Kernel Modules

The boot loader loads the kernel into memory. You can add new code to the kernel by including the source files in the kernel source tree and recompiling the kernel. Kernel modules, which can be dynamically loaded and unloaded on demand, provide device drivers that allow the kernel to access new hardware, support different file system types, and extend its functionality in other ways. To avoid wasting memory on unused device drivers, Oracle Linux supports loadable kernel modules (LKMs), which allow a system to run with only the device drivers and kernel code that it requires loaded into memory.

Listing Information about Loaded Modules

Use the lsmod command to list the modules that are currently loaded into the kernel.

sudo lsmod
Module                  Size  Used by
nls_utf8                1405  1 
fuse                   59164  0 
tun                    12079  0  
autofs4                22739  3 
...
ppdev                   7901  0 
parport_pc             21262  0 
parport                33812  2 ppdev,parport_pc
...

Note:

This command produces its output by reading the /proc/modules file.

The output shows the module name, the amount of memory it uses, the number of processes using the module and the names of other modules on which it depends. In the sample output, the module parport depends on the modules ppdev and parport_pc, which are loaded in advance of parport. Two processes are currently using all three modules.

To display detailed information about a module, use the modinfo command, for example:

sudo modinfo ahci
filename:       /lib/modules/2.6.32-300.27.1.el6uek.x86_64/kernel/drivers/ata/ahci.ko
version:        3.0
license:        GPL
description:    AHCI SATA low-level driver
author:         Jeff Garzik
srcversion:     AC5EC885397BF332DE16389
alias:          pci:v*d*sv*sd*bc01sc06i01*
...
depends:        
vermagic:       2.6.32-300.27.1.el6uek.x86_64 SMP mod_unload modversions 
parm:           skip_host_reset:skip global host reset (0=don't skip, 1=skip) (int)
parm:           ignore_sss:Ignore staggered spinup flag (0=don't ignore, 1=ignore) (int)
...

The output includes the following information:

filename

Absolute path of the kernel object file.

version

Version number of the module.

description

Short description of the module.

srcversion

Hash of the source code used to create the module.

alias

Internal alias names for the module.

depends

Comma-separated list of any modules on which this module depends.

vermagic

Kernel version that was used to compile the module, which is checked against the current kernel when the module is loaded.

parm

Module parameters and descriptions.

Modules are loaded into the kernel from kernel object (ko) files in the /lib/modules/kernel_version/kernel directory. To display the absolute path of a kernel object file, specify the -n option, for example:

sudo modinfo -n parport
/lib/modules/2.6.32-300.27.1.el6uek.x86_64/kernel/drivers/parport/parport.ko

For more information, see the lsmod(5) and modinfo(8) manual pages.

Loading and Unloading Modules

The modprobe command loads kernel modules, for example:

sudo modprobe nfs
sudo lsmod | grep nfs
nfs                   266415  0 
lockd                  66530  1 nfs
fscache                41704  1 nfs
nfs_acl                 2477  1 nfs
auth_rpcgss            38976  1 nfs
sunrpc                204268  5 nfs,lockd,nfs_acl,auth_rpcgss

Use the -v verbose option to show if any additional modules are loaded to resolve dependencies.

sudo modprobe -v nfs
insmod /lib/modules/2.6.32-300.27.1.el6uek.x86_64/kernel/net/sunrpc/auth_gss/auth_rpcgss.ko 
insmod /lib/modules/2.6.32-300.27.1.el6uek.x86_64/kernel/fs/nfs_common/nfs_acl.ko 
insmod /lib/modules/2.6.32-300.27.1.el6uek.x86_64/kernel/fs/fscache/fscache.ko 
...

To determine the dependencies, the modprobe command queries the /lib/modules/kernel_version/modules.dep file, which the depmod utility creates when you install kernel modules.

Note:

modprobe does not reload modules that are already loaded. You must first unload a module before you can load it again.

Use the -r option to unload kernel modules, for example:

sudo modprobe -rv nfs
rmmod /lib/modules/2.6.32-300.27.1.el6uek.x86_64/kernel/fs/nfs/nfs.ko
rmmod /lib/modules/2.6.32-300.27.1.el6uek.x86_64/kernel/fs/lockd/lockd.ko
rmmod /lib/modules/2.6.32-300.27.1.el6uek.x86_64/kernel/fs/fscache/fscache.ko
...

Modules are unloaded in the reverse order that they were loaded. Modules are not unloaded if a process or another loaded module requires them.

Note:

modprobe uses the insmod and rmmod utilities to load and unload modules. As insmod and rmmod do not resolve module dependencies, do not use these utilities.

For more information, see the modprobe(8) and modules.dep(5) manual pages.

About Module Parameters

Modules accept parameters that you can specify using modprobe to modify a module's behavior:

sudo modprobe module_name parameter=value ...

Use spaces to separate multiple parameter/value pairs. Array values are represented by a comma-separated list, for example:

sudo modprobe foo arrayparm=1,2,3,4

You can also change the values of some parameters for loaded modules and built-in drivers by writing the new value to a file under /sys/module/module_name/parameters, for example:

echo 0 > /sys/module/ahci/parameters/skip_host_reset

The /etc/modprobe.d directory contains .conf configuration files specify module options, create module aliases, and override the usual behavior of modprobe for modules with special requirements. The /etc/modprobe.conf file that was used with earlier versions of modprobe is also valid if it exists. Entries in the /etc/modprobe.conf and /etc/modprobe.d/*.conf files use the same syntax.

The following are commonly used commands in modprobe configuration files:

alias

Creates an alternate name for a module. The alias can include shell wildcards. For example, create an alias for the sd-mod module:

alias block-major-8-* sd_mod

As a result, a command such as modprobe block-major-8-0 has the same effect as modprobe sd_mod.

blacklist

Ignore a module's internal alias that is displayed by the modinfo command. This command is typically used if the associated hardware is not required, if two or more modules both support the same devices, or if a module invalidly claims to support a device. For example, to blocklist the alias for the frame-buffer driver cirrusfb:

blacklist cirrusfb

The /etc/modprobe.d/blacklist.conf file prevents hotplug scripts from loading a module, usually so that a different driver binds the module instead, regardless of which driver happens to be probed first.

install

Runs a shell command instead of loading a module into the kernel. For example, load the module snd-emu10k1-synth instead of snd-emu10k1:

install snd-emu10k1 /sbin/modprobe --ignore-install snd-emu10k1 && \
/sbin/modprobe snd-emu10k1-synth
options

Defines options for a module,. For example, define the nohwcrypt and qos options for the b43 module:

options b43 nohwcrypt=1 qos=0
remove

Runs a shell command instead of unloading a module. For example, unmount /proc/fs/nfsd before unloading the nfsd module:

remove nfsd { /bin/umount /proc/fs/nfsd > /dev/null 2>&1 || :; } ; \
/sbin/modprobe -r --first-time --ignore-remove nfsd

For more information, see the modprobe.conf(5) manual page.

Specifying Modules To Be Loaded at Boot Time

The system loads most modules automatically at boot time. If necessary, you can specify an additional module that should be loaded.

To specify a module to be loaded at boot time:

  1. Create a file in the /etc/sysconfig/modules directory. The file name must have the extension .modules, for example foo.modules.

  2. Edit the file to create the script that loads the module.

    The script to load a module can be a simple modprobe call, for example:

    #!/bin/sh
    modprobe foo

    or more complex to include error handling:

    #!/bin/sh
    if [ ! -c /dev/foo ] ; then
      exec /sbin/modprobe foo > /dev/null 2>&1
    fi
  3. Use the following command to make the script executable:

    sudo chmod 755 /etc/sysconfig/modules/foo.modules

About Weak Update Modules

External modules, such as drivers installed using a driver update disk, are usually installed into /lib/modules/kernel-version/extra. Modules stored in this directory are given preference over matching modules included with the kernel, itself, when you attempt to load them. This means that external drivers and modules can be installed to override kernel modules where hardware issues may need resolution. For each subsequent kernel update, it is important that the external module is made available to each compatible kernel to avoid potential boot issues resulting from driver incompatibilities with the affected hardware.

Since the requirement to load the external module with each compatible kernel update is system critical, a mechanism is in place so that external modules can be loaded as weak update modules for compatible kernels. Weak update modules are made available by creating symbolic links to compatible modules in the /lib/modules/kernel-version/weak-updates directory. The package manager handles this process automatically when it detects driver modules installed in any /lib/modules/kernel-version/extra directories for compatible kernels. For example, installation of the kmod-megaraid_sas-uek driver update package on the Driver Update Disk (DUD) for the Oracle Linux 7.4 might install the following:

/lib/modules/4.1.12-61.1.18.el7uek.x86_64/extra/megaraid_sas
/lib/modules/4.1.12-61.1.18.el7uek.x86_64/extra/megaraid_sas/megaraid_sas.ko

The new driver module is installed into the extra directory for the 4.1.12-61.1.18.el7uek.x86_64, which was the kernel version that was originally used to build the module.

A subsequent kernel update means that the system is now running the 4.1.12-112.14.13.el7uek.x86_64 version of the kernel. This kernel is compatible with the module installed for the previous kernel, so the external module is automatically added, as a symbolic link, in the weak-updates directory as part of the installation process:

ls -l /lib/modules/4.1.12-112.14.13.el7uek.x86_64/weak-updates/megaraid_sas/*.ko
lrwxrwxrwx. 1 root root 76 Jan 30 04:52 /lib/modules/4.1.12-112.14.13.el7uek.x86_64\
    /weak-updates/megaraid_sas/megaraid_sas.ko \
     -> /lib/modules/4.1.12-61.1.18.el7uek.x86_64/extra/megaraid_sas/megaraid_sas.ko

The output means that the external module is loaded for subsequent kernel updates.

In most cases, weak updates make sense and ensure that no extra work must be done to carry an external module through subsequent kernel updates. This prevents possible driver related boot issues after kernel upgrades and maintains the predictable running of a system and its hardware.

In some cases you may wish to remove weak update modules for a newer kernel. For instance, if an issue has been resolved for a driver that is shipped in the newer kernel and you would prefer to use this driver over the external module that you installed as part of a driver update.

You can remove weak update modules by removing the symbolic links for each kernel, manually. For example:

sudo rm -rf /lib/modules/4.1.12-112.14.13.el7uek.x86_64/weak-updates/megaraid_sas/

For more information about external driver modules and driver update disks, see Oracle Linux 7: Installation Guide.