直接看lspci -vvv输出中的LnkSta行：Speed值（如8GT/s对应PCIe 3.0）和Width值（如x4）即当前实际协商速率与通道数；LnkCap仅表示设备最大支持能力，LnkSta才是真实运行状态。
直接看 lspci -vvv 输出里的 LnkCap 和 LnkSta 两行，就能确认 PCIe 设备当前实际协商的速率和宽度 —— 不是标称值，不是插槽物理规格，就是此刻链路真实状态。
怎么看 PCIe 实际速率和通道数
关键字段在 lspci -vvv 输出中紧挨着的两行：
-
LnkCap（Link Capability）：设备“能支持”的最大能力，比如Speed 8GT/s, Width x16 -
LnkSta（Link Status）：当前“实际协商成功”的状态，比如Speed 5GT/s, Width x8
注意：LnkSta 才是真相。常见现象包括：
- 插在 x16 插槽的卡只跑 x8 —— 可能是 CPU PCIe 通道被显卡/其他设备分走
- PCIe 4.0 卡显示
Speed 5GT/s—— 实际是 PCIe 3.0（5 GT/s），说明链路降速了 -
LnkSta显示Speed 2.5GT/s—— 基本是 PCIe 1.0，大概率存在兼容性或供电问题
为什么 lspci -vvv | grep "Speed" 不够用
单纯管道过滤会漏掉关键上下文，因为：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
Speed字样可能出现在LnkCap、LnkSta、甚至DevCap里，混在一起无法判断哪行是当前状态 - 有些设备（尤其是老芯片组或虚拟化环境）
LnkSta行可能不显示Width，只靠Speed无法确认是否降宽 - 部分 BIOS 会隐藏
LnkSta，此时需配合sudo lspci -xxx查配置空间偏移0x12（Link Status Register）手动解析
更稳妥的做法是定位到具体设备后，用 sudo lspci -s 01:00.0 -vvv 精确查看，并肉眼比对 LnkCap 与 LnkSta。
哪些参数会影响 LnkSta 显示结果
真实链路协商受软硬多层制约，不是命令本身的问题：
-
ASPM（Active State Power Management）开启时，某些设备会在空闲期主动降速，LnkSta可能短暂显示低速 —— 需持续观察或禁用测试：echo 'performance' > /sys/bus/pci/devices/0000:01:00.0/power/control - BIOS 中关闭了
Resizable BAR或启用了CSM（Compatibility Support Module），可能导致 PCIe 3.0+ 设备强制回落到 2.5 GT/s - 主板插槽物理支持 x4，但卡是 x16，
LnkCap写 x16 没用，LnkSta最高只能到 x4 - 驱动未加载或处于 error recovery 状态时，
LnkSta可能显示为0000或完全缺失 —— 此时先检查lspci -k -s 01:00.0确认模块状态
容易被忽略的权限和稳定性风险
lspci -vvv 多数字段普通用户可读，但以下操作必须 sudo 且有风险：
-
lspci -xxx会读取整个 PCIe 配置空间，某些老旧或异常设备在读取未实现寄存器时可能触发PCIe AER错误甚至系统 hang 住 -
lspci -M（全总线扫描模式）在有故障桥接器的系统上可能造成不可逆中断，仅限调试环境使用 -
/proc/bus/pci/在较新内核（5.10+）中默认禁用，依赖CONFIG_PCI_SYSFS，若发现lspci输出异常简略，先确认该选项是否启用
真正要定位带宽瓶颈，别只盯着 Speed 数字 —— LnkSta 的宽度（Width）和速率（Speed）必须同时满足设备需求，缺一不可。而这两项是否匹配，只有 lspci -vvv 的原始输出里才藏得最老实。
