Repository navigation
40 MHz broken in both directions on Jaguar1: TX not decodable, RX deaf even to 20 MHz frames #352
Description
Activity
Register diff: one surviving lead, BB
0x8b0tests/bw40_regdiff.sh(pushed onrx-bw40-gap) puts the same adapter into each width under each driver and diffs the canary set, reporting only registers that differ at 40 MHz and match at 20 MHz.register devourer @40 vendor @40 both @20 BB 0x8b0 0x000006420x000006180x00000642BB 0xe90 0x018074060x018074080x01807C06The base BB table loads
0x8b0 = 0x00000600on both sides, so something writes the low bits at runtime and the vendor moves to0x618for 40 MHz where devourer stays at0x642. Not yet chased to a cause — recording it rather than guessing.Two things ruled out
- Not the 40 MHz register sequence. devourer's
phy_PostSetBwMode881240 MHz branch is register-for-register identical to the vendor's (0x8ac, 0x8c4, 0x483 DATA_SC, 0x848 L1PeakTH, 0x84a CCK_System, RF 0x18[11:10]). - Not a missing
phy_set_mac_clk_8812a. That function takes the same branch for 20 and 40 MHz (only 10 MHz differs), so a missing call cannot explain 20-works/40-fails.
Harness correction (affects anyone using the canary tooling)
tools/canary_kernel_dump.shsets the channel itself, at 20 MHz, silently overwriting a caller that had already selected HT40 — so it would describe a 20 MHz chip while claiming to be a 40 MHz capture. It now takes an optional HT-mode argument. The diff caught this on itself: the vendor column read0x8acbits[1:0]=00 at "40 MHz".This does not affect the TX/RX isolation in the issue body —
bw40_isolate.shsets HT40 directly and never calls the dump tool. Independently confirmed the vendor driver does honour HT40 in monitor mode (0x8ac = 0x0FF0FA09, bits[1:0]=01).- Not the 40 MHz register sequence. devourer's
Summary
40 MHz does not work on Jaguar1 in either direction. Both paths fail
independently, each proven against the vendor kernel driver on the other end.
This survived the receiver-qualification cleanup in #351 — it is not a
link-margin artifact like the #348 reports were.
Measurements
tests/bw40_isolate.sh(added with this report). One end is always the vendorkernel driver, so each leg tests exactly one devourer path. Every leg carries its
own control, because the easiest way to fake this bug is a monitor that is simply
deaf in HT40 mode.
DUT: RTL8812AU (
0bda:8812), devourer side. Vendor side: Comfast CF-924AC V2(RTL8822BU, external antennas) under
reference/rtl88x2bu. ch6, HT40+.TX leg — devourer transmits, vendor driver receives:
The third row is the one that matters: the same HT40 monitor that decodes 3059
frames of 20 MHz traffic decodes zero of devourer's 40 MHz traffic. So
devourer's 40 MHz TX does not produce a frame this receiver can decode.
RX leg — vendor driver transmits, devourer receives:
DEVOURER_BW=40)The injector sends a 20 MHz frame on the primary channel in both cells. So
at
DEVOURER_BW=40the receiver cannot hear even a 20 MHz frame on its ownprimary — it is not a wide-frame decode problem, the receiver goes broadly deaf.
Scope
behaviour on Jaguar2 (8822BU) at both primary-channel offsets and in both role
directions; that needs re-running with this harness now that it has controls.
DEVOURER_CHOFFSET/DEVOURER_HOP_OFFSETvalues were swept in theearlier runs with no difference.
Why this was not caught before
The existing 40 MHz TX validation (
tests/jaguar2_tx_bw40.sh) uses a kernelsniffer and covers Jaguar2. The devourer 40 MHz receive path appears never to
have been exercised on air at all, and the Jaguar1 40 MHz transmit path is not
covered by that script.
docs/vht-on-2g4.mdcurrently describes this as a receiver-side gap. That isnow known to be only half of it — the TX side fails too — and the doc should be
corrected alongside a fix.
Impact
40 MHz is the headline bandwidth for the 2×2 rates (
VHT2SS_MCS9/40= 400 MbpsPHY, the whole point of #331). None of it is reachable today, and a caller that
sets
DEVOURER_BW=40/DEVOURER_HOP_BW=40gets silence with no error — thetransmitter reports every frame submitted and the receiver reports a clean
bring-up.
Reproducing
sudo REGRESS_VBUS_MAP="0bda:8812=3-2.3.4,3;0bda:b812=4-2.3,3" \ tests/bw40_isolate.shRead the TX leg's third cell first — if the HT40 monitor is deaf there, the
whole leg is void. The RX leg self-voids when its own 20 MHz control fails.
🤖 Filed with Claude Code