DF-5509 — decisive measurements (unpatched stock kernel), session of Oct 6 2026
===============================================================================

[probe mode 0, driver healthy]
ehciarm: ehci0 io_hdl=... io_size=0x1000 sc_offs=0x20 sc_eintrs=0x37 sc_noport=6
ehciarm: MMIO HCCPARAMS=0x6880 (EECP=0x68) USBCMD=0x10001 USBSTS=0x8 USBINTR=0x37
ehciarm: pre-init view: EOREAD4(EHCI_USBSTS) with sc_offs=0 -> reads MMIO+0x04 = 0x6 (HCSPARAMS, NOT status)
ehciarm: EECP chain[0] @0x68: 0x1 (ID=0x1 NEXT=0)  <== LEGSUP
  (QEMU implements writable LEGSUP BIOS_SEM/OS_SEM at config 0x68/0x6a/0x6b)

[dry run: BIOS_SEM=1, kldload ehci]
usbus0: waiting for BIOS to give up control
usbus0: timed out waiting for BIOS          <- 5s park inside ehci_pci_take_controller
-> attach completes normally afterwards (roothub enumerates)  [no pending intr state]

[PHASE 2 — end-to-end bounded storm, 100% stock driver]
arm: pre-arm USBCMD=0x80000 USBSTS=0x1000 USBINTR=0 -> ARMED USBINTR=0x3f, RS=1
     (stand-in for BIOS handoff residue: HC running, all 6 intr enables, BIOS_SEM=1)
kldload ehci -> "usbus0: waiting for BIOS to give up control" (park)
host monitor: device_add usb-kbd,id=k3,bus=ehci0.0,port=3   (single real port event)
baseline counter : ehci0  393106
after attach     : ehci0  704268      == DELTA 311,162 interrupts (≈60-100K/s)
guest: attach completes ("EHCI version 1.0", uhub0, ukbd0..2 enumerated), ssh alive
=> storm bounded by ehci_hcreset (ehci.c:335 via ehci_pci.c:451) — the FIRST
   code after the window that touches USBINTR/USBSTS.

[PHASE 3 — control, identical park, NO pending event]
counter before: 704268   after (park + 14s): 704323   == DELTA 55
=> 311,162 vs 55: single real port event in the armed pre-init window is a
   5,657x interrupt amplification on stock driver code.

[PHASE 4 — permanent variant: pre-init sc_eintrs injected on live driver]
ehciarm: ehci0 MUTED: sc_eintrs 0x37 -> 0 (exact pre-init M_ZERO value; sc_offs CORRECT 0x20)
host monitor: device_add usb-kbd,id=k4,bus=ehci0.0,port=4
  ehci0  1131077       (+~33K/s sustained)
  ehci0  1231156       (3s later; load average 3.60 and climbing; ssh still limps on 6 vCPUs)
  ... 14s total: ~900K interrupts, NO self-heal (nothing will ack; no hcreset coming)
kldunload ehciarm -> "ehciarm: ehci0 restored sc_eintrs=0x37"
  ehci0  1603736 -> 1605667 (2s) == storm STOPS DEAD once the handler can ack
  load averages: 0.00, 0.00, 0.00

[QEMU device-model notes]
- USBINTR writes do NOT re-evaluate the INTx line (hw/usb/hcd-ehci.c
  ehci_opreg_write USBINTR case); ehci_port_attach DOES raise PCD and
  re-evaluate immediately — so arming must precede the port event, exactly
  the BIOS-residue order.
- QEMU's ehci sets port-change PCD regardless of run state via
  ehci_raise_irq(PCD); the running-HC (RS=1) arm was kept to also cover
  the frame-timer path.
- Quirk: QEMU's LEGSUP dword drifted to NEXT=0x10 after the runs — that
  byte makes the next walk read config 0x10 (BAR0 dword 0xfebd1000 ->
  NEXT=0x10) forever: the KNOWN DF-1092/DF-2335 unbounded-chain class,
  re-confirmed accidentally. Cleared with pciconf before each run.