Kestrel (8852BU/8832CU): bimodal deaf RX bring-up — loop starts green, 0 frames until VBUS cold (sometimes)

[josephnef]

Symptom

On both Kestrel dies (8852BU TX20U Nano 35bc:0108, 8832CU TX50UH 35bc:0101), an RX bring-up sometimes completes fully green — tune OK, Kestrel: starting RX loop on chN, 8 async URBs submitted — yet zero frames arrive, including a known-good control TX and ambient traffic. init.timing shows demo.first_rx_frame never fires. The same binary + adapter delivers ~5 600 frames/15 s on the next bring-up.

Facts established (2026-07-16 bench session, during HE ER SU validation)

• Pre-existing, not a regression: reproduced on pristine master (f738cb9) with a bare rxdemo (git-stash bisect) — 0 frames, ch6.
• Bimodal per bring-up: probability of a deaf bring-up worsens with accumulated soft re-inits; a VBUS cold (uhubctl, hub 3-2.3) usually restores, but a fresh-from-cold bring-up can still come up deaf — it's per-bring-up roulette, not a pure retained-state latch.
• Affects both dies: the 8832CU was deaf standalone (35 s, 0 ambient) after a TX session; the 8852BU went deaf after ~5 RX bring-up cycles.
• The 8832CU additionally falls into ZeroCD (0bda:1a2b DISK, dmesg device firmware changed) after VBUS-cold + libusb_reset_device; another VBUS cycle flips it back to 35bc:0101.
• Kestrel coex: LTE interface not ready [E] appears twice per 8832CU bring-up in both working and deaf sessions — not the discriminator.
• TX side is unaffected in the same sessions (bulk-OUT drains, SDR shows 85 % duty).

Impact

Any per-cell RX harness reads false zeros. tests/he_er_su_cross_rx.sh works around it (control-cell gate + zero-cell retry with REGRESS_VBUS_MAP VBUS cold), and this trait is why several ER SU cells read 0 before the DUTs were cold-cycled.

Next steps

• Bisect where the deaf path diverges: RXAGG engine state? halbb gain-cache apply? A MAC RX-filter/RCR word that a prior session leaves latched? Diff a deaf vs healthy bring-up register dump (golden-diff the canary blocks).
• Check whether the vendor driver's bring-up on the same adapter is also bimodal (rules DUT hardware in/out — build/doctor + tests/adapter_doctor_cold.sh grading).
• Understand the LTE interface not ready error (B_AX_ENBT arming order) even if it isn't the discriminator.

Kaeru ref: kestrel-RX-bringup-bimodal-deafness-harness-trap-vbus-roulette-zerocd-0101.

🤖 Generated with Claude Code

[josephnef]

Root-caused. The "bimodal deaf bring-up" was two independent mechanisms, both now fixed:

1. Delivery-level deafness: RX-descriptor aggregate-walk break (fixed in #295)

The RX payload offset is rxd + shift*2 + drv_info_size*UNIT (+4 when mac_info_vld, non-PPDU-status) — and UNIT is 16 bytes on the 8852C vs 8 on the 8852B (vendor hal_trx_8852{b,c}). The old parser used the 8852B formula on both dies and ignored the shift/mac_info terms.

Why bimodal: whether the fw attaches phy-status (PPDU_STS sub-packets carrying drv_info) or mac_info to the RX stream varies per bring-up session. On a session with PPDU_STS leading each bulk-IN aggregate, the mis-computed next_offset lands the walk in garbage after the first sub-packet → every aggregate yields only its PPDU_STS → the host never sees a WIFI frame → green bring-up, demo.first_rx_frame never fires. On a WIFI-led session the same bug shows as the degraded/unreadable-body flavor instead. Sessions without the decorations are healthy. The selftest now locks a [PPDU_STS(drv_info, unit 16)][WIFI] aggregate walk.

2. The stale-handle / ZeroCD churn: USB reset drops running firmware to ROM

libusb_reset_device on a Kestrel whose firmware is running (or half-torn after a SIGKILLed session) crashes it back to bootrom — the device re-enumerates (device firmware changed), the handle goes stale, and the ROM path can land in the dead ZeroCD DISK id (0bda:1a2b, interface 255 — unswitchable by usb_modeswitch/usbfs, only a VBUS cycle recovers). Bench-measured with SIGKILL-churn on the 8832CU: ZeroCD roulette with the reset, 6/6 clean without it.

Fixes (library + demos):

• claim_interface_then_reset now skips the USB reset for any kestrel::variant_for_usb_id match — Kestrel power_on forces the MAC off from any retained state, so the reset added nothing but the ROM-drop risk.
• New devourer::claim_interface_reset_reopen: if a reset does re-enumerate (other chips / forced), it re-opens the same bus+port under the original VID:PID (bounded wait, ZeroCD ids skipped) and re-claims without a second reset.
• The demos' DEVOURER_USB_BUS/PORT discovery polls up to 15 s for the named socket instead of failing on the first empty scan (a closed/killed predecessor leaves the chip re-enumerating for seconds).

Validation

• SIGKILL-churn ×6 on the 8832CU, default env: 6/6 bring-ups deliver (700–1000 frames/15 s), 0 ZeroCD landings, 0 stale handles.
• From VBUS cold: clean.
• tests/he_er_su_cross_rx.sh same-die (8852C→8852C) and cross-die (8852B→8852C), ch6: 8/8 cells pass on the first attempt — zero retries, zero VBUS cycles (vs all-day retry roulette before).
• 24/24 ctest.

Not fully explained: one degraded (12-frame) 8852B RX cell observed once early in the session; not reproduced across 29 controlled bring-ups (pure / post-TX / under-flood / from-cold / post-SIGKILL). Left open for observation — the harness belt-and-braces retry stays in the test script.

🤖 Generated with Claude Code

[josephnef]

Fixed: the delivery-level deafness by the RX-descriptor walk fix in #295 (per-die drv_info unit / shift×2 / mac_info+4), and the stale-handle/ZeroCD churn by #296 (Kestrel skips the USB reset; reopen recovery; bounded topology discovery). Validated: SIGKILL-churn 6/6 clean with 0 ZeroCD landings, and both ER cross-RX matrices pass 8/8 cells on the first attempt with zero retries.