枚举超时到底是个什么鬼？
先说定义。枚举超时，就是 USB 设备在连接后，主机给它发的一系列设备描述符请求、配置描述符请求，在规定时间内没有得到正确回应。说白了，设备跟主机「握手」握到一半，设备没反应了，或者回的数据不对，主机就认为这次枚举失败了。
我刚开始调 USB 驱动那会儿，遇到枚举超时，第一反应就是拔插重试。后来发现，这事远没那么简单。超时背后埋着不少雷。你想想看，USB 3.0 的枚举过程本来就比 2.0 复杂——它要多跑一个链路训练、还要交换 5Gbps 的信号。任何一个环节出问题，超时就来了。
操作系统那边的报错码
不同操作系统对枚举超时的处理方式不一样，但都会扔一个错误码出来。我记得第一次在 Windows 设备管理器里看到「代码 43」时，满脑子都是问号。后来才搞清楚，这些错误码就像设备的「病历号」，每一条都能帮你锁定病因。
| 操作系统 | 常见错误码/提示 | 含义 |
|---|---|---|
| Windows | 代码 10 (无法启动) | 设备没有在超时时间内返回描述符，驱动认为设备不可用 |
| Windows | 代码 43 (无法识别) | 枚举超时或设备返回了无效数据，驱动干脆停掉这个设备 |
| Linux | -110 (ETIMEDOUT) |
USB 核心层等待设备响应超时，会触发复位然后重试 |
| Linux | -71 (EPROTO) |
协议错误，通常伴随超时一起出现 |
| macOS | IOUSBDevice 超时日志 | IOKit 会记录「timed out while getting descriptor」 |
dmesg | tail -20 看内核日志，错误码和 USB 事件全都有。用熟了之后，看一眼报错就能判断大概方向。
设备无法识别——用户的直接体感
枚举超时最直观的结果就是：设备在系统里不出现。无论是 U 盘、摄像头还是调试器，插上之后一点反应都没有。
- 从用户角度看：插拔没反应，甚至没听到那个「叮咚」的提示音。
- 从驱动角度看：设备节点没创建，或者创建后立刻被移除。
- 从硬件角度看：可能是 D+ / D- 上拉电阻没配置对，导致主机根本检测不到设备连接。
我在项目中遇到过一台工业相机，插到 Windows 上偶尔能认、偶尔认不到。一开始怀疑是线缆的问题，换了根新的还是老样子。后来用分析仪抓波形才发现，是相机的 STREAM 使能信号上太快，在枚举还没完成时就抢占了总线……这属于设备端固件的时序问题，但表面现象就是「设备无法识别」。
系统挂起——最严重的一类
大部分枚举超时不会导致系统崩溃，但有一种情况特别恶心：USB 主控制器（xHCI）死锁。当超时反复发生，且设备固件或者驱动对异常状态处理不当，就可能把整个 USB 子系统拖死，然后引发系统级 hang。
我曾经在一台笔记本上调试一个 USB 3.0 集线器，集线器下游接了个不稳定设备。每次插拔那个设备，集线器就报枚举超时，然后笔记本的触控板（也是 USB 的）也跟着失效了。最后连键盘都卡住，只能按电源键强关。
为什么一个 USB 端口超时能把整个系统干掉？因为 xHCI 控制器要处理很多命令环（command ring）和事件环（event ring），如果某个命令永远不完成，事件环被堵死，其他端口的传输就没法正常调度。说白了，就是一条链上卡了个死结。
看到这张图，你应该能明白：枚举超时不是一个单一的故障表现，而是一个链条。最轻的是报个错误码，重则设备认不到，最极端就是整个系统僵住。
枚举超时的时间阈值
这里还有个知识点：枚举超时的时间阈值是多少？USB 规范里写死了——
- 设备号超时：主机发出 SET_ADDRESS 后，等待设备完成地址变更的时间不得超过 2ms。
- 描述符请求超时：主机发出 GET_DESCRIPTOR 后，设备必须在 5s 内完成响应。
- 重置后恢复超时：USB 3.0 在链路复位后，设备要在 12ms 内开始发送 TS1 序列。
嗯，这些数字你记得住最好，记不住也没关系。但有一条你要清楚：主机端的超时时间通常是可配置的，驱动层会留余量。而设备端的固件必须严格遵守规范，否则就会触发主机端的超时。
我调过一款 USB 3.0 摄像头，它读内部 EEPROM 慢了一点，结果 GET_DESCRIPTOR 偶尔回得超过 5s。Windows 那边直接报代码 10，Linux 报 -110。后来我们在固件里加了个预加载机制，让描述符在枚举之前就准备好，问题就解决了。你看，查清楚时间阈值，就能定位到固件到底慢在哪儿。
小结一下
枚举超时的三类影响：错误码、设备不认、系统挂起。它们往往是同一个根因的不同表现形式。我建议大家熟记常见错误码，理解超时阈值，更重要的是——遇到系统挂起时，先不要慌着清驱动，先拔可疑设备。这条原则帮我省了不少重装系统的时间。