Follow a device from hardware to driver
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
- List PCI devices with their bound drivers:
lspci -k. Pick the network controller and note the "Kernel driver in use" line. - Look at that module in detail with
modinfo <driver>: its description, its parameters and its dependencies. - Find it in
lsmodand read the third and fourth columns -- the use count and the list of modules using it. - Try
rmmodon it and read the refusal. Explain which column predicted that. - Load a harmless module you are not using --
modprobe dummycreates a dummy network interface. Confirm withip linkthatdummy0appeared, thenmodprobe -r dummyand confirm it is gone. - Read the firmware tables the kernel does not otherwise expose:
dmidecode -t systemanddmidecode -t memory | grep -E 'Size|Locator'. Answer whether this machine has a free memory slot. - Read this boot's hardware messages with
dmesg -T | head -40and 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.