卡死状态定义：哪些状态属于卡死？卡死与正常等待的区别
做LTSSM诊断，第一件事就是要分清楚：什么算卡死，什么只是正常的等待。
我见过不少工程师，一看到某个状态停留了几毫秒就急着喊“卡死了”，结果查了半天发现是正常的链路训练延迟。反过来，也有兄弟在真正的卡死面前犹豫不决，白白浪费Debug时间。
这一章，咱们就把这个边界划清楚。
一、先给“卡死”下个定义
说白了，LTSSM卡死就是：逻辑状态机停在一个预期之外的状态，并且无法在规定时间内跳转到下一个合法状态。
注意两个关键词：
- 预期之外：指的是当前状态在当前场景下不该长时间停留。比如L0已经稳定运行了一小时，突然掉进Recovery就出不来了——这叫异常。
- 无法超时跳出：每个状态都有硬件超时计数器。如果超时倒计数归零后，状态机仍然没有触发跳转，那就是真的卡死了。
我在项目中遇到过一种情况：设备在Polling.Active状态下反复尝试，但Link始终没建立。我当时习惯先看LTSSM_STS寄存器的两次采样值是否相同——如果连续三次采样都是同一个副状态，基本可以判定卡死。
二、卡死与正常等待的核心区别
正常等待，是有“预期结局”的。比如L1状态，设备只是暂停转发事务，一旦收到Exit信号立即跳回L0。你想想看，这种等待有明确触发条件和有限时长。
但卡死不同。卡死是既没有前进的触发，也没有后退的路径。整个状态机就像卡在齿轮缝里，进退两难。
| 对比维度 | 正常等待 | 卡死状态 |
|---|---|---|
| 状态停留时长 | 符合规格要求，一般小于几微秒 | 远超规格，甚至无限 |
| 超时计数器行为 | 正常倒计数，归零后跳转 | 归零后未触发跳转，或计数器异常溢出 |
| 电气信号状态 | 稳定可预测 | 异常抖动、电平错误或Missing Idle |
| 软件可恢复性 | 无需干预 | 需复位或启动恢复机制 |
| 寄存器反馈 | 状态码持续变化 | 状态码被“冻结”或周期性回滚 |
这里有个避坑指南：我曾经被“伪卡死”骗过一次——设备在Recovery.RcvrLock状态停留了将近200微秒，我断定是卡死。后来排查发现，是因为对端的TxPreset延迟时间过长，导致RcvrLock超时值被错误地加载成了最大值。那不是卡死，是超时参数配置错误。
三、到底哪些状态属于“卡死状态”？
从我个人的Debug经验来看，以下这些状态或副状态是高危卡死区：
- Logical Idle卡死：常见于Hot Reset或Disable被误触发后，链路陷入永久Idle而无法退出。此时所有Lane都保持电气Idle，但状态机卡在“等待唤醒”的死循环里。
- Recovery卡死：在RcvrLock子状态卡死最频繁。表现为反复锁定失败，或者锁定后EQ（均衡）参数协商错误，导致状态机回弹到RcvrCfg再失败。
- Configuration卡死：多出现在Dynamic Reconfig或Lane Reversal场景下。设备死活等不到对方的配置参数完成。
- Polling & Detect相关卡死：常见于热插拔场景。Detect状态检测不到对端，或者Polling状态无法建立多Lane的Bit Lock。
下面这张图能帮你快速定位“卡死高危区”：
四、这些“伪卡死”状态你最好也记住
我习惯把下面几种情况归类为“伪卡死”——表面看着像卡死，实际是正常行为：
- L1.Entry超长等待：如果对端设备在睡眠模式下响应延迟，L1.Entry的停留时间可能被拉长到几十微秒。但这不是卡死，只要最终Exit成功就行。
- Hot Reset完成暂停：某些Root Complex在发送Hot Reset后会主动等待所有下游设备完成复位，这期间状态机看似“卡”在Reset状态，实际是在等待全局同步。
- Gen5/6速率的EQ试探：高速率下的均衡参数协商需要多次相位调整，有时Recovery状态会反复进出，只要整体时间在规范内（通常小于1ms），就属于正常。
怎么区分？我个人有个笨办法：在疑似卡死的状态上加一个0.5秒的软件定时器。如果0.5秒后状态码都没变，而且未触发任何超时中断，那基本就是真的卡死了。如果超时中断来了但状态跳走了，那就是正常延迟。
快速判断口诀：
一回采样看变化，二看超时又归零。
三查电气稳不稳，四问复位是不是。
状态若在必死区，恢复趁早莫犹豫。
五、实战中容易忽略的卡死诱因
讲几个我踩过的坑：
- Skew Margin不足：多Lane场景下，如果某条Lane的Skew超过内部FIFO深度，Recovery状态会反复尝试丢弃重对齐——这就是卡死的源头。我建议在物理层设计时至少预留两倍的Margin。
- RxTerm未启：有些SoC在低功耗模式退出后，接收端的终端电阻（RxTerm）启用来迟了，导致Detect状态检测到对端存在但Polling又建链失败。嗯，这种情况调试起来特别容易绕晕。
- 边带信号冲突：某些设计用了PERST#作为复位源，但如果PERST#被外部干扰时，LTSSM可能在多个状态间反复跳跃。我曾经遇到过PERST#上有一个几十纳秒的Glitch，导致设备卡在Recovery里整整一个小时。
警告：不要盲信超时中断！
有些硬件平台的超时中断只在主状态间迁移时才会触发，子状态内部超时不会报错。你看到中断没来，未必代表没卡死——建议主动查询LTSSM Capability Structure中的Max_Timeout字段，手动验证超时设置是否正确。
好了，关于卡死状态的定义和边界，就先梳理到这里。记住一句话：正常的等待有始有终，卡死状态无始无终。你在实际抓Trace时，拿住这条基准线，再配合状态对比和超时分析，大概率不会误判。