LTSSM状态机状态详解
好，上一章我们聊了LTSSM的基本骨架。这一章，我们深入到骨头缝里，看看每个状态到底在干什么。
说实话，我刚接触PCIe时，看着那十几个状态的头都大了。后来做项目调时序，才慢慢明白——LTSSM的本质，就是一套严格的握手协议。每个状态都有明确的使命，哪个状态卡住了，链路就建不起来。
2.1 状态机里的“三六九等”
LTSSM的状态，可以粗分为三大类。我习惯这么记：
- 链路训练态：Detect, Polling, Configuration。这哥仨负责把物理链路搭起来。
- 链路管理态：L0, L0s, L1, L2, Recovery。链路建好后，跑数据、省电、纠错，全靠它们。
- 特殊态：Hot Reset, Disabled, Loopback。这些用于调试、复位或者强制关闭。
每个状态的切换，背后都有定时器在倒计时。说白了，定时器就是LTSSM的“耐性”。耐性不够（超时短），链路可能频繁误判；耐性太好（超时长），恢复就慢。
2.2 核心状态逐个解析
下面我挑几个麻烦最多的状态说说。其他状态大致能猜到，这几个必须吃透。
2.2.1 Detect 状态
链路训练的起点。发器（Transmitter）在差分对上发送一个“检测信号”，看看有没有东西连上了。
- 任务：找到对端设备。
- 关键参数：Detect Quiet Time、Detect Active Time。我记得默认值好像挺长的，但有些老设备需要更长的时间才能响应。
- 我踩过的坑：曾经有一批定制卡，上电后RX Detection总是超时，链路直接掉到Disabled状态。查了半天，发现是对方的Receiver Termination使能慢了。后来我们把这个超时参数从12ms放宽到24ms，问题解决。
2.2.2 Polling 状态
检测到对端后，进入Polling。发Training Sequence（TS1/TS2）符号，同步bit lock和symbol lock。
- 任务：确定链路宽度，对齐比特流。
- 定时器：Polling Active Timer。如果超时还没lock上，回Detect重新来。
- 注意：交叉线（Crossover）的检测也在这里完成。如果你发现链路死活只能跑x2，但明明两边都是x8，不妨看看Polling阶段log。八成是有一方的差分信号极性反了。
2.2.3 Configuration 状态
真正的“谈婚论嫁”阶段。双方交换能力：支持多大宽度、多少Lane、是否支持L0s/L1等等。
- 任务：完成链路宽度协商，并分配Lane号。
- 定时器：Configuration Idle Timer、Configuration Link Width Timer。
- 为什么我总调这个？ 因为不同厂商芯片协商逻辑不一样。有的激进，一上来就尝试x16；有的保守，先试x8再扩。定时器设短了，快速收敛；设长了，万一遇到不兼容的设备，链路就僵死在这儿。
2.2.4 L0 状态
开心地传输数据。这是正常工作态，也是我们要优化的目标。
- 任务：传递TLP和DLLP。
- 定时器：这里没有专门的L0定时器，但L0的“稳定性”依赖于其他状态的超时机制。
- 一个容易忽略的点：L0完全是硬件自同步的。你不需要去管它怎么维持，但你要确保从其他状态回到L0的过程足够快。
2.2.5 Recovery 状态
当链路上发生Bit Error、或者需要调整速度（比如从Gen1升到Gen3）时，进入Recovery。
- 任务：重新进行EQ，恢复比特锁定和块对齐。
- 定时器：Recovery Active Timer、Recovery Equalization Timer。这两个是调优的重灾区。
- 核心观点：链路速率越高，Recovery允许的定时就越紧。Gen4下，很多旧的主板网卡在Recovery阶段超时，因为它们的EQ过程太慢了。我个人的习惯是，把这个超时放到PCIe Spec允许的max值，宁慢勿断。
2.2.6 L0s 与 L1 状态
这两个是省电态（ASPM）。L0s是轻睡，快速进快速出；L1是深睡，省电多但退出也慢。
- 任务：降低功耗。
- 定时器：L0s Entry Timer、L1 Entry Timer。
- 实际案例：我做服务器时发现，某些SATA控制器如果进入L1时间太短，频繁进出反而比不省电更耗电。我们当时把这个Entry Timer从1us改到100us，性能完全没影响，功耗还降了5%。
2.2.7 L2 状态
几乎完全掉电，只保留一些辅助信号。
- 任务：Vaux电源维持，等待唤醒事件。
- 定时器：L2 Idle Timer。
- 注意：L2退出时，相当于重新走一遍Detect到Cfg，所以延迟很大。除非真的需要深度休眠（比如笔记本合盖），否则一般不建议设备主动进L2。
2.3 状态迁移中的“定时器陷阱”
你想想看，每个状态的退出，要么靠收到对端的确认信号（比如TS2），要么靠定时器超时。信号可能丢，但定时器一定会硬生生地跳完。这就是LTSSM的“保底机制”。
但很多人只关注了单一状态的超时值，忽略了整个迁移路径上的累积时间。
举个例子：链路在Recovery里做Speed Change，需要先走到Recovery.Equalization，再走回L0。如果Equalization阶段的定时器设了20ms，Recovery Active又设了10ms，那从故障到恢复，最多可能等30ms。这30ms对普通HBA卡还行，但对NVMe直连，主机端驱动早就报Fatal Error了。
2.4 SVG: LTSSM 主循环流程
2.5 状态参数速查表
我整理了一个简表，方便你对照。这些参数都在PCIe Base Spec里，但不同Gen的默认值有变化。
| 状态 | 主要活动 | 典型超时参数 | 易错点 |
|---|---|---|---|
| Detect | RX检测 | Detect Quiet Time (12ms) | 对端使能慢时超时 |
| Polling | Bit/Symbol Lock | Polling Active (2ms) | 信号完整性差时反复超时 |
| Configuration | Lane协商/交换 | Config Idle (50us) | 跨厂商兼容性问题高发区 |
| L0 | 正常传数据 | 无独立定时器 | 由Recovery等状态间接保护 |
| Recovery | EQ/重对齐 | Recovery Active (12ms) | Gen4/Gen5 EQ窗口太小导致失败 |
| L0s | 轻量省电 | L0s Entry (可配) | 频繁进出反而增加延迟 |
| L1 | 深度省电 | L1 Entry (可配) | Entry time配太小，非但没省电还耗电 |
| L2 | 掉电待唤醒 | L2 Idle (20ms) | 退出代价高，几乎等于重启链路 |
2.6 一个小结
这一章我尽量把每个状态的“脾气”给你讲透了。如果你记住两点就够：第一，每个状态是个有限状态机，它的退出口要么是收到协议信号，要么是定时器超时。第二，调优不能只看一个状态，要算整条路径的账。