1 files changed, 23 insertions, 0 deletions

diff --git a/DEBUG_NOTES.md b/DEBUG_NOTES.md
index c9efdc1..b72a979 100644
--- a/DEBUG_NOTES.md
+++ b/DEBUG_NOTES.md
@@ -699,3 +699,26 @@ Follow-up hardening in the driver:
 - persistent bottom-row summary: per controller `64b=`/`leg=` handoff result,
   every connected port's PORTSC, and the HID device count — hardware runs
   without serial now show the whole picture, not just the first QR
+
+### OptiPlex — "dies at the prompt" (third run)
+
+Same QR (stage=1, PED=0), but now the machine never reaches the shell.  Two
+boot-time hazards, both introduced/exposed by the hardware diagnostics:
+
+1. **Count-based MMIO waits.**  `reset_port` polled PED for 2,000,000
+   iterations and the controller reset used 10,000,000-iteration loops.
+   On real silicon each iteration is an uncached MMIO read; with the new
+   reset retry that is seconds per port.  The boot-phase watchdog panics
+   when task 0 keeps a fixed stack frame for 750 ticks (7.5 s), and its
+   panic band is the only visible trace (serial carries the rest).
+2. **Automatic re-scan every second.**  While no HID was found the cursor
+   task re-ran the entire EHCI scan (including port resets), so a rate
+   matching hub never got a chance to settle.
+
+Fixes: all EHCI waits are wall-clock bounded (halt/reset/run 500 ms, PED
+200 ms, control transfer 500 ms), a per-controller 3 s port-scan budget, no
+automatic re-scan (hotplug is explicit via `usb rescan`), a 300 ms power-up
+settle, and the boot watchdog window raised to 20 s.  The xHCI controller
+also gets a persistent bottom-row summary.  QEMU `make test-usb` is green
+again (the 2 M-iteration PED poll had also eaten the 2 s scan budget and
+skipped the keyboard).