Linux kernel functionalities, such as the support for specific devices or filesystems, are organized in modules, which can be built statically into the kernel or as separated “units” which can be loaded and unloaded on request. Nowadays needed modules are automatically loaded, so we seldom need to explicit manage them. In certain situations, however, we may need to perform such actions.
In this tutorial we learn how to retrieve information about kernel modules, how to use the modprobe utility to load or unload modules at runtime, and how to load or blacklist modules at boot.
In this tutorial you will learn:
- How to list loaded kernel modules
- How to get information about a kernel module
- How to load and unload kernel modules with modprobe
- How to automatically load a module at boot or blacklist it
| Category | Requirements, Conventions or Software Version Used |
|---|---|
| System | Distribution-agnostic |
| Software | lsmod, modinfo, modprobe |
| Other | Administrative privileges to load or unload modules. |
| Conventions | # – requires given linux-commands to be executed with root privileges either directly as a root user or by use of sudo command $ – requires given linux-commands to be executed as a regular non-privileged user |
Listing loaded modules
To retrieve the list of the loaded kernel modules, all we have to do is to inspect the content of the /proc/modules file. Below you can see an example of what an entry in the file looks like:
i915 3174400 42 - Live 0x0000000000000000
As you can see, the content of the file is organized in six columns. The first column contains the name of the module (“i915” in this case: it is the module which adds support for Intel integrated graphics); in the second one the memory size of the module is reported in bytes (3174400). The third column contains the number of the currently loaded module instances, which, in this case are 42.
Some modules, to work correctly rely on functionalities provided by other modules: the fourth column is used to report the modules dependencies. In the entry we took as an example we can see the module has no dependencies: all we can see in the column is the “-” character. The fifth column reports the current state of the module, which can be one among: Live, Loading or Unloading.
Finally, in the sixth column, we can see the memory address where the module is loaded.
To avoid reading the content of the /proc/modules file directly, we can use the lsmod utility, which provides a more readable and nicely formatted output, which includes a header:
Module Size Used by i915 3174400 42
Retrieving information about a module
To get information about a specific Linux kernel module, we can use another utility: modinfo. This utility provides information about the module passed as its argument. We can reference a module by using its path or just its name; when we do the latter, the module is searched for in the /lib/modules/<kernel-version> directory, where “<kernel-version>” is a directory named after the Linux kernel version currently in use, which can be obtained by running:
$ uname -r
To get information about the “i915” module, we would run:
$ modinfo i915
Among the other things, in the output of the command, we can see the module filename, its author, license and dependencies. We can also see the list of parameters which can be passed to the module in order to adjust its behavior, and a brief explanation of them:
parm: modeset:Use kernel modesetting [KMS] (0=disable, 1=on, -1=force vga console preference [default]) (int) parm: enable_dc:Enable power-saving display C-states. (-1=auto [default]; 0=disable; 1=up to DC5; 2=up to DC6; 3=up to DC5 with DC3CO; 4=up to DC6 with DC3CO) (int) parm: enable_fbc:Enable frame buffer compression for power savings (default: -1 (use per-chip default)) (int) parm: lvds_channel_mode:Specify LVDS channel mode (0=probe BIOS [default], 1=single-channel, 2=dual-channel) (int) parm: panel_use_ssc:Use Spread Spectrum Clock with panels [LVDS/eDP] (default: auto from VBT) (int) parm: vbt_sdvo_panel_type:Override/Ignore selection of SDVO panel mode in the VBT (-2=ignore, -1=auto [default], index in VBT BIOS table) (int) parm: reset:Attempt GPU resets (0=disabled, 1=full gpu reset, 2=engine reset [default]) (uint) parm: vbt_firmware:Load VBT from specified file under /lib/firmware (charp) parm: error_capture:Record the GPU state following a hang. This information in /sys/class/drm/card<N>/error is vital for triaging and debugging hangs. (bool) parm: enable_hangcheck:Periodically check GPU activity for detecting hangs. WARNING: Disabling this can cause system wide hangs. (default: true) (bool) parm: enable_psr:Enable PSR (0=disabled, 1=enable up to PSR1, 2=enable up to PSR2) Default: -1 (use per-chip default) (int) parm: psr_safest_params:Replace PSR VBT parameters by the safest and not optimal ones. This is helpful to detect if PSR issues are related to bad values set in VBT. (0=use VBT p arameters, 1=use safest parameters) (bool) parm: enable_psr2_sel_fetch:Enable PSR2 selective fetch (0=disabled, 1=enabled) Default: 0 (bool) parm: force_probe:Force probe the driver for specified devices. See CONFIG_DRM_I915_FORCE_PROBE for details. (charp) parm: disable_power_well:Disable display power wells when possible (-1=auto [default], 0=power wells always on, 1=power wells disabled when possible) (int) parm: enable_ips:Enable IPS (default: true) (int) parm: fastboot:Try to skip unnecessary mode sets at boot time (0=disabled, 1=enabled) Default: -1 (use per-chip default) (int) parm: load_detect_test:Force-enable the VGA load detect code for testing (default:false). For developers only. (bool) parm: force_reset_modeset_test:Force a modeset during gpu reset for testing (default:false). For developers only. (bool) parm: invert_brightness:Invert backlight brightness (-1 force normal, 0 machine defaults, 1 force inversion), please report PCI device ID, subsystem vendor and subsystem device I D to dri-devel@lists.freedesktop.org, if your machine needs it. It will then be included in an upcoming module version. (int) parm: disable_display:Disable display (default: false) (bool) parm: memtest:Perform a read/write test of all device memory on module load (default: off) (bool) parm: mmio_debug:Enable the MMIO debug code for the first N failures (default: off). This may negatively affect performance. (int) parm: verbose_state_checks:Enable verbose logs (ie. WARN_ON()) in case of unexpected hw state conditions. (bool) parm: nuclear_pageflip:Force enable atomic functionality on platforms that don't have full support yet. (bool) parm: edp_vswing:Ignore/Override vswing pre-emph table selection from VBT (0=use value from vbt [default], 1=low power swing(200mV),2=default swing(400mV)) (int) parm: enable_guc:Enable GuC load for GuC submission and/or HuC load. Required functionality can be selected using bitmask values. (-1=auto [default], 0=disable, 1=GuC submission, 2=HuC load) (int) parm: guc_log_level:GuC firmware logging level. Requires GuC to be loaded. (-1=auto [default], 0=disable, 1..4=enable with verbosity min..max) (int) parm: guc_firmware_path:GuC firmware path to use instead of the default one (charp) parm: huc_firmware_path:HuC firmware path to use instead of the default one (charp) parm: dmc_firmware_path:DMC firmware path to use instead of the default one (charp) parm: enable_dp_mst:Enable multi-stream transport (MST) for new DisplayPort sinks. (default: true) (bool) parm: enable_dpcd_backlight:Enable support for DPCD backlight control(-1=use per-VBT LFP backlight type setting [default], 0=disabled, 1=enable, 2=force VESA interface, 3=force I ntel interface) (int) parm: enable_gvt:Enable support for Intel GVT-g graphics virtualization host support(default:false) (bool) parm: request_timeout_ms:Default request/fence/batch buffer expiration timeout. (uint) parm: lmem_size:Set the lmem size(in MiB) for each region. (default: 0, all memory) (uint) parm: lmem_bar_size:Set the lmem bar size(in MiB). (uint) parm: mitigations:Selectively enable security mitigations for all Intel® GPUs in the system.
How parameters can be passed to a module? Let’s find out!
Loading and unloading modules with modprobe
To load or unload Linux kernel modules we can use the modprobe utility. Modprobe is intelligent enough to resolve module dependencies, so that when we load a module, its dependencies are also loaded. The command takes the name of the module we want to operate on as first argument. When loading a module, we can also specify the comma-separated list of parameters it should be loaded with.
Loading a module
Supposing we wanted to load the i915 module, explicitly enabling verbose state checks. We would run:
$ sudo modprobe i915 verbose_state_checks=1
To apply new parameters to a module, we should either unload it first, if possible, or change the value of the module as exposed in /sys/module/<module-name>/parameters/<parameter-name>. For instance, to check the current value of the “verbose_state_checks” parameter of the i915 module we could just check the content of the corresponding file:
$ sudo cat /sys/module/i915/parameters/verbose_state_checks Y
In this case, the feature is enabled. Supposing we want to disable it without unloading the module, we could simply write the new value to the file:
$ echo 0 | sudo tee /sys/module/i915/parameters/verbose_state_checks
Notice that not all parameters can be changed like we did above. If a parameter cannot be changed, the corresponding file will have no writing permissions.
Unloading a module
To unload one or more modules we still use modprobe, but we run it with the -r option. If we try to unload a module which is currently in use, we receive an error:
$ sudo modprobe -r i915 modprobe: FATAL: Module i915 is in use.
As we already said, modprobe is dependecies-aware, so when a module is unloaded, it tries to unload all the modules it depends on, if they are not in use.
Loading or blacklisting a module at boot
Loading a module with modprobe like we did in the previous example, does not make the module automatically be loaded the next time we start the system. To make a module be loaded at boot, we have either to append its name to the /etc/modules file (creating it if it doesn’t exist), or to a file with the “.conf” extension, under the /etc/modules-load.d/ directory. In order for an hypothetical module “foo” to be loaded at boot, for example, we would write “foo” in the /etc/modules-load.d/foo.conf file:
$ echo "foo" | sudo tee /etc/modules-load.d/foo.conf
If we want to specify the options a module should be loaded with at boot, or prevent a module to be loaded, instead, we should create a file with the “.conf” extension under the
/etc/modprobe.d directory. For the i915 module to be loaded without verbose state checks, for example, we would create the /etc/modprobe.d/i915.conf file, with the following content:
options i915 verbose_state_checks=0
To blacklist the module, instead, we would use the “blacklist” instruction:
blacklist i915
Conclusions
Linux functionalities are organized in modules, which can be statically built into the kernel or loaded and unloaded when needed. In this tutorial we saw how to list loaded modules, get information about them and how to load or unload modules at runtime with the modprobe utility. We also saw how to automatically load a module at boot, with or without specific options, and how to prevent one to be loaded, by blacklisting it.
