Issue背景描述：

Xilinx两块开发版PCIe link up时间相差很大，Virtex-6开发版PCIe link up时间超过60ms，而Virtex-7 PCIe link up时间只有~25ms.

分析过程：

1. 对比Virtex-6和Virtex-7两块开发板上电过程的LTSSM状态机。

首先看一下，Virtex-6开发版的LTSSM状态机，发现在多了一次Polling->Dectect的转换过程。

再来看Virtex-7开发版的LTSSM状态机，不同状态之间的转换符合PCIe Spec标准。

发现LTSSM状态机的异常点之后，然后结合详细的PCIe trace找到root cause.

2. 从Trace中看到，Upstream(Virtex-6)在Detect状态检查到RX存在之后，进入了Polling.Active状态，但是，之后由于一直未收到从Downstream下发的TS1序列，于是，就进入了Polling.Compliance状态. 此时，Upstream Lanes处于Electrical Idle。

3. 经过一段时间之后，Upstream Lanes看到EIOS之后，开始退出Polling.Compliance状态, 进入Polling.Active状态.

4. 接着，Downstream lanes进入Polling.Active状态，然后开始发送TS1序列。

5. 经过一段时间后，Upstream也进入了Polling.Active状态，然后开始发送TS1序列。

6. Upstream在Polling.Active状态实现了Bit Lock和Symbol Lock, 就转换进入到Polling.Configuration状态，并开始发送TS2序列。

7. 但是，问题来了，Downstream在Polling.Active状态未能成功实现了Bit Lock和Symbol Lock,在24ms timeout之后回到了Detect状态。

8. 此时，Upstream处于Polling.Configuration状态，在等待Downstream的TS2序列。由于Downstream已经回到Dectect状态了，Upstream在48ms内没有收到Downstream下发的TS2序列，也跟着返回Detect状态。

9. Downstream回到Dectect状态之后，就开始重新进行链路训练，在重新链路训练中，这次在Polling.Active状态成功实现了Bit Lock和Symbol Lock, 然后进入Polling.Configuration状态。最终成功实现PCIe链路训练。

从上面的分析过程中，我们看到，第7/8步中有两个timeout时间，分别是24ms和48ms，正是因为这两个timeout的存在，造成了Virtex-6开发版link up时间超过60ms。

Root Cause：

最后发现root cause是由于英特尔处理器中的一个bug造成的。如Intel Errata中的描述，由于Rx端过载保护电路的存在，可能会导致某些Device异常进入Polling.Compliance, 最后导致Downstream和Upstream之间状态出现偏差，引起Bit Lock/Symbol Lock错误。

精彩推荐:

• 浅析PCIe链路LTSSM状态机
  

• 浅析PCIe系统性能
  

• LDPC编解码初探
  

• 浅析PCI配置空间
  

• 步入新时代 | PCIe 4.0带来了哪些惊喜？

• PCIe SSD飞入寻常百姓家靠什么？
  

• SCM+MLC/TLC NAND混合SSD性能探究
  

• 浅析企业级SSD Multi-Stream Write技术
  

• 企业级SSD发展趋势
  

• 2D NAND和3D NAND横向对比
  

• 第二代3D TLC NAND原厂级深度评测

• 为QLC保驾护航 | 慧荣科技亮出最新LDPC技术

• SSD固态硬盘接口种类多，你了解多少？
  

• 写放大机制与影响因素详解

• 详解SSD之垃圾回收GC

• SSD为什么需要Trim？
  

• OP详解: 谁“偷”走了SSD的容量？

• SSD性能优化之4K对齐

• 文件系统全记录回顾
  

• 快来看，SATA秘籍惊现江湖！！！

• PCIe最全科普贴流出！不说了，赶快Mark！

• 独家发布 | Linux NVMe Driver学习笔记大合集
  

• 存储随笔《NVMe专题》大合集及PDF版正式发布！

更多精彩内容，敬请关注头条号【存储随笔】获取更多活动内容。

同时，也可以关注微信公众号: 存储随笔，Memory-logger.