| 基于Linux系统的PCIe常见问题定位总结 | 您所在的位置：网站首页 › 下线设备未开启什么意思 › 基于Linux系统的PCIe常见问题定位总结 |
基于Linux系统的PCIe常见问题定位总结
|
背景 笔者3年多Linux PCIe驱动开发与PCIe芯片验证经验，当前已经不专门搞PCIe，故做一个回顾与小结，希望后面不太清楚时能回头来看看。 建链问题PCIe的拓扑和Linux的PCIe IDPCIe的建链问题比较常见，由于各种厂商定位PCIe的方式方法不同，这里我们只介绍协议的方式 如何判断当前链路状态。在介绍建链前需要补充一下PCIe设备如何查看ID。Linux系统下通过以下命令，可以查到当前 PCIe 的拓扑图。 lspci –vt下图是执行该命令后某个编译服务器的部分拓扑截图。关键信息是各个设备的ID即DBDF(Domain,Bus,Deivce,Function)号，识别到ID后才能针对某个设备做精确的查询和控制。  图1图中有个IEP设备就是0000:00:00.0, 这里的几个域的含义是第一个0000是domain域基本上都是0，第二个00是Bus总线号，第三个00是Device 设备号，第四个0是Function 功能号。这个RCiEP(Root Complex Integrated Endpoint)设备是Intel CPU自带的内部的模块，我们不需要关注，我们需要关注的是RP(Root Port)和EP(Endpoint)，这里是借这个设备说明一下如何查看PCIe 设备的DBDF号，图中红字也有说明。 这个图里面能看到有3 RP，即00:01.0, 00:02.0, 00:03.0。同时也能看到00:02.0下挂了一个EP，但这个EP有两个PF(Physical Function)，一个是02:00.0 WX7100 一个是02:00.1 RX580。同时00:03.0 下挂了一个EP，这个EP只有一个PF 03:00.0 NVMe SSD 自此，该拓扑解析完成，目前看到有3个RP 2个EP，且有个EP有2个PF，还有1个RCiEP。 注：绝大部分场景下，设备都在一个domain域内，所以lspci工具使用时通常会省略domain域，即domain默认值为0。 查看当前PCIe建链状态当我们已经知道拓扑后，我们就知道哪个设备挂载哪个RP下了。假设我们有个设备挂载上图的0:01.0 这个RP上，但是没有看到EP设备怎么办。这时需要确认RP的建链状态 使用命令查看当前RP设备的配置空间解析，用于查看当前RP状态 sudo lspci -vvs 0:1.0执行结果如下图所示  图2其中红框中的DLActive- 就代表该Port并未建链。 无法建链问题如果出现无法建链的情况需要优先排查下列三种情况 卡是否有插入对应插槽，是否插槽插错了或者没有插好EP卡是否有问题，在其他设备上是否能正常使用RP对应的槽位是否能正常，别的正常卡能否插在该槽位正常工作如果这三点都排查了，都工作正常，那有可能就是从RP到EP的链路质量不好。需要硬件先测一下眼图，看看是否真的信号质量太差。如果确实信号质量差，那就要按照协议调整PCIe的一些硬件参数。如果是自研芯片或者能看到寄存器信息的芯片，则可以通过读取芯片PCIe的状态机状态来判断是在那个阶段就出现问题了。还可以排查一些PCIe的配置，比如时钟来源等等。 建链的问题较多，这里只是给了一些思路，具体还要根据实际的场景实际分析。 注：可能有些BIOS/UBOOT在启动阶段如果不能建链, BIOS/UBOOT就会关闭对应RP用于节能。如果实在调试EP设备，需要注意启动时间与BIOS对应。 带宽速率不符合预期如图3 所示DLActive状态正常，红框中的代表当前建链的状态即与对端协商到的带宽和速率是多少。蓝框中的表示当前我这个设备支持的单宽和速率是多少。  图3图3是EP的配置空间，如果这里红框中的speed和蓝框中speed需要对应的话，那这会儿的建链是有问题的，需要确认为什么speed明明支持到8G/s(GEN3)但是当前只建链到2.5Gb/s(GEN1)。这里需要先确认RP的配置空间是否支持到8G/s(GEN3)，如果RP只支持则建链到2.5Gb/s(GEN1)是符合协议的。  图4从图4中能看到RP是支持8G/s(GEN3)，这里就需要确认为什么链路只建链到2.5Gb/s(GEN1)。当然这里的原因是因为显卡根据负载会自动切换速率，当前我们没用显卡，所以显卡驱动时为了省电故意将速率切换到2.5Gb/s(GEN1)。但如果我们对接的卡并不支持动态切换速率的话，就需要检查为什么不能建链到更高速度。一般的原因还是因为信号质量不好，尝试切速的时候误码过多，无法recovery 成功，所以速率无法上去。 当然还有些是width 与预期不匹配，一般原因仍然是跟物理通路有关，可能某条通路不通或者信号质量太差，但是其他部分通路是通的，则有可能建链到与预期不匹配的带宽上。 枚举问题枚举问题一般比较少。一般我理解的枚举问题就是，上面那个例子中，RP的DLActive+ 但是仍然看不到对接的EP设备，可以尝试用以下命令重新枚举设备。 echo 1 > /sys/bus/pci/rescan注意老的Linux版本如果当前设备有其他PCI设备在正常运行，可能会受影响。如果不放心可以指定某个RP进行rescan如下命令 echo 1 > /sys/bus/pci/devices/0000\:00\:01.0/rescan执行命令后如果能看到设备，那么很有可能就是EP启动较慢，导致在HOST BIOS建链枚举阶段并未真正枚举到。在OS启动阶段也就看不到对应设备了。但在HOST启动OS后又建链了，可能才会出现这种现象。 当然如果上面的命令做了以后还是无法看到设备，可能需要怀疑EP设备是否能正常工作了，因为这个枚举动作实际上也是逻辑在参与，如果枚举不到大概率还是EP芯片逻辑出问题了。 AER问题AER (Advanced Error Reporting) 是PCIe设备的高级功能，PCIe设备如果出现问题可以通过这个机制上报给系统，然后系统来处理异常。 AER里面主要分为三种类型的故障，分别是：CE(Correctable Error), UE(Uncorrectable Error),UE中根据Severity寄存器又分为NFE(Non-Fatal Error), FE(Fatal Error)。一般来说CE 不会上报OS，PCIe设备自己处理，UE会上报OS。如果HOST为x86可能也不会管NEF，因为NFE的默认处理是断链，然后重新建链，但X86不只是热插拔，所以NEF要么不处理，要么不上报。FE的处理一般都是复位系统。 这里笔者列出较常见的故障有哪些，并说明一下出错原因。没有列出的，笔者暂时没有遇到过，还不太清楚问题出现原因，就不单独描述了。如果对这个AER有兴趣可以看PCIe协议。 Correctable Errors Receiver Error：可能是协商过程中出现误码，只要不影响功能可以不用关注Bad TLP Status：TLP 出现过错包，由于PCIe协议有重传机制，只要不一直出现，不会有大影响但如果持续出现会影响PCIe的通信效率。Bad DLLP Status：同上，只是改成了DLLP出现过错包。REPLAY_NUM Rollover Status：即错包过多，内部计数已经翻转，这个错误不常见，如果出现需要考虑物理通路上是否有太多误码而影响PCIe通信。Uncorrectable Errors Data Link Protocol Error Status：链路异常，笔者从未遇到过，暂时不知产生原因，但这个是fatal，如果真的产生可能需要通过PCIe协议分析仪看看为什么会有这种故障。Surprise Down Error Status: 即链路突然断链，fatal故障，x86默认重启。AARCH64 可以支持热插拔的场景下，可以通过修改Slot Capabilities Register 中的Hot-Plug Surprise 位，热插拔的时候可以不再上报这个故障。该故障的原因也有很多，比如真正的热插拔，或者插槽松动引起的Linkdown，误码过多引起的Linkdown，还有软件配置了Link Control Register中的Link Disable导致的Linkdown等等都有可能。Poisoned TLP Received Status：TLP中毒可以理解为一个错误的TLP报文，根据TLP报文的类型会导致的异常是未知的，一般建议是芯片内部不处理该报文并丢弃，但这个设计整个芯片处理逻辑。产生原因目前仍然可能是因为链路原因或RAM的位跳变引起，该异常不太常见，该异常出现后可能伴随着其他故障出现如UC 或CPL Timeout等。Completion Timeout Status：即发送的请求对端没有及时相应导致超时。该现象比较常见，较大可能是因为CPL 超时时间配置不合理，导致对端的请求还没处理完成就超时了，还有可能是对端逻辑出现故障了无法返回导致超时。Unsupported Request Error Status& Completer Abort Status：UR和CA，UR就是对端发了一个我处理不了的请求，CA就是这个请求被终止了，一般来说出现这种异常可能有其他异常出现，需要结合TLP Header来进一步分析异常原因。截图如下，记录的是第一次异常出现的TLP Header。
1、NCB-PCI_Express_Base_4.0r1.0_September-27-2017 |
【本文地址】