lsmod是最直接查看已加载内核模块的方式，输出三列：module为模块名（如nvidia）、size为字节数、used by为引用计数及依赖模块列表；但仅表示代码载入内核，不证明设备绑定或参数生效。
lsmod 是最直接、最可靠的方式，但它只告诉你“模块代码进了内核”，不等于驱动在用、设备已绑定、参数已生效。
lsmod 输出怎么看：Module、Size、Used by 三列的真实含义
Module 列是模块名，不是驱动名或文件名（nvme.ko 加载后显示为 nvme，igb.ko 显示为 igb）；
Size 是模块占用的内存字节数，数值异常小（如 12676）可能只是封装层，真实逻辑在其他模块里；
Used by 是引用计数 + 依赖模块列表，数字为 0 不代表模块空闲——kvm_intel 常年 Used by 0 却无法 rmmod，因为内核子系统隐式持有它；
若某模块出现在多行 Used by 中（如 nf_nat 同时被 xt_nat 和 nf_nat_masquerade_ipv4 引用），说明它是共享基础模块，强行卸载大概率 panic。
为什么 lsmod | grep xxx 总是查不到？常见漏查原因
模块名大小写敏感，且不含路径和扩展名：hello.ko 加载后只显示为 hello；
一个驱动常拆成多个模块：nvidia、nvidia_modeset、nvidia_uvm，只搜主名会漏依赖项；
模块名可能带下划线变体：nvme 驱动实际加载后常显示为 nvme_core、nvme_pci，直接 lsmod | grep nvme 会漏掉；
更稳妥的写法是先提取第一列再过滤：lsmod | awk '{print }' | grep -i -E '^(nvme|nvidia|kvm)'；
如果模块没定义 MODULE_ALIAS，用 insmod ./xxx.ko 加载后也不会出现在 lsmod 名称列中。
lsmod 只是起点，真正闭环要补哪几手？
查模块是否真绑定硬件：
PCI 设备用 lspci -k -s $(lspci | grep -i nvidia | cut -d' ' -f1) 看 Kernel driver in use: 字段；
网卡用 ethtool -i eth0 看 driver 是否非空；
查模块参数是否生效：modinfo -p nvidia | grep NVreg_EnableGpuFirmware，再对比 cat /sys/module/nvidia/parameters/NVreg_EnableGpuFirmware；
查签名是否合规：modinfo -F sig_id nvidia，若输出为空且内核启用了 CONFIG_MODULE_SIG_FORCE=y，该模块根本不会加载；
查模块文件路径是否匹配当前内核：modinfo -n nvidia 应指向 /lib/modules/$(uname -r)/ 下对应路径，混入旧版 .ko 会导致 probe 失败。
模块没出现在 lsmod？先排除这三件事
模块根本没加载：运行 sudo modprobe nvidia 再查，别只等开机自动加载；
模块被黑名单：执行 modprobe --showconfig | grep -A5 'blacklist nvidia'，或检查 /etc/modprobe.d/*.conf 里有无 blacklist nvidia 或 install nvidia /bin/false；
模块签名不匹配：内核启用强制签名时，未签名模块会被静默拒绝，dmesg | grep -i "signature" 会报 module verification failed，此时 lsmod 当然看不到它。
真正容易被忽略的是：模块加载成功只是第一步。lsmod 只告诉你“代码进了内核”，不保证“设备连上了、probe 完了、netdev 注册了、参数生效了”。每一步都可能断在中间，得靠 dmesg + ethtool + lspci -k 交叉印证。
