可信复现首轮：真实FTP生产路径177轮全过（SHA-256全匹配）+并发UI 600帧，未复现冻结

2026-09-23 01:06:19 +08:00
parent 685a860635
commit 0e6efb44a3
2 changed files with 3 additions and 0 deletions
@@ -547,6 +547,7 @@ NET 层 TCP Client（阶段 7）`net_connect()` 返回 0，但 `net_poll()` 报
 > 5. **仍然成立的部分**：E 系列（Phase 6-only，排空间隔 10/20/40/60ms，标准 `tcp_client` 序列）40/40 通过（脚本层逐步匹配）；"芯片 RX 读是否必须读空"**未被任何有效台架证伪或证实**。
 > 6. **现场 TC-NET-604 冻结仍未解释**：需以可信工具重新复现——判读一律用 `MDK-ARM/bench_verdict.py`（脚本层 STEP 为真值，并扣除固件读者吞噬的字节），`probe_classify.py` 仅作参考；台架配方必须避免"固件内非回显读者"（Phase 9/11、探针）与 PC 侧期望值混用。
 > 7. 相关代码：本轮 N-7 原型（net 层"读必读空"+ 共用中转槽，+3KB）**未提交**，仅存设计；在机理确认前不落地（见 `docs/待处理内容.md` N-7 撤回标注）。
+> 8. **可信复现首轮（2026-09-23）**：改用**真实生产路径**——产品固件（无测试套件、**无任何固件探针**）+ 真 lftpd FTP 上传，判据 = FTP 协议结果 + **上传后 RETR 下载比对 SHA-256**（内容真值）+ 卡住时用**控制通道 NOOP** 区分"数据 socket 卡死 vs 整层卡死"（工具 `MDK-ARM/ftp_freeze_probe.py`，判据天生免疫"固件读者吞数据"假象）。结果：**177 轮全过**（8KB×10、64KB×10/20/100、256KB×5、1MB×2；含零间隔快速重连与 100 轮浸泡），SHA-256 全匹配；并发 UI 流（`:7003`，600 帧）CRC 600/0 全过；设备侧日志无 FAIL/ERROR/WARN（仅每轮数据 socket 正常 `auto-relisten ok`）。→ **当前固件在该组条件下未复现现场冻结**；现场现象是否已被 2026-09-20 起的一系列修复（Trap 09 重监听重试 / L3 pending 化 / D20 / 自动重监听）顺带消除，或需更极端的客户端行为，待进一步验证。

 ### 现象
 单条 TCP 连接在传输中途**静默单向死亡**：设备侧回显/应答流戛然而止（PC 侧 0 字节），连接不 RST（两侧均保持 ESTABLISHED）、无芯片断开事件；**芯片接收路径仍然健康**（2026-09-22 精确定位轮实证：冻结后继续到达的数据芯片照常接收、MCU 照常排空，命令流节奏完整），**芯片发送路径永久死亡**（已写入的发送数据不出线——SPI 写被芯片接受但线上无任何段；ACK/窗口更新随之停止）→ 对端剩余数据滞留**对端发送缓冲**（窗口视图冻结在 0，对端"重传"实为等窗口的空等，10s 无效）。对端断开重连（新 Socket）后恢复正常。2026-09-22 精确定位轮最小复现：64×10 + 1460B 填充 + **1024B 部分排空**（C/C0 配方，Phase 6-only 构建、零第二命令，10/10）；原三因子配方（F1 组合 + 4096B 超容突发）10/10 维持。