correct the record: the 2026-08-10 boot wedges were the USB-serial adapter hanging an unbounded overlapped write, NOT print-deadlock (confounded A/B, retracted); pod runbook gets the full COM1/FTDI diagnosis + remote minidump procedure

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

context/pod-hardware.md

@@ -510,6 +510,27 @@ trailing-space payload) or use PowerShell `Add-Content`. Bit us arming BT_GLASS_
 `Expand-Archive` → podkit → `schtasks /run` came up clean on the first try — rig config survived,
 newest-install auto-resolve worked, no hand-edits. The cab genuinely upgrades like a tester box.
 
+**9a. ⚠ THE RIO's "COM1" IS A USB-SERIAL ADAPTER — the axis-dropout / frozen-boot fault
+(2026-08-10, minidump-proven) [T1].** `\Device\VCP0` = an FTDI adapter (FTE7PGA5A); COM2 is a
+second FTDI (A995JTOYA); **two ghost Prolific PL2303 entries also claim "COM1"** from earlier
+plug-ins (clean them in Device Manager). When the adapter's **USB side** drops mid-operation:
+brief drop = analog polls go mute (the field "encoder dropouts", revived by hand-jostle /
+re-enumeration — NOT by button protocol); drop with a write in flight = the 1995 code's
+**unbounded `GetOverlappedResult` wait in `PCSerialPacket::SendPacket` parked the whole game at
+0 CPU forever** (three boots on 2026-08-10; stack: NtWaitForSingleObject ← GetOverlappedResult ←
+SendPacket ← RIO ctor). **Hardened in 4.11.881**: 500 ms bounded write + CancelIo + 3 s sick
+window (fast-drop, game keeps frame rate, keyboard fallback lives); `txTO=` in the `[rio]` health
+line counts the events — proven the same evening (`txTO=1 rRetry=4` on a boot that SURVIVED).
+USB **selective suspend disabled** system-wide on the cab the same day (powercfg) — prime suspect
+for the random-period idle dropouts. Hardware to-do: FTDI adapter into a REAR motherboard USB
+port, reseat its USB end. ⚠ A first "print-deadlock" diagnosis of the boot wedge was WRONG
+(confounded A/B) and is retracted — the dump is the authority.
+**Remote minidump procedure (worked over SSH, no tools install):** 32-bit dump of the wedged pid
+via `C:\Windows\SysWOW64\rundll32.exe C:\Windows\SysWOW64\comsvcs.dll, MiniDump <pid>
+C:\bt411\w.dmp full` → scp home → local x86 cdb (`where.exe cdb` resolves the bt411-tools copy)
+with `-y C:\git\bt411\dist` (the archived per-build PDBs) → `~*k`. A 64-bit comsvcs dump of the
+WOW64 process shows only 64-bit frames — use the SysWOW64 pair.
+
 **9. ⚠ `schtasks /end` ORPHANS the game — the dead-RIO trap (2026-08-10):** `/end` kills the
 batch, but `runpod.bat` `start ""`s the exe DETACHED, so the old btl4.exe survives, keeps COM1
 open, and the NEXT launch boots with a dead cockpit board: `InitSerialPort() failed

engine/MUNGA_L4/L4GLASSWIN.cpp

@@ -2121,9 +2121,11 @@ static unsigned long
 	return token;
 }
 
-// [rio] health printer (L4RIO.cpp): the serial path may only COUNT --
-// printing from it deadlocks against the PCSPAK RX thread -- so the report
-// rides this tick, which already streams [glassperf] safely every second.
+// [rio] health printer (L4RIO.cpp): the serial poll path only COUNTS (kept
+// I/O-free by design; the 2026-08-10 wedges once blamed on prints there were
+// really the USB-serial adapter hanging an unbounded overlapped write --
+// see PCSerialPacket::SendPacket); the report rides this tick, which
+// already streams [glassperf] every second.
 extern "C" void BTRioHealthReport();
 
 void

engine/MUNGA_L4/L4RIO.cpp

@@ -1364,13 +1364,15 @@ Logical
 	Word		errors;
 
 	//
-	// [rio] link-health TRACKING -- pure arithmetic, no I/O.  ⚠ NEVER PRINT
-	// FROM THIS PATH: the first version DEBUG_STREAMed here and deadlocked
-	// the process against the PCSPAK RX thread within ~10 s of every
-	// live-RIO boot (2026-08-10 ALPHA-MR: 0-CPU park after "RIO successfully
-	// initialized", A/B-convicted by BT_RIO_LOG=0 booting clean).  The
-	// printer half is BTRioHealthReport() below, called from the glass tick
-	// beside [glassperf] -- a proven-safe stream site.
+	// [rio] link-health TRACKING -- pure arithmetic, no I/O here by design.
+	// CORRECTED HISTORY (2026-08-10): the boot wedges first blamed on prints
+	// from this path were actually the USB-serial adapter dropping its link
+	// with a write in flight -- the unbounded GetOverlappedResult in
+	// PCSerialPacket::SendPacket parked the game (minidump-proven; the
+	// print-deadlock A/B was confounded by the adapter behaving that boot).
+	// The count-here / print-from-the-glass-tick split stays anyway: it
+	// keeps this hot polled path I/O-free and the printer at one known
+	// stream site (BTRioHealthReport below, beside [glassperf]).
 	//
 	if (operational)
 	{