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 不是看作者和描述的，关键就这三项：

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• modinfo -p <code>igb：列出所有可调参数，比如 InterruptThrottleRate，这是网卡中断调优的入口，不查这个你连能不能改都搞不清
• modinfo -n <code>igb：返回路径，如 /lib/modules/5.15.0-101-generic/kernel/drivers/net/ethernet/intel/igb/igb.ko，若路径指向旧内核目录（比如 5.4.0），说明模块版本错配，加载可能失败
• modinfo -F sig_id <code>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 <code>ens33 看网卡接口：输出中 driver: 字段必须是非空且匹配预期（如 igb），若为 unknown 或空白，说明 probe() 没走完，netdev 没注册，lsmod 再多也没用
• USB 设备用 lsusb -t：看树状结构里某设备节点下挂的是不是你的驱动名，比如 driver=usb-storage

最容易被忽略的一点：模块加载成功只是第一步。lsmod 只管代码进没进内核，不管硬件连没连上、probe 成没成功、netdev 注册没注册、参数生效没生效。每一步都可能断掉，必须用 dmesg + lspci -k + ethtool -i 交叉验证，缺一不可。