Linux查看已安装驱动方法

本文深入解析了Linux系统中查看和诊断已安装驱动的完整方法论，指出仅依赖lsmod查看模块加载状态存在诸多误区——它只反映内核当前运行的模块，而非驱动是否真正安装或生效；需结合modinfo验证模块存在性、lspci -k或lsusb -t确认硬件绑定关系，并通过dmesg日志、黑名单检查、手动加载测试及固件/权限/内核参数等多维度排查“看似正常却功能异常”的疑难问题，帮助用户跳出“有模块=能用”的思维陷阱，掌握从驱动安装、加载、绑定到实际运行的全链路诊断能力。

怎么确认某个驱动模块是否已加载

直接查 lsmod 输出最可靠，它列出的是当前内核正在使用的模块，不是“安装了但没启用”的静态文件。很多新手误以为装了驱动包就等于模块已加载，其实只是把 .ko 文件放进了 /lib/modules/$(uname -r)/ 目录，还没进内核。

• 运行 lsmod | grep nvme（比如查 NVMe 驱动）——注意大小写敏感，nvm 或 NVME 都可能查不到
• 如果输出为空，不代表没装驱动，只说明没被加载；可配合 modinfo nvme 看模块是否存在且路径可读
• lsmod 不显示模块依赖关系的层级，想看谁依赖了谁，得加 --show-depends（仅部分发行版支持），更通用的做法是用 modinfo -F depends nvme

为什么 lsmod 里看不到自己刚安装的驱动

常见原因是没触发自动加载，或手动加载失败但没报错。Linux 不会因为存在 .ko 就自动加载模块，得靠硬件事件（如插 USB 设备）、配置文件（/etc/modules）、或用户显式执行 modprobe。

• 检查是否被黑名单：查看 /etc/modprobe.d/*.conf 中是否有 blacklist xxx 或 install xxx /bin/false
• 尝试手动加载：sudo modprobe r8169（以 Realtek 网卡为例），失败时立刻看 dmesg | tail -20，里面常有关键错误，比如 Unknown symbol in module 表示依赖模块缺失
• 某些驱动（如 nvidia）需要匹配精确的内核版本，升级内核后旧驱动不会自动重建，得重装 nvidia-kernel-dkms 类包

lsmod 输出字段怎么看：Size、Used by 是啥意思

三列分别是模块名、内存占用（字节）、被引用次数。这个“Used by”不是进程列表，而是其他内核模块或内核子系统对它的直接引用计数。值为 0 并不意味着模块空闲，可能是被内核核心逻辑持有（比如 ext4 被 VFS 层调用，但不体现在该字段）。

• Size 偏大（如超 500KB）不一定异常，图形或网络驱动本身就大；但若比同类驱动大一个数量级，可能是调试符号未剥离（strip --strip-unneeded 可减小）
• Used by 显示 - 表示无其他模块引用，但设备可能仍在使用（例如 USB 摄像头模块 uvcvideo 在 Used by 为 0 时仍能正常出图）
• 模块名带下划线（如 mt7921e）是合法的，但 shell 里用 modprobe mt7921e 时不能写成 mt7921-e，否则报 Module mt7921-e not found

想查驱动对应哪个硬件设备，光看 lsmod 不够

lsmod 只告诉你模块在跑，不告诉你它管哪块硬件。必须结合 lspci -k（PCI 设备）或 lsusb -t（USB 设备）交叉验证。

• lspci -k | grep -A 3 -B 1 "Network controller" 会显示设备 ID 和 Kernel driver in use 字段，这才是真实绑定关系
• 如果 lspci -k 显示 Kernel driver in use: snd_hda_intel，但 lsmod | grep hda 没输出，说明模块被卸载了，设备实际不可用
• 某些驱动（如 vfio-pci）会主动从原驱动“抢走”设备，此时 lspci -k 的 driver 字段会变，但原模块（如 igb）仍留在 lsmod 里，只是不再管这个设备了

真正麻烦的是那种“模块加载成功、设备也识别了、但功能异常”的情况——这时候 lsmod 和 lspci -k 都看起来没问题，问题往往出在固件（firmware）、权限（如 /dev/vfio/ 访问）、或内核参数（如 iommu=pt 缺失）。别只盯着模块列表，得往下挖一层日志和硬件状态。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~