lsmod是唯一能实时反映内核中已加载模块的命令，它读取/proc/modules，输出模块名、大小（字节）和used by（引用计数及依赖模块），但used by为0不表示模块空闲，模块名不含.ko后缀且严格区分大小写，过滤需用awk+grep正则避免遗漏。
直接用 lsmod 查当前已加载的模块
lsmod 是唯一能告诉你“此刻哪些模块真正在内核里跑着”的命令。它读的是 /proc/modules，不是磁盘上的文件列表，所以结果反映的是真实运行状态。
- 执行
lsmod就能看到三列：模块名、字节数大小、Used by（引用计数 + 依赖模块名） -
Used by列数字为 0 ≠ 模块空闲——比如nvidia正在渲染画面时，Used by可能是 0，但rmmod nvidia仍会失败，报错Module nvidia is in use - 模块名不带
.ko后缀，也不含路径；insmod ./hello.ko加载后，在lsmod输出里只显示hello，除非模块代码里写了MODULE_ALIAS
lsmod | grep 过滤时总找不到？注意模块名变体和大小写
直接 lsmod | grep nvme 可能漏掉 nvme_core 或 nvme_pci，因为驱动常拆成多个关联模块。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 稳妥做法是：
lsmod | awk '{print $1}' | grep -E '^(nvme|nvidia|usb|vfio)'—— 先取第一列模块名，再用正则匹配常见前缀 - 模块名严格区分大小写：
NVIDIA和nvidia是两个东西，实际加载名永远小写 - 闭源模块（如
nvidia）若被标记为 tainted，lsmod默认不显示T标志，得看/proc/modules原始行末尾才有
确认模块是否“可用”而非“已加载”，用 modprobe -l
lsmod 只管内存里的，而 modprobe -l 列的是磁盘上所有预编译好的 .ko 文件路径，适合查“系统有这个模块但没加载”的情况。
-
modprobe -l | grep ^/lib/modules/$(uname -r)/kernel/drivers/net/ | head -5可快速定位网卡驱动位置 - 输出路径含压缩后缀（如
.ko.xz）说明模块被压缩存储，modprobe加载时自动解压，insmod不能直接处理这类文件 - 如果
modprobe -l | grep xxx无输出，但你知道模块应该存在，大概率是depmod -a没跑过，或/lib/modules/$(uname -r)下根本没对应目录
模块加载失败？别只盯 lsmod，要配合 dmesg | tail 和 modinfo
lsmod 空了不代表没试过加载——失败的模块根本不会出现在里面。这时候得看内核日志和模块元数据。
-
dmesg | tail -20通常包含最近加载失败的提示，例如Unknown symbol in module表示依赖缺失，Operation not permitted往往是模块签名验证失败（CONFIG_MODULE_SIG_FORCE开启） -
modinfo xxx能确认模块是否存在、路径对不对、有没有depends:字段——比如modinfo veth显示依赖cfg80211，那得先确保后者已加载 -
modprobe --showconfig | grep -A5 xxx查该模块是否被blacklist或install指令覆盖，这是“明明有模块却死活不加载”的高频原因
lsmod 输出里——它可能根本没被调用，可能加载失败被内核拒之门外，也可能被配置规则静默拦截。盯着 lsmod 本身，永远只能看到冰山浮出水面的那一角。
