搞Linux排查硬件lspci 几乎是人手一条的命令。插上新卡不识别、开机没显示、驱动装上又掉凡是跟 PCI 设备沾边的问题第一反应都是先lspci看一遍。输出里的“Kernel modules”这一列尤其关键它直接告诉你内核里有哪些驱动模块可以接管这台设备。但很多人从来没想过这一列信息到底是从哪里来的是 lspci 自己读出来的还是内核告诉它的为什么设备明明插的是 AMD 的卡执行lspci | grep -i amd却搜不到任何内容这篇文章就围绕 lspci 和 Kernel modules 这条信息链路把数据源头、解析逻辑、匹配机制和故障排查完整过一遍。适合刚接触 Linux 驱动排查的运维、嵌入式开发者也适合那些想知道“系统到底怎么知道该加载哪个驱动”的进阶玩家。1. lspci 与 Kernel modules 列先搞清楚它到底在显示什么1.1 Kernel modules 列不等于“当前正在用的驱动”用lspci -k查看设备时会看到两行容易混淆的内容Kernel driver in use和Kernel modules。我见过不少朋友把这两行当成一回事结果排查时走了不少弯路。严格来说这两行的含义完全不同Kernel driver in use指的是这台 PCI 设备当前实际绑定的驱动代表设备已经被某个驱动接管能在lsmod里查到对应模块而Kernel modules则是内核认为“有可能”匹配这台设备的模块列表它们只是候选未必加载了。举个常见的例子。一台同时有 Intel 核显和 NVIDIA 独立显卡的机器lspci -k会看到核显的Kernel driver in use是 i915而Kernel modules里列出 i915 和 nouveau独显的Kernel driver in use是 nvidia但Kernel modules里可能同时有 nvidia 和 nouveau。这里 nouveau 就是纯候选系统并没有加载它。这个区分非常重要很多人看到Kernel modules里有 nouveau就觉得驱动冲突了其实只要Kernel driver in use是 nvidia设备就是被正常接管的没有冲突。1.2 默认输出里根本看不到这一列再强调一个基础事实lspci的默认输出只有一行设备描述比如VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] ...根本不会出现Kernel modules字样。必须加上-k或-v参数这一列才会显示出来。-k是最轻量的方式只多显示驱动关联信息-v更详细会显示设备的各项能力、中断、资源等-nn则能把 vendor ID 和 device ID 以数字形式打印出来比如1002:73bf。一般排查时我习惯直接lspci -nnk一起上一次把 ID、驱动、模块全看清。很多网上教程只写lspci或lspci -v新手照做之后看不到Kernel modules列还以为自己系统有问题其实只是参数没给够。1.3 为什么系统要把“候选”和“当前”分开这套设计不是刻意复杂而是 Linux 内核模块自动装载机制决定的。设备出现时内核设备核心会为它生成一个 modalias 标识udev/kmod 拿到这个标识后去模块别名的数据库里匹配决定加载哪些模块。但“加载哪个模块”只是尝试真正的绑定还要看驱动的 probe 是不是成功。候选驱动可以有很多个实际绑定只能有一个所以 lspci 用两行来分别显示这两个阶段的状态。换句话说Kernel modules是设备驱动匹配的第一道筛子Kernel driver in use是最后的结果。理解了这个关系后面看数据来源就顺理成章了。2. Kernel modules 的信息从哪来一条从硬件到模块的完整链路2.1 一切从 PCI 配置空间开始每一块 PCI 设备都有一段可以被系统读取的配置空间空间里固定位置存着 vendor ID、device ID、class code、子系统 ID 等信息。Linux 内核在系统启动和热插拔时扫描 PCI 总线把这些信息解析出来然后暴露到 sysfs也就是/sys/bus/pci/devices/目录下。拿一台 AMD 显卡举例设备目录通常是/sys/bus/pci/devices/0000:01:00.0里面有一堆小文件。执行cat /sys/bus/pci/devices/0000:01:00.0/vendor输出是0x1002这是 AMD 的 vendor IDdevice文件输出设备 IDclass文件是设备类别modalias文件则是拼接好的完整 ID 串。如果用生活化类比vendor ID 相当于省份device ID 是城市subsystem ID 是街道class code 则是职业。lspci 所有的显示内容本质上都是在拿这套数字 ID 做翻译它本身并不去碰硬件。2.2 pci.ids把数字 ID 翻译成厂商名的字典lspci 显示Advanced Micro Devices, Inc. [AMD/ATI]而不是0x1002靠的是一个文本数据库 pci.ids。它通常在/usr/share/hwdata/pci.ids部分发行版放在/usr/share/misc/pci.ids不装 hwdata 包的最小系统则完全没有这个文件。文件格式不复杂有注释行有 vendor 行有缩进的设备行还有再缩进的子系统行。lspci 启动时加载它按 ID 查表翻译。文件缺失或过旧输出就只剩 class 描述和数字 ID。管理数据库用update-pciids命令从网络获取最新版或者直接安装 hwdata 包。这里要注意pci.ids 只是给人看的字典它不参与任何驱动匹配驱动能不能用跟这个文件一点关系都没有。2.3 modalias 和 modules.alias匹配的核心lspci 的Kernel modules列来源其实不在 pci.ids 里真正的匹配发生在设备和模块之间核心是两个文件设备侧的 modalias和模块侧的 modules.alias。设备侧cat /sys/bus/pci/devices/0000:01:00.0/modalias会打印类似pci:v00001002d000073bfsv00001002sd0000...这样一串。它把 vendor、device、子系统 vendor、子系统 device、class 等信息按固定格式编码v 后面是 vendord 后面是 devicesv/sd 是子系统bc/sc 是分类码。模块侧驱动源码里用MODULE_DEVICE_TABLE(pci, xxx_ids)声明支持的 ID 表。编译安装模块时depmod 扫描所有内核模块从中提取这些 ID 表生成/lib/modules/$(uname -r)/modules.alias和modules.alias.bin。里面的每一行都是一个“模块别名”形如alias pci:v00001002d000073bfsv* sd* bc* sc* i* amdgpu。运行lspci -k时lspci 通过 libkmod 把设备的 modalias 和 modules.alias.bin 里的所有规则做匹配凡是匹配到的模块名全部收进Kernel modules列。这一段链路才是“Kernel modules 信息来源”的核心答案。2.4 整条链路一图流设备 PCI 配置空间 → 内核 PCI 枚举 → sysfs 暴露 vendor/device/class/modalias → pci.ids 翻译成厂商名 → lspci 显示设备描述 → libkmod 用 modalias 匹配 modules.alias → 列出候选内核模块。所以下次再有人问“lspci 怎么知道该列哪些模块”答案不是“它猜的”也不是“它读驱动的”而是它走了整整一条从硬件配置空间到内核模块别名的数据链路。了解这条链路排查驱动问题会轻松很多。3. 复盘“lspci | grep -i amd 无反应”为什么明明有 AMD 设备却搜不到3.1 最常见的原因默认输出里根本没有你想搜的字段先说一个我遇到最多的场景。很多人听说lspci | grep能过滤设备就直接执行lspci | grep -i amd想找到 AMD 显卡对应的驱动线索。但默认的 lspci 输出里只有一行设备描述既没有Kernel modules列也不一定包含你想找的模块名。你要是想搜的是amdgpu这样的模块名默认输出里当然没有就算设备确实是 AMD 的如果 pci.ids 数据库里缺这条记录输出可能连“AMD”字样都没有。所以遇到“没反应”先分清你搜的到底是厂商名AMD还是模块名amdgpu再决定要不要加-k。grep -i amd想看到结果前提是 lspci 输出的文本里真的有“AMD”这三个字母想看到驱动模块就得用lspci -k | grep -i amd或者直接搜模块名。3.2 pci.ids 缺失连厂商名都没了最小化安装、容器环境、精简服务器上hwdata 或 pciutils 的数据文件很可能没装。此时 lspci 的输出变成VGA compatible controller加一堆编号完全没有Advanced Micro Devices, Inc.。这种情况下grep -i amd搜不到再正常不过。验证方法很简单ls /usr/share/hwdata/pci.ids看文件在不在或者跑lspci -nn看有没有显示数字 ID。解决就是安装 hwdata 包或运行update-pciids更新数据库。老硬件如果设备 ID 较新数据库过旧时厂商名也会缺失更新一下往往就恢复了。3.3 alias 和机器可读模式的干扰还有一种隐藏坑很多人在~/.bashrc里设了alias lspcilspci -nn。这样表面上设备输出的是1002:73bf没有“AMD”字样grep -i amd自然为空。看起来“无反应”其实只是 lspci 在你的环境里被改了默认参数。检查type lspci就能看到你是不是被 alias 坑了。另外管道场景下 lspci 的输出格式会变化尤其是lspci -mm机器可读模式每个字段用引号包裹、用换行符分隔和终端看到的表格完全不一样。在这种模式下 grep 搜索的关键词、期望的输出结构都要重新设计直接拿平时的 grep 习惯套上去很容易出现“明明有 AMD 设备却搜不到”的错觉。3.4 设备 ID 不在数据库里厂商名匹配但型号缺失最后一种典型情况设备能显示Advanced Micro Devices, Inc.但设备描述只有VGA compatible controller没有Radeon RX等具体型号。这是因为 pci.ids 里没收录这个 device ID或者数据库太旧。此时grep -i amd能匹配到 vendor 行但grep -i radeon匹配不到很多人会误以为“显卡没识别”。用lspci -nn拿到数字 ID去 pci.ids 或网上查真实型号再考虑更新数据库就清楚了。4. 实操手册把 Kernel modules 的来源一条条查出来4.1 设备侧从 sysfs 读取原始 IDlspci 显示的是翻译结果sysfs 里的是原始值。排查时我喜欢直接看 sysfs它不受 pci.ids 数据库影响for d in /sys/bus/pci/devices/*/; do echo $d cat $d/vendor $d/device $d/class cat $d/modalias done这样能看到所有 PCI 设备的 vendor、device 和完整 modalias。对比lspci -nn的输出能确认 lspci 是否因为数据库缺失做出了错误的翻译。如果 sysfs 里的 vendor 是 0x1002但 lspci 没显示 AMD那就是字典的问题不是硬件问题。4.2 模块侧用 modinfo 验证 aliasmodinfo -F alias可以看某个模块导出的所有别名。比如modinfo -F alias amdgpu会打印一长串pci:v00001002d...格式的条目。重点关注通配符d0000*表示匹配该 vendor 下所有设备 ID。一个模块能匹配多个设备正是因为这些带通配符的别名。手工验证匹配也很简单把设备 modalias 字符串和模块 alias 做对照。modules.alias 里的星号就是通配符匹配成功就是候选模块。比如设备 modalias 是pci:v00001002d000073bf模块 alias 是pci:v00001002d000073bf*那就能对上lspci 的Kernel modules列就会列出这个模块。4.3 交叉验证lspci -k 结果和 lsmod 对比lspci -k 列出了所有“候选”lsmod 列出了“当前已加载”。两者做差集能发现没被加载的驱动lspci -k | grep -A2 -i vga lsmod | grep -i amdgpu如果设备Kernel driver in use为空、Kernel modules里有 amdgpu 但 lsmod 里没有说明 amdgpu 作为候选存在但没被自动加载问题出在模块自动加载环节而不是驱动不支持。反过来如果Kernel modules里根本没有 amdgpu问题就出在 depmod 缓存或模块本身。4.4 数据库和模块别名的刷新姿势更新 pci.ids 用update-pciids更新模块别名缓存用depmod -a。如果你手动放了一个新模块到/lib/modules/$(uname -r)/extra/不跑depmod -alspci 的Kernel modules列不会出现它的名字。这个顺序很多人搞反结果新驱动明明装了lspci 却看不到于是开始怀疑模块本身有问题。其实只是缓存没刷新。5. 常见问题与排查技巧实录5.1 Kernel modules 列为空怎么办大概三类原因设备 ID 确实没有模块支持内核模块没安装depmod 缓存没生成。排查顺序是先看 sysfs 的 modalias再用 modinfo 在/lib/modules里找匹配记录最后确认 depmod 是否跑过。cat /sys/bus/pci/devices/0000:01:00.0/modalias grep $(cat /sys/bus/pci/devices/0000:01:00.0/modalias) /lib/modules/$(uname -r)/modules.alias第二条命令如果没有任何输出说明在现有模块集里确实没有匹配项要么装驱动要么换内核而不是在 lspci 上找问题。5.2 设备显示 unknown 或空 ID旧硬件比较常见设备 ID 在最新 pci.ids 里也查不到lspci 只能显示unknown device。处理建议先更新数据库再用lspci -nn记录数字 ID 上网查询最后可以把完整输出-o参数保存到文件留档。这种问题不影响驱动加载因为驱动匹配不依赖 pci.ids只是显示上不好看。5.3 新增网卡或显卡后模块永远是候选但不加载这不是 lspci 的问题是 kmod 自动加载没触发。检查 udev 规则、modprobe.conf、模块是否在/lib/modules/$(uname -r)/下。要手动验证就modprobe一下能加载成功就说明模块本身没问题问题在自动加载策略。5.4 排查速查表现象可能原因排查命令解决方向lspci 无 Kernel modules 列没加 -k 或 -vlspci -k正确加参数grep -i amd 搜不到pci.ids 缺失ls /usr/share/hwdata/pci.ids安装 hwdata、update-pciids只显示数字 ID数据库过旧lspci -nnupdate-pciidsKernel modules 为空depmod 缓存未生成grep modalias /lib/modules/.../modules.aliasdepmod -a候选模块不加载自动加载没触发lsmod; modprobe 模块名检查 udev 规则、modprobe.d5.5 一点个人习惯踩过几次坑之后我的习惯是真正排查驱动问题时第一件事不是看 lspci而是cat /sys/bus/pci/devices/0000:01:00.0/modalias它把该看的都编码进去了。搜索时用grep -E AMD|amdgpu|1002多路搜索不把鸡蛋放在一个关键词上写脚本尽量按 vendor ID 比较不依赖文本翻译。这样能避免 pci.ids 缺失这种表层问题干扰判断。这套方法帮我解决了不少“驱动明明在却找不到设备”的怪问题希望对你有用。
搞Linux排查硬件lspci 几乎是人手一条的命令。插上新卡不识别、开机没显示、驱动装上又掉凡是跟 PCI 设备沾边的问题第一反应都是先lspci看一遍。输出里的“Kernel modules”这一列尤其关键它直接告诉你内核里有哪些驱动模块可以接管这台设备。但很多人从来没想过这一列信息到底是从哪里来的是 lspci 自己读出来的还是内核告诉它的为什么设备明明插的是 AMD 的卡执行lspci | grep -i amd却搜不到任何内容这篇文章就围绕 lspci 和 Kernel modules 这条信息链路把数据源头、解析逻辑、匹配机制和故障排查完整过一遍。适合刚接触 Linux 驱动排查的运维、嵌入式开发者也适合那些想知道“系统到底怎么知道该加载哪个驱动”的进阶玩家。1. lspci 与 Kernel modules 列先搞清楚它到底在显示什么1.1 Kernel modules 列不等于“当前正在用的驱动”用lspci -k查看设备时会看到两行容易混淆的内容Kernel driver in use和Kernel modules。我见过不少朋友把这两行当成一回事结果排查时走了不少弯路。严格来说这两行的含义完全不同Kernel driver in use指的是这台 PCI 设备当前实际绑定的驱动代表设备已经被某个驱动接管能在lsmod里查到对应模块而Kernel modules则是内核认为“有可能”匹配这台设备的模块列表它们只是候选未必加载了。举个常见的例子。一台同时有 Intel 核显和 NVIDIA 独立显卡的机器lspci -k会看到核显的Kernel driver in use是 i915而Kernel modules里列出 i915 和 nouveau独显的Kernel driver in use是 nvidia但Kernel modules里可能同时有 nvidia 和 nouveau。这里 nouveau 就是纯候选系统并没有加载它。这个区分非常重要很多人看到Kernel modules里有 nouveau就觉得驱动冲突了其实只要Kernel driver in use是 nvidia设备就是被正常接管的没有冲突。1.2 默认输出里根本看不到这一列再强调一个基础事实lspci的默认输出只有一行设备描述比如VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] ...根本不会出现Kernel modules字样。必须加上-k或-v参数这一列才会显示出来。-k是最轻量的方式只多显示驱动关联信息-v更详细会显示设备的各项能力、中断、资源等-nn则能把 vendor ID 和 device ID 以数字形式打印出来比如1002:73bf。一般排查时我习惯直接lspci -nnk一起上一次把 ID、驱动、模块全看清。很多网上教程只写lspci或lspci -v新手照做之后看不到Kernel modules列还以为自己系统有问题其实只是参数没给够。1.3 为什么系统要把“候选”和“当前”分开这套设计不是刻意复杂而是 Linux 内核模块自动装载机制决定的。设备出现时内核设备核心会为它生成一个 modalias 标识udev/kmod 拿到这个标识后去模块别名的数据库里匹配决定加载哪些模块。但“加载哪个模块”只是尝试真正的绑定还要看驱动的 probe 是不是成功。候选驱动可以有很多个实际绑定只能有一个所以 lspci 用两行来分别显示这两个阶段的状态。换句话说Kernel modules是设备驱动匹配的第一道筛子Kernel driver in use是最后的结果。理解了这个关系后面看数据来源就顺理成章了。2. Kernel modules 的信息从哪来一条从硬件到模块的完整链路2.1 一切从 PCI 配置空间开始每一块 PCI 设备都有一段可以被系统读取的配置空间空间里固定位置存着 vendor ID、device ID、class code、子系统 ID 等信息。Linux 内核在系统启动和热插拔时扫描 PCI 总线把这些信息解析出来然后暴露到 sysfs也就是/sys/bus/pci/devices/目录下。拿一台 AMD 显卡举例设备目录通常是/sys/bus/pci/devices/0000:01:00.0里面有一堆小文件。执行cat /sys/bus/pci/devices/0000:01:00.0/vendor输出是0x1002这是 AMD 的 vendor IDdevice文件输出设备 IDclass文件是设备类别modalias文件则是拼接好的完整 ID 串。如果用生活化类比vendor ID 相当于省份device ID 是城市subsystem ID 是街道class code 则是职业。lspci 所有的显示内容本质上都是在拿这套数字 ID 做翻译它本身并不去碰硬件。2.2 pci.ids把数字 ID 翻译成厂商名的字典lspci 显示Advanced Micro Devices, Inc. [AMD/ATI]而不是0x1002靠的是一个文本数据库 pci.ids。它通常在/usr/share/hwdata/pci.ids部分发行版放在/usr/share/misc/pci.ids不装 hwdata 包的最小系统则完全没有这个文件。文件格式不复杂有注释行有 vendor 行有缩进的设备行还有再缩进的子系统行。lspci 启动时加载它按 ID 查表翻译。文件缺失或过旧输出就只剩 class 描述和数字 ID。管理数据库用update-pciids命令从网络获取最新版或者直接安装 hwdata 包。这里要注意pci.ids 只是给人看的字典它不参与任何驱动匹配驱动能不能用跟这个文件一点关系都没有。2.3 modalias 和 modules.alias匹配的核心lspci 的Kernel modules列来源其实不在 pci.ids 里真正的匹配发生在设备和模块之间核心是两个文件设备侧的 modalias和模块侧的 modules.alias。设备侧cat /sys/bus/pci/devices/0000:01:00.0/modalias会打印类似pci:v00001002d000073bfsv00001002sd0000...这样一串。它把 vendor、device、子系统 vendor、子系统 device、class 等信息按固定格式编码v 后面是 vendord 后面是 devicesv/sd 是子系统bc/sc 是分类码。模块侧驱动源码里用MODULE_DEVICE_TABLE(pci, xxx_ids)声明支持的 ID 表。编译安装模块时depmod 扫描所有内核模块从中提取这些 ID 表生成/lib/modules/$(uname -r)/modules.alias和modules.alias.bin。里面的每一行都是一个“模块别名”形如alias pci:v00001002d000073bfsv* sd* bc* sc* i* amdgpu。运行lspci -k时lspci 通过 libkmod 把设备的 modalias 和 modules.alias.bin 里的所有规则做匹配凡是匹配到的模块名全部收进Kernel modules列。这一段链路才是“Kernel modules 信息来源”的核心答案。2.4 整条链路一图流设备 PCI 配置空间 → 内核 PCI 枚举 → sysfs 暴露 vendor/device/class/modalias → pci.ids 翻译成厂商名 → lspci 显示设备描述 → libkmod 用 modalias 匹配 modules.alias → 列出候选内核模块。所以下次再有人问“lspci 怎么知道该列哪些模块”答案不是“它猜的”也不是“它读驱动的”而是它走了整整一条从硬件配置空间到内核模块别名的数据链路。了解这条链路排查驱动问题会轻松很多。3. 复盘“lspci | grep -i amd 无反应”为什么明明有 AMD 设备却搜不到3.1 最常见的原因默认输出里根本没有你想搜的字段先说一个我遇到最多的场景。很多人听说lspci | grep能过滤设备就直接执行lspci | grep -i amd想找到 AMD 显卡对应的驱动线索。但默认的 lspci 输出里只有一行设备描述既没有Kernel modules列也不一定包含你想找的模块名。你要是想搜的是amdgpu这样的模块名默认输出里当然没有就算设备确实是 AMD 的如果 pci.ids 数据库里缺这条记录输出可能连“AMD”字样都没有。所以遇到“没反应”先分清你搜的到底是厂商名AMD还是模块名amdgpu再决定要不要加-k。grep -i amd想看到结果前提是 lspci 输出的文本里真的有“AMD”这三个字母想看到驱动模块就得用lspci -k | grep -i amd或者直接搜模块名。3.2 pci.ids 缺失连厂商名都没了最小化安装、容器环境、精简服务器上hwdata 或 pciutils 的数据文件很可能没装。此时 lspci 的输出变成VGA compatible controller加一堆编号完全没有Advanced Micro Devices, Inc.。这种情况下grep -i amd搜不到再正常不过。验证方法很简单ls /usr/share/hwdata/pci.ids看文件在不在或者跑lspci -nn看有没有显示数字 ID。解决就是安装 hwdata 包或运行update-pciids更新数据库。老硬件如果设备 ID 较新数据库过旧时厂商名也会缺失更新一下往往就恢复了。3.3 alias 和机器可读模式的干扰还有一种隐藏坑很多人在~/.bashrc里设了alias lspcilspci -nn。这样表面上设备输出的是1002:73bf没有“AMD”字样grep -i amd自然为空。看起来“无反应”其实只是 lspci 在你的环境里被改了默认参数。检查type lspci就能看到你是不是被 alias 坑了。另外管道场景下 lspci 的输出格式会变化尤其是lspci -mm机器可读模式每个字段用引号包裹、用换行符分隔和终端看到的表格完全不一样。在这种模式下 grep 搜索的关键词、期望的输出结构都要重新设计直接拿平时的 grep 习惯套上去很容易出现“明明有 AMD 设备却搜不到”的错觉。3.4 设备 ID 不在数据库里厂商名匹配但型号缺失最后一种典型情况设备能显示Advanced Micro Devices, Inc.但设备描述只有VGA compatible controller没有Radeon RX等具体型号。这是因为 pci.ids 里没收录这个 device ID或者数据库太旧。此时grep -i amd能匹配到 vendor 行但grep -i radeon匹配不到很多人会误以为“显卡没识别”。用lspci -nn拿到数字 ID去 pci.ids 或网上查真实型号再考虑更新数据库就清楚了。4. 实操手册把 Kernel modules 的来源一条条查出来4.1 设备侧从 sysfs 读取原始 IDlspci 显示的是翻译结果sysfs 里的是原始值。排查时我喜欢直接看 sysfs它不受 pci.ids 数据库影响for d in /sys/bus/pci/devices/*/; do echo $d cat $d/vendor $d/device $d/class cat $d/modalias done这样能看到所有 PCI 设备的 vendor、device 和完整 modalias。对比lspci -nn的输出能确认 lspci 是否因为数据库缺失做出了错误的翻译。如果 sysfs 里的 vendor 是 0x1002但 lspci 没显示 AMD那就是字典的问题不是硬件问题。4.2 模块侧用 modinfo 验证 aliasmodinfo -F alias可以看某个模块导出的所有别名。比如modinfo -F alias amdgpu会打印一长串pci:v00001002d...格式的条目。重点关注通配符d0000*表示匹配该 vendor 下所有设备 ID。一个模块能匹配多个设备正是因为这些带通配符的别名。手工验证匹配也很简单把设备 modalias 字符串和模块 alias 做对照。modules.alias 里的星号就是通配符匹配成功就是候选模块。比如设备 modalias 是pci:v00001002d000073bf模块 alias 是pci:v00001002d000073bf*那就能对上lspci 的Kernel modules列就会列出这个模块。4.3 交叉验证lspci -k 结果和 lsmod 对比lspci -k 列出了所有“候选”lsmod 列出了“当前已加载”。两者做差集能发现没被加载的驱动lspci -k | grep -A2 -i vga lsmod | grep -i amdgpu如果设备Kernel driver in use为空、Kernel modules里有 amdgpu 但 lsmod 里没有说明 amdgpu 作为候选存在但没被自动加载问题出在模块自动加载环节而不是驱动不支持。反过来如果Kernel modules里根本没有 amdgpu问题就出在 depmod 缓存或模块本身。4.4 数据库和模块别名的刷新姿势更新 pci.ids 用update-pciids更新模块别名缓存用depmod -a。如果你手动放了一个新模块到/lib/modules/$(uname -r)/extra/不跑depmod -alspci 的Kernel modules列不会出现它的名字。这个顺序很多人搞反结果新驱动明明装了lspci 却看不到于是开始怀疑模块本身有问题。其实只是缓存没刷新。5. 常见问题与排查技巧实录5.1 Kernel modules 列为空怎么办大概三类原因设备 ID 确实没有模块支持内核模块没安装depmod 缓存没生成。排查顺序是先看 sysfs 的 modalias再用 modinfo 在/lib/modules里找匹配记录最后确认 depmod 是否跑过。cat /sys/bus/pci/devices/0000:01:00.0/modalias grep $(cat /sys/bus/pci/devices/0000:01:00.0/modalias) /lib/modules/$(uname -r)/modules.alias第二条命令如果没有任何输出说明在现有模块集里确实没有匹配项要么装驱动要么换内核而不是在 lspci 上找问题。5.2 设备显示 unknown 或空 ID旧硬件比较常见设备 ID 在最新 pci.ids 里也查不到lspci 只能显示unknown device。处理建议先更新数据库再用lspci -nn记录数字 ID 上网查询最后可以把完整输出-o参数保存到文件留档。这种问题不影响驱动加载因为驱动匹配不依赖 pci.ids只是显示上不好看。5.3 新增网卡或显卡后模块永远是候选但不加载这不是 lspci 的问题是 kmod 自动加载没触发。检查 udev 规则、modprobe.conf、模块是否在/lib/modules/$(uname -r)/下。要手动验证就modprobe一下能加载成功就说明模块本身没问题问题在自动加载策略。5.4 排查速查表现象可能原因排查命令解决方向lspci 无 Kernel modules 列没加 -k 或 -vlspci -k正确加参数grep -i amd 搜不到pci.ids 缺失ls /usr/share/hwdata/pci.ids安装 hwdata、update-pciids只显示数字 ID数据库过旧lspci -nnupdate-pciidsKernel modules 为空depmod 缓存未生成grep modalias /lib/modules/.../modules.aliasdepmod -a候选模块不加载自动加载没触发lsmod; modprobe 模块名检查 udev 规则、modprobe.d5.5 一点个人习惯踩过几次坑之后我的习惯是真正排查驱动问题时第一件事不是看 lspci而是cat /sys/bus/pci/devices/0000:01:00.0/modalias它把该看的都编码进去了。搜索时用grep -E AMD|amdgpu|1002多路搜索不把鸡蛋放在一个关键词上写脚本尽量按 vendor ID 比较不依赖文本翻译。这样能避免 pci.ids 缺失这种表层问题干扰判断。这套方法帮我解决了不少“驱动明明在却找不到设备”的怪问题希望对你有用。
