lsmod仅确认驱动代码是否加载进内核，不能证明设备已绑定或功能启用；必须结合lspci -k、ethtool -i、dmesg等命令交叉验证probe状态、硬件绑定及参数生效情况。

lsmod 是唯一能直接告诉你“驱动代码是否已进入内核”的命令——它读的是 /proc/modules，实时、可靠、不需要 root 权限。但仅靠它判断“驱动在用”，90% 的情况下会误判。

为什么 lsmod | grep nvme 有输出，lspci -k 却显示 Kernel driver in use: none

模块加载 ≠ 设备绑定。常见断点有三个：

• 设备被 vfio-pci 或 pci-stub 抢占：检查 lspci -k -s 0000:01:00.0 中的 Kernel modules: 字段，若列出 vfio_pci，说明该设备根本没交给 nvme 模块管理
• 驱动 probe 失败：运行 dmesg | grep -i nvme，出现 probe failed 或 Unknown symbol in module 表示依赖缺失或硬件不匹配
• 模块名大小写敏感且不含扩展名：你编译的 my_nvme.ko 加载后在 lsmod 里只显示为 my_nvme，lsmod | grep MY_NVME 必然为空

modinfo 必须查的三个参数：-p、-n、-F sig_id

modinfo 不是看作者和描述的，关键就这三项：

• modinfo -p igb：列出所有可调参数，比如 InterruptThrottleRate，这是网卡中断调优的入口，不查这个你连能不能改都搞不清
• modinfo -n igb：返回路径，如 /lib/modules/5.15.0-101-generic/kernel/drivers/net/ethernet/intel/igb/igb.ko，若路径指向旧内核目录（比如 5.4.0），说明模块版本错配，加载可能失败
• modinfo -F sig_id igb：检查签名 ID，若输出为空且系统启用了 CONFIG_MODULE_SIG_FORCE=y（查 zcat /proc/config.gz | grep MODULE_SIG_FORCE），那这个模块压根不会被加载

确认“真正在用”的唯一闭环：lspci -k 或 ethtool -i

只有这两条命令能告诉你设备是否真正绑定了驱动：

• lspci -k 看 PCI 设备：找到对应设备行，检查 Kernel driver in use: 后面是不是你要的模块名；再看 Kernel modules: 是否包含它——前者表示已绑定，后者表示可绑定
• ethtool -i ens33 看网卡接口：输出中 driver: 字段必须是非空且匹配预期（如 igb），若为 unknown 或空白，说明 probe() 没走完，netdev 没注册，lsmod 再多也没用
• USB 设备用 lsusb -t：看树状结构里某设备节点下挂的是不是你的驱动名，比如 driver=usb-storage

这里有个常被忽视的关键点：模块加载成功，仅仅只是万&里长征的第一步。lsmod 的职责仅限于确认代码是否进入内核，它无法替你确认硬件连接状态、probe 函数是否执行完毕、netdev 是否完成注册，或是参数是否真正生效。这条链路中的任何一个环节断裂，都会导致功能失效。因此，必须通过 dmesg、lspci -k 与 ethtool -i 进行交叉验证，三者缺一不可。