Loading...

VONDS ©

Lab 1: RAID Controller Module Identification

Back to Lab Index

Identify the kernel driver bound to a PCI RAID controller and validate the module’s load state using CLI-only inspection. Confirm evidence across PCI enumeration, sysfs, module metadata, and kernel logs, then prove control by reloading the module safely.

troubleshooting boot core

Scenario

A new RAID controller has been installed at PCI address 03:00.0 . You cannot open the chassis (warranty constraints), but you still need to confirm the correct driver is in use, verify the module is actually loaded, and gather log evidence to support troubleshooting.

Operator context

Perform this verification before escalating the issue to hardware support, replacing firmware, or assuming the kernel should detect the device automatically.

Objective

  • Confirm the RAID controller is visible on the PCI bus.
  • Identify the kernel driver bound to PCI device 03:00.0 .
  • Validate module presence via sysfs and module tooling.
  • Collect kernel log evidence for the module/device.
  • Verify control by safely reloading the module.

Concepts

  • PCI device identification and targeted inspection using lspci .
  • Driver/module binding: “kernel driver in use” versus “available kernel modules.”
  • sysfs as a source of truth for kernel object state ( /sys ).
  • Loaded module validation and metadata inspection ( lsmod , modinfo ).
  • Kernel log triage for device initialization ( dmesg , journalctl -k ).
  • Safe module reload procedure ( modprobe -r then modprobe ).

Walkthrough

Step 1 : Confirm the controller is visible on PCI.
Command 
lspci

lspci enumerates PCI devices and is your baseline proof that the OS sees the hardware. If the device is not listed, driver and module work is premature. At that point you are likely dealing with a seating, firmware, slot, or passthrough mapping issue. 

# Look for the target address and class:
# 03:00.0 RAID bus controller: ... MegaRAID ...
Step 2 : Identify the kernel driver bound to 03:00.0.
Command 
lspci -k -s 03:00.0

-s scopes to a single PCI address. -k prints kernel driver and module binding information. This gives direct evidence of the active driver without guessing module names. 

Kernel driver in use: megaraid_sas
Kernel modules: megaraid_sas
Step 3 : Cross-check kernel state in sysfs.
Commands 
ls /sys/bus/pci/drivers
# OR
ls /sys/module

sysfs ( /sys ) reflects live kernel objects. Listing /sys/bus/pci/drivers shows registered PCI drivers. Listing /sys/module shows modules present from the kernel’s perspective. This is how you avoid “a tool says it’s there” when the kernel disagrees. 

# You should see:
megaraid_sas
Step 4 : Validate load state and module metadata.
Commands 
lsmod | grep megaraid_sas
# OR
modinfo megaraid_sas

lsmod tells you whether the module is loaded and its usage count. modinfo describes the module (description, license, file path, version) and helps confirm you are running the expected driver build. 

# lsmod:
megaraid_sas

# modinfo (confirm key fields):
description:    LSI Logic MegaRAID SAS Driver
filename:       /lib/modules/.../megaraid_sas.ko...
Step 5 : Collect kernel log evidence for device initialization.
Commands 
dmesg | grep megaraid
# OR
journalctl -k | grep megaraid

Logs answer “what happened when the kernel initialized this device.” This is where you spot IRQ mapping issues, firmware readiness, timeouts, and fallback modes. journalctl -k is often better on systemd systems because it provides a consistent kernel log view. 

# Expected patterns:
megaraid_sas 0000:03:00.0: ...
FW now in Ready state
Step 6 : Confirm general module visibility.
Command 
lsmod

This is the broad “what’s loaded right now” view. It is useful for spotting related dependencies and confirming you are not debugging an empty runtime environment. 

# Confirm module appears in the list:
megaraid_sas
Step 7 : Reload the module to validate control and reset state.
Safety note

Reloading a storage driver can be disruptive. Do this only when you understand the blast radius (mounted filesystems, active I/O, RAID management tools, etc.).

Command 
sudo modprobe -r megaraid_sas && sudo modprobe megaraid_sas

modprobe -r removes the module (and may refuse if it is in use). Re-adding it tests that the system can cleanly reinitialize the driver. Treat this as a controlled operation. 

lspci -k -s 03:00.0
dmesg | grep megaraid

Common breakpoints

PCI device not present in lspci output

If 03:00.0 does not appear at all, driver troubleshooting is premature. Verify the slot, firmware, BIOS settings, or virtualization passthrough mapping first.

Kernel driver in use is blank

The device is present, but nothing is bound. Confirm the correct module exists, check Kernel modules output, then look for binding errors in dmesg or journalctl -k .

modprobe -r fails: “module is in use”

Storage modules often cannot be removed while the device is active. Stop related services, unmount filesystems, and ensure there is no active I/O before retrying.

No useful log evidence found

Filter may be too narrow. Try searching by PCI address ( 03:00.0 ) or by vendor strings from lspci . You can also inspect the full kernel log window around boot time with journalctl -k -b .

Cleanup checklist

This lab is read-only until the optional module reload. If you reloaded the module, your “cleanup” is verifying the device is still bound and logs show a clean reinit.

Commands 
lspci -k -s 03:00.0
lsmod | grep megaraid_sas
journalctl -k | grep megaraid
Success signal

lspci -k still shows a bound driver, and logs show a clean init with no repeated timeouts or probe failures.

Reference

  • lspci -k -s <addr> : Shows kernel driver and module binding for a specific PCI device.
    • -k : Displays the kernel driver currently bound to the device.
    • -s <addr> : Restricts output to a single PCI address (for example 03:00.0 ).
  • ls /sys/bus/pci/drivers : Shows registered PCI drivers.
    • /sys/bus/pci/drivers : Directory containing PCI driver entries.
  • ls /sys/module : Shows modules present from the kernel’s perspective.
    • /sys/module : Directory containing loaded module objects.
  • lsmod | grep <module> : Confirms whether a specific module is loaded.
    • | : Pipes output from the left command into the right command.
    • grep <module> : Filters lines matching the module name.
  • modinfo <module> : Displays metadata about a kernel module.
  • dmesg | grep <pattern> : Searches kernel messages for a pattern.
  • journalctl -k -b : Shows kernel logs for the current boot.
    • -k : Limits output to kernel messages.
    • -b : Restricts output to the current boot.
  • modprobe -r <module> : Unloads a kernel module (if not in use).
    • -r : Removes (unloads) the module.