应使用sudo lspci -vvv定位lnksta行查看实际协商的speed和width，因普通用户权限不足会导致该行缺失；单纯grep "speed"会混淆lnkcap（标称能力）、devcap和lnksta（真实状态），且部分设备lnksta藏于二级功能或需sysfs路径/current_link_speed交叉验证。
直接看 lspci -vvv 输出里的 LnkSta 行，它显示的是当前真实协商的链路速度和宽度，不是设备标称能力，也不是插槽物理规格。
为什么只用 lspci -vvv | grep "Speed" 会出错
这条命令容易把 LnkCap（设备支持上限）、DevCap（设备能力）和 LnkSta（实际状态）混在一起，导致误判。比如：
-
LnkCap: Speed 16GT/s, Width x4是卡本身能跑 PCIe 4.0 x4，但不代表它正在跑 -
LnkSta: Speed 8.0GT/s, Width x2才是真相：它当前只协商到 PCIe 3.0 x2 - 某些设备（如老网卡或 BMC 直连设备）的
LnkSta行可能完全不出现，grep会漏掉这类问题
必须加 sudo 才能看到 LnkSta
普通用户执行 lspci -vvv 时，PCIe 配置空间中部分寄存器（尤其是链路状态寄存器）读不到，LnkSta 行可能为空、字段缺失，甚至整行消失。这不是命令没输出，是权限不足。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 一定要用
sudo lspci -vvv，否则诊断无效 - 如果加了
sudo还看不到LnkSta，检查内核是否启用了CONFIG_PCIEASPM，或 BIOS 是否关闭了 “PCIe Link State Reporting” - 遇到多功能设备（如 NVMe 控制器带 Function 0 和 Function 1），
LnkSta可能藏在二级功能里，得用sudo lspci -s 00:1d.1 -vvv单独查
比 lspci 更稳的验证方式：读 /sys/bus/pci/devices/xxx/current_link_speed
lspci 依赖用户空间工具解析配置空间，而 /sys 下的值由内核直接从硬件寄存器读取，更贴近运行时真实状态，尤其适合脚本批量采集或 lspci 失效时兜底。
- 先定位设备地址：
lspci | grep -i nvme→ 得到类似0000:09:00.0 - 检查路径是否存在：
ls /sys/bus/pci/devices/0000:09:00.0/ - 读当前速率：
cat /sys/bus/pci/devices/0000:09:00.0/current_link_speed（输出是纯数字，如8.0） - 读最大能力：
cat /sys/bus/pci/devices/0000:09:00.0/max_link_speed；若二者不等，说明链路已降速
真正容易被忽略的点是：LnkSta 显示 Speed 0.0GT/s 或字段为空，不是“速度慢”，而是链路根本没建立——这时候该去看 dmesg | grep -i pcie，查供电、BIOS PCIe 设置是否禁用、或设备是否被识别为 disabled 状态。
