Follow a device from hardware to driver

short · 25 min · Objective 1.2

Task

Take one piece of hardware and trace it the whole way: what the bus reports, which module claims it, what that module depends on, and what the firmware tables say about the machine it sits in. Then load and unload a module and see why removal is sometimes refused.

Steps

  1. List PCI devices with their bound drivers: lspci -k. Pick the network controller and note the "Kernel driver in use" line.
  2. Look at that module in detail with modinfo <driver>: its description, its parameters and its dependencies.
  3. Find it in lsmod and read the third and fourth columns -- the use count and the list of modules using it.
  4. Find a module in lsmod whose third column is above 0 and whose fourth names the modules using it, try rmmod on it, and read the refusal ("Module ... is in use by ..."). Explain which column predicted that. Do NOT try this on your network driver: a virtual NIC's driver usually shows a use count of 0, so rmmod succeeds and takes the interface down -- over SSH, that is your session gone. A driver built into the kernel refuses differently: "Module ... is builtin".
  5. Load a harmless module you are not using -- modprobe dummy creates a dummy network interface. Confirm with ip link that dummy0 appeared, then modprobe -r dummy and confirm it is gone.
  6. Read the firmware tables the kernel does not otherwise expose: dmidecode -t system and dmidecode -t memory | grep -E 'Size|Locator'. Answer whether this machine has a free memory slot.
  7. Read this boot's hardware messages with dmesg -T | head -40 and note the timestamps are now readable.

Verify

lspci -k | grep -A3 -i ethernet | grep -i 'driver in use'
lsmod | awk 'NR==1 || $3 > 0' | head
modprobe dummy && ip link show dummy0 >/dev/null && echo "loaded"
modprobe -r dummy && ! ip link show dummy0 2>/dev/null && echo "unloaded"
sudo dmidecode -t memory | grep -c 'Size: No Module Installed'

The last command counts empty memory slots, which is the practical answer to "can I add RAM without opening the case". If dmidecode is unavailable you are probably in a container -- run this part on a VM or host.

Notes

A device in lspci -k with no "Kernel driver in use" line has nothing bound to it, and that is the whole diagnosis. The causes are missing firmware, a blacklist, an out-of-tree driver not rebuilt after a kernel update, or Secure Boot refusing an unsigned module -- four different fixes, one symptom.

This is an independent study companion for CompTIA Linux+ and is not produced by or endorsed by CompTIA.