我们Saniffer公众号前面几年经常提到业内碰到的SSD掉盘的问题，有些影响面和波及面非常广，各种各样的问题，这其中有些我们通过PCIe协议分析仪串在链路中间抓取双向流量进行分析得到原因，有些则通过一些工具主动“激发”出问题从而推测出问题的所在。我们今天在这里总结一下SSD掉盘到底有哪些原因，还有哪些原因是工程师不怎么想得到的。

什么是“掉盘”？

“掉盘”在工程上几乎从来都不是一个单点故障名词。它通常是控制器固件、PCIe/NVMe 协议状态机、低功耗链路状态、热插拔/复位时序、供电完整性、背板或 retimer、中间管理通道，以及 BIOS/OS 驱动策略共同作用后的外在现象。NVM Express 规范明确给出了 APST、Keep Alive、CSTS.CFS 等机制；Linux 内核与 微软 StorNVMe 文档又说明了主机侧是如何参与这些状态转移的。这意味着：很多“盘坏了”的现场，根因其实并不在 NAND（当然，如果真的是NAND Flash坏了，我们可以通过NplusT公司的NanoCycler做一些失效和特性分析），而在盘能不能被重新枚举、能不能按预期退出低功耗、能不能在异常电源与复位序列下完成链路训练。

公开案例显示，掉盘高发的根因并不神秘，反而很集中：深度低功耗/APST 唤醒失败、电压处理/电源时序缺陷、背板/retimer/sideband 通讯异常、控制器/HBA 固件异常或异常恢复路径不健壮、平台 BIOS/驱动与 SSD 固件组合不匹配。从 戴尔 的 Micron 2200S “No Drive Detected/STOP Error”，到 联想 的 Kioxia BG5 永久不可见，再到 慧与 UBM6 背板“Removed/Inserted”抖动，以及 思科 对 NVMe/SATA SSD“improper voltage handling”的现场通报，模式都非常一致：先掉枚举，再谈介质。

真正被 99% 团队忽略的，不是“有没有升级过 firmware”，而是有没有把协议、sideband、功耗、拓扑、管理面日志在同一时间轴上对齐。单看 SMART 不够，单跑 fio 不够，单盯协议抓包也不够。最短诊断路径通常是：协议抓包 + sideband 采样 + 电源扰动复现 + 主动工作负载四线并举。以 SerialTek、Quarch、SanBlaze、Serial Cables 这四类工具组合为例，已经足以把绝大多数掉盘问题压缩到某一层：协议、链路、供电、热插拔、还是平台软件。

可以先记住五个结论。其一，低功耗最危险：APST、ASPM L1/L1.2、CLKREQ#、PERST#、WAKE# 的组合，是最容易被误判为“随机坏盘”的区域。其二，热插拔不是插上能认盘就算过：必须在 I/O 压力、管理面轮询、固件升级、异常掉电与 retimer/backplane 参与时验证。其三，控制器异常恢复路径必须当正式功能测试，而不是靠线上用户替你回归。其四，上线前测试一定要覆盖真实拓扑，包括 M.2、U.2/U.3、EDSFF、直连、经 switch、经 retimer、单口/双口。其五，生产监控必须先盯“枚举与链路健康”，再盯温度与 SMART。

说明：本文提到的相关产品均来源于网络公开信息。

掉盘真正发生在哪里

把 SSD 掉盘拆开看，本质上是在问：它死在了哪一层。NVMe 规范说明，主机可以通过 APST 让控制器自动转入非工作电源状态；如果控制器在唤醒时不能按它自己宣称的延迟返回，主机就会把它视为超时、失联或需要 reset。规范还明确写到：Keep Alive Timer 过期会记录 Error Information Log，并把 CSTS.CFS 置位；而 CSTS.CFS 代表严重错误，主机应尝试 Controller Reset，如果再不清，再考虑更激进的 NVM Subsystem Reset。更麻烦的是，规范同时警告：Subsystem Reset 可能导致 PCIe 链路掉下去，一些 OS 或 hypervisor 甚至会因此崩。

这也是为什么“低功耗掉盘”如此隐蔽。金士顿 A2000、Solidigm P44 Pro，以及中国市场常见的京东上可以买到的某款M.2 SSD，公开内核修复都直指最深电源状态退出失败：盘在最深 sleep state 之后变得 whole disk unresponsive，修复方法不是换 NAND，而是先禁止最深 power state或更新固件/内核 quirk。换言之，工程上首先要怀疑的是ENLAT/EXLAT 报告、APST 配置、L1/L1.2 sideband 协议、以及 PERST#/CLKREQ#/WAKE# 时序，而不是先宣判“闪存寿命完了”。

主机侧同样是因子，而不是背景板。StorNVMe 文档明确说明，Windows 会根据 ENLAT+EXLAT 与当前容忍延迟来挑最深可接受 power state；微软给现代待机场景的建议甚至明确到：StorNVMe 不支持 APST enabled 的设备用于 Modern Standby。Linux 则把 ASPM 的 L0s/L1/L1.1/L1.2 暴露成 sysfs 开关，并提供 per-device reset/remove/rescan 接口用于排障。这说明：同一块 SSD 在 A 平台不掉、在 B 平台掉，并不奇怪；主机 BIOS、ACPI、电源策略、驱动与内核 quirk 会直接改变你看到的现场。

更容易被忽略的是“盘外掉盘”。联想公开的控制器/适配器变更记录里，直接写过“NVMe drive missing after few Lane/Phy glitches between PCIe switch downstream port and Endpoint”“drive missing status even when drive is present”“FW exception during reboot of a server with PCIe gen5”“heavy IO + NVMe passthru from OOB after 5–8 hrs hit KA”这类问题。也就是说，盘从 OS 视角消失，根因可以在switch、retimer、HBA/RAID FW、OOB 管理、MCTP/NVMe-MI 通道，甚至恢复路径本身。把掉盘只当 SSD 介质问题，是许多团队的第一层误判。

下面这张图，是本文建议的分层思维框架。它不是规范原图，而是对公开案例和工具链能力的工程抽象。

全球真实案例库

公开证据主要来自 镁光、英睿达、铠侠、三星 等 SSD/存储厂商，和 戴尔、联想、惠普、思科 等平台/OEM 的官方支持公告；下表还补充了开源内核公开修复记录。需要坦诚说明的是：绝大多数公开案例不会披露厂内实验室到底用了哪台仪器。因此，表中的“诊断工具”分成两层：公开诊断线索与建议复盘工具。后者是基于故障机理给出的最佳最短路径，不代表厂商公开确认使用过这些品牌设备。

除了表中的“显性掉盘”，还要特别留意那些还没真正消失、但已经在边缘的征兆。较新的公开发布件里，Solidigm P44 Pro 被 Linux 内核加入 “NODEEPESTPS” quirk；联想控制器变更记录则记载了“lane/phy glitch 后 drive missing”“MCTP request failed with drive missing status even when drive is present”“PCIe gen5 reboot 时 FW Exception”“bad Phy/链路降速”等问题；戴尔某些企业 NVMe 固件发布说明则把“thermal shutdown behavior”“PERST handling”“invalid command handling”“OOB command during shutdown”列为修复项。这些都说明：掉盘不是突发事件，而是很多边缘征兆长期未被监控后的最终形态。

工具化诊断流程

工作流一：怀疑 APST、ASPM L1/L1.2、resume/idle-wake 导致的间歇性掉盘。第一步，不要一上来“更新到最新再看”，而是先冻结现场：记录 BIOS、SSD FW、OS、驱动/内核、ACPI/电源计划、是否启用 Modern Standby、当前 ASPM/L1.1/L1.2 配置。第二步，用 SerialTek 在“进入空闲—触发唤醒—重新训练—掉盘/恢复”的窗口抓LTSSM、DLLP/TLP、Config Space 历史变化；Quarch 同步抓电源轨迹与 sideband，重点盯 CLKREQ#、 PERST#、 WAKE#、SMBus/NVMe-MI 活动。第三步，分别做 A/B 试验：关闭最深 APST、限制 power-state latency、关闭可疑 L1.x、再与原始配置对照。如果关掉最深 PS 后现象消失，你就基本锁定了“盘或平台在低功耗退出路径上不成立”，而不是“盘体随机坏”。

工作流二：怀疑热插拔、背板、retimer、switch 或 sideband 交互。第一步，把问题从“某台机器偶发掉盘”重构成“某个拓扑下可复现的枚举失效”：直连、经 retimer、经 switch、不同槽位、不同线缆/背板、不同双口/单口配置都要分开。第二步，用 Serial Cables 的测试底座把每槽上电顺序、presence、热插拔、slot telemetry、NVMe-MI/MCTP纳入自动化矩阵；Hydra 一类平台本身就支持 per-slot power sequencing、hot-plug simulation、温度与功耗遥测、NVMe-MI/MCTP 访问。第三步，用 Quarch 做brownout、glitch、ramp、fault injection、pin timing 复现；如果问题只在“高 I/O + 热插拔”“高 I/O + OOB 轮询”“重启 + firmware flash”“功率波动 + presence bounce”这几种组合下出现，那么根因多半已不在纯协议层，而在协议层与平台电源/sideband/拓扑的交界面。

工作流三：怀疑控制器固件 assert、exception handling 或 OOB/Keep Alive 路径。第一步，用 SanBlaze 主动加载工作负载，而不是只等用户业务复现。它的 PCIe Gen5 RM5/DT5 平台本身就具备read/write/compare、error injection、custom opcode、NVMe-MI over SMBus、power on/off、hot-plug 与 drive presence under software control、per-drive voltage/power measurement能力，适合把“边干活边出错”的路径系统化复现。第二步，把前台 I/O 与后台管理动作用矩阵化方式并发：命名空间操作、Firmware Download、sanitize、NVMe-MI 轮询、日志抓取、OOB passthrough。第三步，SerialTek 负责看哪一拍开始偏离规范，Quarch 负责看那一拍前后有没有 rail、reset、sideband 异常，SanBlaze 负责保证故障并不是随机流量造成的偶然现象。第四步，一旦怀疑进入 CSTS.CFS 或 Keep Alive 失效，恢复梯度要保守：先 Controller Reset，再评估是否值得做更激进的 NVM Subsystem Reset；不要把 NSSR 当成通用治疗手段，因为规范已经明确说过它可能让 PCIe links go down，并对某些 OS/hypervisor 造成不良影响。

最有价值的采集物不是更多日志，而是更好的时间轴。建议所有实验都固定输出同一套证据包： SSD FW、 BIOS/driver/kernel、 IdentifyControllerpower-state table、 AER/PCIeerror、 NVMeerror log、 OOB logs、 SerialTek PCIe trace、 Quarchpower+sideband、 SanBlazeworkload script、 SerialCablesslot topology。如果一轮实验结束后，你还不能回答“先掉的是链路、还是电源、还是侧带、还是主机先 reset 了盘”，那就说明这轮实验设计得还不够好。

预部署测试计划

现实中最贵的掉盘，不是实验室重现不了的那个，而是根本没被纳入预部署验证矩阵的那个。公开资料已经足够说明这件事：SanBlaze 的 NVMe 平台面向 development、QA、qualification、manufacturing test；支持 NVMe-MI、conformance、error injection、power control、per-drive measurement；Quarch 提供 margining、power loss、brownout、glitch、sideband capture；Serial Cables 提供多槽位、热插拔、每槽供电与 NVMe-MI/MCTP；SerialTek 则负责把 LTSSM/TLP/DLLP/config 变化一次抓全。把这四者组合起来，已经能覆盖大多数“上线前就该发现”的问题类型。

要特别强调三条实施原则。第一，用真实拓扑做测试，不要只在开发板或直连 AIC 上测完就宣布通过。第二，把管理面流量当成工作负载的一部分，因为 MCTP/NVMe-MI/OOB 与前台 I/O 并发时，恰恰最容易把边界状态打出来。第三，把固件升级路径当成一级功能测试；公开案例已经反复证明，很多掉盘并不是业务负载首发，而是升级、重启、resume 或 power-cycle 首发。

如果团队需要一个最小可执行配置，我建议是：一台 Serial Cables 多槽测试底座（例如Gen5 switch卡） + 一套 Quarch PAM/PPM/热插拔模块 + 一台 SanBlaze RM5/DT5 + 一台 SerialTek 协议分析仪。这样你能同时做真实主机下的枚举、工作负载、power margining、热插拔、NVMe-MI/MCTP、以及协议/sideband/功耗三线对齐。对于企业盘，若涉及双口、U.2/U.3、EDSFF、OOB 管理与 OCP 规范，则应继续把 UNH-IOL 和 Open Compute Project 的测试思路纳入脚本与验收口径。

修复、监控与行动建议

修复掉盘，最忌讳“统一关掉所有低功耗、省事就行”。这只能暂时把问题藏起来，却不能告诉你是谁在低功耗退出时失配。更正确的做法是分层修。协议/固件层，修 ENLAT/EXLAT 报告、修 APST/Keep Alive/reset state machine、修 invalid command/OOB/shutdown 处理、修 thermal shutdown 行为；公开发布件已经反复把这些列为正式修复项。平台软件层，把 BIOS、驱动/IRTS/StorNVMe 或内核 quirk 与 SSD FW 做成套验证，不要相信“只刷盘固件就够”。热插拔与背板层，校正 presence debounce、retimer FW、OOB 管理路径以及 reset sequencing。供电层，对 brownout、rail droop、ramp 与 power-chirp 做边界收敛，而不是仅测 steady-state 功耗。

对机械与装配问题，我建议比大多数团队更保守。若故障与特定槽位、温区、弯折、插拔次数、运输/振动、按压动作强相关，就要把 U.2/M.2/EDSFF 连接器接触与焊点当成一等嫌疑。电子封装与焊点可靠性研究早已确认，热循环和机械应力会显著影响焊点微结构与疲劳寿命；而平台发行说明里也不断出现 lane/phy glitches、bad phy、drive present 但被上层判断 missing、链路降速后异常等征兆。工程上应把 AOI、X-ray、温循前后复测、槽位轮转与链路余量问题并行推进，而不是等软件团队“继续跟一版 firmware 试试”。

推荐修复动作可以压缩成一个简表：

生产监控上，不要只看 SMART。最有效的告警体系，应该先覆盖“有没有开始丢枚举”。Cisco 与 HPE 的公开案例都表明，带外管理面往往比 OS 更早看到 inoperable、 removed、 inserted、 missing；Linux 文档则说明了链路电源状态、ASPM 开关、reset/rescan 等都可被纳入平台可观测面。建议把下面这些对象放进生产告警与值班剧本里。

最后，建议把“协议、sideband、功耗、拓扑”这四条证据链，变成平时SSD掉盘的标准排障模板。 只靠替换硬件，你会在同一类故障上反复交学费；只靠改一版 firmware，你会在线上把另一个边界条件放出来。真正能把掉盘率打下来的团队，靠的不是运气，而是复现实验设计。对经常看我们公众号的朋友来说，Saniffer 已公开过一批很有价值的中文资料：包括 Quarch 的 NVMe 热插拔/电压拉偏/功耗测试讲座、PCIe Gen4/5/6 协议分析讲座，以及 SanBlaze NVMe 测试平台介绍，想把本文变成日常SSD失效分析/掉盘培训的一个素材，请关注微信公众号 Saniffer。

链接: https://pan.baidu.com/s/1R-tJEqwBlzBaDR0WLuMU0Q?pwd=9av3 提取码: 9av3

如果你有其任何关于PCIe5&6.0, CXL, NVMe/NVMoF, NAND, DDR5/LPDDR5以及UFS测试方面的我问题想咨询，请访问：访问www.saniffer.cn / www.saniffer.com 访问我们的相关测试工具和产品；或者添加点击左下角“阅读原文”留言，或者saniffer公众号留言，致电021-50807071 / 13127856862，sales@saniffer.com。