lsmod仅显示模块加载状态，无法确认是否正常工作；modinfo只读取磁盘文件元数据；二者必须配合使用：lsmod查运行态，modinfo查兼容性与参数。
lsmod 只能告诉你“哪些模块正在运行”，但无法确认模块是否真被系统使用或能否正常工作；modinfo 则完全不关心加载状态，它只查磁盘上模块文件的元数据。两者必须配合用，缺一不可。
lsmod 输出里 Used by 为 0 是什么情况
这表示该模块当前没有被其他模块或内核子系统引用，但模块本身仍驻留在内存中。常见于：
- 模块刚被
modprobe加载，但还没触发实际设备匹配（比如 USB 设备未插入） - 驱动已加载，但对应硬件被热拔出或电源关闭（如
usb_storage在 U 盘拔掉后仍显示，Used by变为 0） - 某些模块设计为“常驻监听”，例如
kvm_intel，即使没运行虚拟机也保持加载，Used by可能长期为 0 - 注意：
Used by 0不代表模块可安全卸载——rmmod仍可能报Module is in use，因为内核可能内部持有引用（如通过try_module_get()）
modinfo 查不到模块名？先确认模块是否存在
modinfo 报 ERROR: Module <name> not found</name>，通常不是命令写错，而是模块根本没安装到当前内核版本路径下。检查步骤：
- 运行
uname -r确认当前内核版本，比如输出6.8.0-45-generic - 检查模块文件是否存在：
ls /lib/modules/$(uname -r)/kernel/drivers/net/wireless/rtw88/rtw88_8822bu.ko* - 若文件是
.ko.xz压缩格式，modinfo默认支持，无需解压；但某些旧版工具链可能不识别，可临时解压验证：xz -d rtw88_8822bu.ko.xz - 模块名不等于文件名：比如
ath9k.ko对应模块名是ath9k，但ath9k_common.ko是依赖模块，不能直接用modinfo ath9k_common加载，需靠modprobe ath9k自动拉起
grep 过滤 lsmod 时为什么漏掉模块
直接 lsmod | grep nvidia 可能找不到，因为模块名未必含关键词。典型陷阱：
- nvidia 驱动主模块名是
nvidia，但配套模块叫nvidia_uvm、nvidia_drm、nvidia_modeset—— 单靠grep nvidia会漏掉后三者 - 某些模块别名隐藏真实名：比如
btusb模块在/etc/modprobe.d/里被 alias 成bluetooth，lsmod | grep bluetooth就什么都看不到 - 大小写敏感：
LSMOD不是命令，lsmod | grep NVME匹配不到全小写的nvme - 更稳妥方式：
lsmod | awk '{print $1}' | grep -i 'nvidia\|nvme\|bt'，用awk提取第一列再过滤
modinfo -p 显示的参数，为什么 modprobe 加了却没生效
modinfo -p 列出的是模块编译时声明的可配置参数，但加载时是否真正应用，取决于三个条件：
- 参数必须在
modprobe命令中显式传入，如：sudo modprobe r8169 disable_msi=1 - 若模块已加载，
modprobe默认不会重载——得先rmmod r8169再重新modprobe（或加-r卸载后自动重装） - 某些参数需在模块加载前通过内核启动参数设置，例如
i915.enable_psr=0必须加在 GRUB 的linux行里，运行时用modprobe传无效 - 验证是否生效：加载后执行
sudo cat /sys/module/r8169/parameters/disable_msi，输出Y或1才算成功
真正麻烦的不是命令记不住，而是模块状态、文件存在性、参数作用时机这三层信息不在同一个地方维护——/proc/modules、/lib/modules/$(uname -r)、/sys/module/ 各管一段，稍不注意就查偏了。
