lsmod命令用于显示当前linux内核已加载的模块列表，包含模块名、大小（字节）和使用计数及依赖关系，它仅反映内存中活跃的驱动，不显示未加载的.ko文件或模块来源路径。

Linux系统里没有“安装驱动”这个概念，只有“已加载的内核模块”——也就是当前正在运行、被内核使用的驱动。所谓“所有驱动”，实际指已加载模块，而非硬盘上存着但没用的文件。

lsmod 是最直接的入口

lsmod 输出的是当前内存中活跃的驱动模块列表，包含模块名、大小、使用计数和依赖关系。它不显示未加载的.ko文件，也不区分“官方”或“第三方”驱动。

• 直接运行 lsmod 可看全量列表；想快速定位网卡驱动，用 lsmod | grep -i e1000\|iwl\|r8169
• 注意第三列（Used by）：值为 0 表示该模块未被其他模块或设备引用，但不一定没在用——比如 USB 设备拔掉后，usb_storage 可能仍显示 Used by 0，但它之前确实在工作
• lsmod 不显示模块来源路径，若需确认是内核自带还是外加的，得配合 modinfo <module_name></module_name> 查 srcversion 或 vermagic

lspci -k 和 lsusb -v 按硬件反查驱动

PCI/USB 设备有物理存在，lspci -k 和 lsusb -v 能告诉你“哪个设备用了哪个驱动”，比 lsmod 更具上下文。

PyCharm 2026.2.0.1 Linux版

PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。

下载

• lspci -k 的关键字段是 Kernel driver in use，它只显示当前绑定到设备的驱动，不显示同厂商其他可选驱动（比如 Intel 显卡可能同时装了 i915 和 intel_gpu_top，但只有 i915 在 Kernel driver in use 里）
• lsusb -v 输出巨大，真正有用的驱动名藏在 Driver=<code>字段（不是每个设备都有），更可靠的方式是先 <code>lsusb -t 找总线地址，再进 /sys/bus/usb/devices/<code> 看 <code>driver 符号链接
• 这两命令不显示未识别设备的驱动（比如 USB 设备插着但没被枚举成功），此时 dmesg | tail -30 才是第一手线索

/sys/modules 下能看见模块的实时状态

/sys/modules 是内核导出的模块运行时视图，每个子目录对应一个已加载模块，内容比 lsmod 更底层。

• ls /sys/modules/ 列出所有已加载模块名，和 lsmod 基本一致，但不带大小和依赖信息
• 进任意模块目录，比如 /sys/modules/e1000e/，cat refcnt 显示当前引用计数，cat initstate 显示是否已完成初始化（live 表示已就绪）
• 这里看不到模块参数值，要看实际生效配置得查 /sys/module/<module_name>/parameters/</module_name> 下的文件，比如 cat /sys/module/iwlwifi/parameters/led_mode

modinfo 只查模块元数据，不反映运行状态

modinfo 读取的是 .ko 文件的 ELF 段信息，哪怕模块根本没加载也能执行，所以它告诉你“这个驱动支持什么”，而不是“它现在有没有在跑”。

• modinfo e1000e 会显示作者、描述、参数列表、alias（用于自动加载）、firmware 依赖项等，但不会告诉你当前是否有网卡在用它
• 如果 modinfo 报错 Module e1000e not found，说明该模块不在 /lib/modules/$(uname -r)/ 下，或者被放在了非标准路径且没更新 depmod 缓存
• 别依赖 modinfo 的 version 字段判断实际运行版本——它来自编译时写入，而运行中的模块可能被 insmod 强制覆盖过，真实版本要以 ethtool -i <interface></interface> 或 lshw -class network 输出为准

真正容易被忽略的点是：驱动是否“在用”，取决于设备是否存在、是否被内核识别、是否完成 probe —— 这三步缺一不可。lsmod 只管最后一步，lspci -k 看前两步结果，dmesg | grep -i "probe\|failed" 才暴露中间失败环节。光列模块名，解决不了设备不工作的问题。