Loading...

VONDS ©

Lab 1: RAID Controller Module Identification

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.

What You’ll Practice

  • PCI device identification and targeted inspection using lspci .
  • Driver/module binding concepts: “kernel driver in use” vs “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/module work is premature; you likely have a seating/firmware/slot issue or a passthrough mapping problem. 

# 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 asks for the kernel driver/module binding information. This gives direct “what driver is in use” evidence without guessing module names. 

Kernel driver in use: megaraid_sas
Kernel modules: megaraid_sas
Step 3 : Cross-check kernel state in sysfs.
Command 
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 currently present from the kernel’s perspective. This is how you avoid “tool says it’s there” when the kernel disagrees. 

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

lsmod tells you whether the module is loaded and its usage count. modinfo tells you what the module is (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 init.
Command 
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’s useful for spotting related dependencies and confirming you’re 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). Immediately re-adding it tests that the system can cleanly reinitialize the driver. In production, this can recover from a bad init state, but it must be treated as a controlled operation. 

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

Reference

  • lspci : Lists PCI devices recognized by the kernel.
  • 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 ).
  • /sys : sysfs virtual filesystem exposing live kernel object state.
  • lsmod : Lists currently loaded kernel modules.
  • modinfo <module> : Displays metadata about a kernel module.
  • dmesg : Displays kernel ring buffer messages.
  • journalctl -k : Queries kernel logs via systemd.
    • -k : Limits output to kernel messages.
  • modprobe -r <module> : Loads or unloads kernel modules with dependency resolution.
    • -r <module> : Safely unloads a module.