lsmod仅显示模块已加载，不能确认驱动是否绑定设备、参数生效或签名合规；需结合modinfo -p/-n/-f sig_id查参数路径签名，再用lspci/ethtool/dmesg验证设备绑定与初始化。
lsmod 能列出已加载模块，但“具体”和“详细”两个词意味着你不能只看它——它只告诉你“代码进了内核”，不告诉你驱动是否真在管设备、参数有没有生效、签名合不合格。
怎么用 lsmod 看模块名和基础状态
直接运行 lsmod 即可，它读的是 /proc/modules，实时、无需 root。但注意三列的真实含义：
-
Module列是模块名，不是驱动名：比如nvme模块可能对应设备nvm0n1；igb模块加载后不会显示为igb.ko，而是igb -
Size是内存字节数，数值极小（如 12676）往往说明只是封装层，核心逻辑在别的模块里 -
Used by为 0 不代表能安全卸载——nf_conntrack常被 netfilter 框架隐式持有，rmmod会失败，dmesg | tail才会报错 - 模块名大小写敏感，且
insmod ./hello.ko加载后若没定义MODULE_ALIAS，lsmod里根本不会出现hello
为什么 lsmod | grep nvme 可能漏掉关键模块
常见驱动模块名有变体，比如 NVMe 相关模块实际可能是 nvme_core、nvme、nvme_pci，只 grep nvme 会漏掉前两者。更稳妥的做法是：
lsmod | awk '{print $1}' | grep -E '^(nvme|nvidia|usb|igb)$'- 或直接查 PCI 设备绑定：
lspci -k -s 0000:01:00.0 | grep "Kernel driver"，这才是“驱动真在用”的证据 - 网卡类驱动还要补
ethtool -i eth0，如果driver字段为空或unknown，说明 probe 失败了，dmesg | grep -i igb通常会输出probe failed
怎么确认模块文件路径、参数和签名是否合规
modinfo 不是看作者和描述的，重点用这三个参数：
-
modinfo -p <code>模块名：列出所有可调参数，比如modinfo -p igb显示InterruptThrottleRate，这是调优网卡中断的关键入口 -
modinfo -n <code>模块名：返回模块文件路径，检查是否来自当前内核版本，避免/lib/modules/5.15.0-101-generic/下混入旧版.ko -
modinfo -F sig_id <code>模块名：若输出为空，且内核启用了CONFIG_MODULE_SIG_FORCE=y，该模块根本无法加载 - 另有个隐藏线索：
modinfo输出里的srcversion字段，相同源码编译出的模块该值一致，可用于排查“我编译的 ko 为何加载失败而系统自带的可以”
闭环验证：从加载到设备可用的四步交叉印证
仅靠 lsmod 和 modinfo 还不够，必须组合验证才能确认驱动真正可用：
- 第一步：用
lsmod | grep <code>模块名确认模块已加载 - 第二步：用
lspci -k -s <code>PCI地址或lsusb -t确认设备是否绑定到该驱动（Kernel driver in use:后非none） - 第三步：用
ethtool -i <code>接口名或nvme list等用户态工具，确认设备功能层面已就绪 - 第四步：用
dmesg | grep -i <code>模块名查 probe 日志，有registered或probed才算走完初始化流程
最容易被忽略的是 probe 阶段：模块加载成功 ≠ 设备初始化成功。很多问题卡在 request_irq 失败、PCI 配置空间读取超时、或 firmware 缺失，这些都不会反映在 lsmod 里，只能靠 dmesg 和硬件工具交叉定位。
