PCIE链路训练 recovery 状态机拆解：从配置到恢复的完整状态流转-平芜编程栈

1. PCIE 链路训练 recovery 状态机到底在解决什么问题

如果你正在调试一块 PCIe 板卡，大概率见过这样的现象：lspci里链路速率从 16GT/s 掉到 8GT/s，或者dmesg里反复打印 "Link is down / Link up"，甚至系统跑着跑着设备直接消失。这类问题十有八九出在链路训练的 Recovery 状态机里。PCIE 链路训练状态机（LTSSM）负责从 Detect 一路把链路带到 L0 工作态，而 Recovery 是其中被触发最频繁、分支最多的一个状态——它既处理速率切换，也处理均衡重做、位锁丢失、电气空闲退出等异常恢复。理解 Recovery 内部从 RcvrLock 到 RcvrCfg、Equalization、Speed、Idle 的完整流转逻辑，是定位"链路反复重训"的关键。

这篇内容面向硬件调试和驱动开发场景，把 Recovery 状态机的触发条件、跳转判据、关键寄存器和超时机制拆开讲，并给出一套可复制的状态机配置骨架和寄存器验证动作。适合正在做 PCIe 链路 bring-up、遇到速率协商失败、或者需要判断链路是否稳定工作在目标速率的工程师。读完之后你应该能回答三个问题：当前链路为什么进 Recovery、它会在 Recovery 里走哪条路径、以及怎么用寄存器把这条路径确认下来。

2. 用 TaoToken 搭一个可对话的调试助手

调试 PCIe 状态机时，手边经常需要快速查协议条款、比对寄存器定义、或者让模型帮你解释一段 LTSSM 日志。我习惯用 TaoToken 起一个对话环境，把协议片段和寄存器手册丢进去做交叉验证。它的模型对话入口在 https://taotoken.net/api 对应的控制台里，先到 https://taotoken.net/api 的 console 页面创建一个 API Key，然后在模型对话里就能直接问"Recovery.RcvrLock 进入 RcvrCfg 需要满足哪几个条件"这类问题。

如果你是要长期做编码和 Agent 调试，比如写脚本自动解析lspci -vvv输出、批量比对链路状态寄存器，那更适合用 Coding Plan，把状态机解析逻辑做成可复用的工具。接入文档在 https://taotoken.net/api 的 doc 页面，API Key 管理在 https://taotoken.net/api 的 api-keys 页面。下面给一段用 Python 调用模型对话接口做日志分析的骨架，你可以直接改成自己的调试脚本。

import requests API_BASE = "https://taotoken.net/api" API_KEY = "你的_API_Key" def ask_ltssm(question: str) -> str: resp = requests.post( f"{API_BASE}/v1/chat/completions", headers={ "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json", }, json={ "model": "claude-sonnet", "messages": [ {"role": "system", "content": "你是 PCIe 协议调试助手，回答要给出寄存器名和状态跳转条件。"}, {"role": "user", "content": question}, ], "temperature": 0.2, }, timeout=60, ) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"] if __name__ == "__main__": print(ask_ltssm("Recovery.RcvrLock 在 8GT/s 以上速率时，收到 8 个连续 TS1 且 EC=00b 会跳到哪个状态？"))

这段代码的作用是把协议问题结构化地丢给模型，让它按"寄存器 + 跳转条件"的格式回答，避免泛泛而谈。实测下来，把lspci -vvv里 Link Status、Link Control 2、Lane Equalization Control 这几段贴进去一起问，模型能帮你把当前链路卡在哪个子状态推断得比较准。

3. Recovery 状态机的完整流转拆解

3.1 从 Detect 到 L0 再到 Recovery 的触发链

LTSSM 上电后从 Detect 开始，依次经过 Polling、Configuration，最终进入 L0。L0 是正常工作态，但链路并不会一直待在这里。以下情况会把链路从 L0 拉回 Recovery：

一是速率切换请求。当上层软件写 Link Control 2 寄存器的 Target Link Speed 字段，或者硬件发起 directed_speed_change，链路会进入 Recovery 去重新协商速率。二是位锁或符号锁丢失。接收端检测到连续错误、block alignment 失败，会触发 Recovery 重新建立同步。三是电气空闲退出异常。从 L1、L0s 退出时如果同步没建立好，也会走 Recovery。四是均衡重做。DSP 在上层要求下发送 EC 不为 0 的 TS1，请求重新做 equalization。

Recovery 内部不是一个状态，而是一组子状态：Recovery.RcvrLock、Recovery.RcvrCfg、Recovery.Equalization、Recovery.Speed、Recovery.Idle。进入 Recovery 后先到 RcvrLock，然后根据条件分流。

3.2 Recovery.RcvrLock 的判据与跳转

RcvrLock 的核心任务是重新获得 bit lock 和 symbol/block alignment。在 8.0GT/s 及以上速率时，接收端只认 block alignment 之后收到的 TS0、TS1、TS2。如果是从 L1 或 Recovery.Speed 进入，block alignment 必须在退出 Electrical Idle 之后完成；如果是从 L0 进入，则要在最后一个 data stream 结束之后完成。

跳转到 RcvrCfg 的条件是：双方收到 8 个连续的 TS1 或 TS2，其中 link number 和 lane number 与本地发送一致，speed_change 比特与本地 directed_speed_change 一致，EC 域为 00b，且当前速率是 8.0GT/s 或更高。如果设置了 Extended Synch 比特，进入 RcvrCfg 前至少要发 1024 个连续 TS1。

跳转到 Recovery.Speed 的条件有两个：一是当前速率高于 2.5GT/s，但进入 Recovery 后从未在该速率下正常工作过（changed_speed_recovery 为 0），此时离开 Speed 后会降回 2.5GT/s；二是 changed_speed_recovery 为 1，表示高速率曾工作过但切到新协商速率后失败，此时速率恢复为进入 Recovery 前的值。

跳转到 Configuration 的条件是：没有发起速率改变（directed_speed_change 为 0 且 TS1/2 中 speed_change 为 0），任一配置 lane 上收到至少一个 TS1/TS2，且 link num、lane num 与本地发送一致；或者双方协商后最高公共速率只有 2.5GT/s。

跳转到 Recovery.Equalization 的条件是：USP 收到 8 个连续 TS1，link/lane num 一致，speed_change 为 0 但 EC 域不为零，说明 DSP 希望重做部分均衡流程。注意 DSP 不能从 Configuration.Idle 或 Recovery.Idle 直接进 Equalization，必须经过 RcvrLock。

24ms 超时后，如果上述条件都没满足，跳转到 Detect。

3.3 Recovery.Speed 的电气空闲与速率决策

进入 Recovery.Speed 后，tx 先进入 Electrical Idle，等待 rx 也进入，然后等待额外时间：successful_speed_negotiation 为 1 时至少等 800ns，为 0 时至少等 6us，但都不超过 1ms。

退出 Electrical Idle 后回到 RcvrLock，新速率按以下规则确定：如果是从 RcvrCfg 进入且两侧切速成功（successful_speed_negotiation=1），新速率是配置 lane 上协商的最高公共速率，changed_speed_recovery 置 1；如果没有成功切速且这是从 L0/L1 进入 Recovery 后第二次进 Speed（changed_speed_recovery=1），速率回到最初进入 Recovery 时的值，changed_speed_recovery 清 0；其他情况新速率为 2.5GT/s，changed_speed_recovery 清 0。48ms 超时后进 Detect。

3.4 Recovery.Idle 的退出路径

Recovery.Idle 有两个出口。回 Configuration：任一配置 lane 上收到两个连续 TS1 且 lane num 为 PAD。回 L0：8b/10b 编码下，所有配置 lane 收到 8 个连续 Idle symbol 且已发送 16 个 Idle symbol；128b/130b 编码下条件类似，但要求当前状态不是从 RcvrCfg 因超时进入。8.0GT/s 时 tx 发 SDS 开启 data stream 再发 idle symbol，16GT/s 及以上在 SDS 后发 SKP 再发 idle symbol。2ms 超时后，如果 idle_to_rlock_transitioned 小于 0xFF 则回 RcvrLock，否则进 Detect。

4. 可复制的状态机配置骨架与寄存器验证

4.1 关键寄存器清单

调试 Recovery 时，下面这几个寄存器是必看的。Link Control 2 里的 Target Link Speed 决定协商目标速率，Enter Compliance、Hardware Autonomous Speed Disable 影响速率切换行为。Link Control 3 的 Perform Equalization 位决定是否进 Equalization。Lane Equalization Control Register Entry 里存着各 lane 的 Downstream Port Transmitter Preset 和 preset hint。Link Status 寄存器的 Link Bandwidth Management Status 和 Link Autonomous Bandwidth Status 反映带宽变化来源。

# 查看链路当前速率和宽度 lspci -vvv -s 01:00.0 | grep -E "LnkCap|LnkSta|LnkCtl2|LnkCtl3" # 读取 Link Control 2 寄存器（偏移 0x30） setpci -s 01:00.0 CAP_EXP+0x30.w # 读取 Link Control 3 寄存器（偏移 0x34） setpci -s 01:00.0 CAP_EXP+0x34.w # 读取 Link Status 寄存器（偏移 0x12） setpci -s 01:00.0 CAP_EXP+0x12.w

4.2 状态机配置骨架

下面这段伪代码把 Recovery 的跳转条件整理成可对照的骨架，你可以按实际实现填充寄存器读写。

typedef enum { REC_RCVRLOCK, REC_RCVRCFG, REC_EQUALIZATION, REC_SPEED, REC_IDLE, } recovery_substate_t; typedef struct { int directed_speed_change; int changed_speed_recovery; int successful_speed_negotiation; int start_equalization_w_preset; int idle_to_rlock_transitioned; uint8_t current_speed; // 1=2.5G, 2=5G, 3=8G, 4=16G, 5=32G, 6=64G } ltssm_ctx_t; recovery_substate_t recovery_next(ltssm_ctx_t *ctx, ts_recv_t *ts) { switch (ctx->substate) { case REC_RCVRLOCK: if (ts->count >= 8 && ts->link_lane_match && ts->speed_change == ctx->directed_speed_change && ts->ec == 0x00 && ctx->current_speed >= SPEED_8G) { return REC_RCVRCFG; } if (ts->count >= 8 && ts->link_lane_match && ts->speed_change == 0 && ts->ec != 0x00) { return REC_EQUALIZATION; } if (ctx->current_speed > SPEED_2P5G && !ctx->changed_speed_recovery) { return REC_SPEED; } if (timeout_24ms()) return DETECT; return REC_RCVRLOCK; case REC_SPEED: if (electrical_idle_exit_done(ctx)) { if (ctx->successful_speed_negotiation) { ctx->changed_speed_recovery = 1; ctx->current_speed = negotiated_max_speed(); } else if (ctx->changed_speed_recovery) { ctx->current_speed = speed_before_recovery; ctx->changed_speed_recovery = 0; } else { ctx->current_speed = SPEED_2P5G; ctx->changed_speed_recovery = 0; } return REC_RCVRLOCK; } if (timeout_48ms()) return DETECT; return REC_SPEED; case REC_IDLE: if (ts->count >= 2 && ts->lane_num == PAD) return CONFIGURATION; if (idle_symbols_ok(ctx)) return L0; if (timeout_2ms()) { if (ctx->idle_to_rlock_transitioned < 0xFF) { ctx->idle_to_rlock_transitioned++; return REC_RCVRLOCK; } return DETECT; } return REC_IDLE; default: return ctx->substate; } }

4.3 验证动作

配置完成后，用下面的步骤确认链路是否按预期流转。先确认当前速率和宽度，再读 Link Control 2 看 Target Link Speed 是否设为目标值，然后读 Link Control 3 确认 Perform Equalization 位。如果链路反复重训，重点看 Link Status 的 Link Bandwidth Management Status 是否被置位，以及 dmesg 里是否有 "Link training failed" 或 "Speed change failed" 的记录。

# 确认当前链路状态 lspci -vvv -s 01:00.0 | grep -A2 "LnkSta:" # 触发一次速率切换（写 Target Link Speed 为 16GT/s） setpci -s 01:00.0 CAP_EXP+0x30.w=0x0002 # 观察 dmesg 中的链路训练日志 dmesg -w | grep -iE "pcie|link|ltssm"

5. 本篇常见错排查

链路卡在 Recovery.RcvrLock 不跳转。先确认收到的 TS1/TS2 里 link number 和 lane number 是否与本地发送一致。如果 lane num 不匹配，通常是配置阶段 lane 映射错了，检查 Configuration 阶段的 lane 分配。如果 EC 域一直不为 0，说明对端在请求均衡，需要看 Perform Equalization 位和 Lane Equalization Control 寄存器。

速率协商后掉回 2.5GT/s。这通常是 changed_speed_recovery 为 0 且高速率从未工作过，链路在 Recovery.Speed 里降速。检查信号完整性，尤其是 8GT/s 以上的均衡参数是否收敛。如果是从 RcvrCfg 进入 Speed 且 successful_speed_negotiation 为 0，说明两侧没有协商出公共速率，检查双方支持的速率集合。

Recovery.Idle 超时进 Detect。看 idle_to_rlock_transitioned 是否达到 0xFF。如果每次进 RcvrLock 都加 1，说明链路反复在 Idle 和 RcvrLock 之间震荡，通常是电气空闲退出时序或 common mode 电压没稳定。DSP 需要做 timer，确保检测到 Electrical Idle exit 后达到最小 TCOMMONMODE 值再发 TS1。

Link Bandwidth Management Status 被置位。说明带宽变化不是 DSP 自主发起的，而是上层软件或链路可靠性问题导致。对比 Link Autonomous Bandwidth Status，如果后者为 1 且 speed change 由 DSP 发起，则是自主带宽变化。

6. 把调试流程固化下来

Recovery 状态机的调试本质上是在回答"链路为什么进 Recovery、走了哪条路径、为什么没回到 L0"。把上面这套寄存器读取和状态跳转判据做成脚本，每次 bring-up 时自动跑一遍，比手动翻协议快得多。如果你想把日志解析和状态推断做成长期可用的工具，可以用 Coding Plan 把模型对话能力接进你的调试脚本，让它按寄存器名和跳转条件输出结构化结论。API Key 在 https://taotoken.net/api 的 api-keys 页面管理，接入方式参考 https://taotoken.net/api 的 doc 页面。模型对话入口适合快速查协议条款，Coding Plan 适合把状态机解析逻辑沉淀成可复用的代码。