Repository navigation
RTL8814AU: devourer-RX captures 0 frames in tests/regress.py full-matrix #51
Description
Symptom
In tests/regress.py --full-matrix --channel 100, every cell where the RX side is RTL8814AU (devourer) returns 0 hits, regardless of TX side:
| Cell | TX side | RX side (devourer 8814AU) | Result |
|---|---|---|---|
| 11 | RTL8821AU (kernel) | RTL8814AU (devourer) | 0 hits / 452 TX ✗ |
| 12 | RTL8821AU (devourer) | RTL8814AU (devourer) | 0 hits / 7000 TX ✗ |
| 19 | RTL8812AU (kernel) | RTL8814AU (devourer) | 0 hits / 450 TX ✗ |
| 20 | RTL8812AU (devourer) | RTL8814AU (devourer) | 0 hits / 6500 TX ✗ |
| 23 | RTL8812AU (kernel) | RTL8821AU (devourer) | 0 hits / 444 TX ✗ |
| 24 | RTL8812AU (devourer) | RTL8821AU (devourer) | 0 hits / 6500 TX ✗ |
(Cells 23/24 are devourer-RX 8821 — listed for completeness; the symptom is the same devourer-RX captures zero from any-side-TX-that's-working.)
When the same TX side (which sends 6000+ frames per cell) is paired with a kernel RX 8814AU (cells 9, 10, 17, 18), the kernel RX side captures hundreds to thousands of frames. So the TX side is fine and the chip itself receives — devourer's RX path does not surface the frames.
Reproduce
Pre-condition: full-matrix harness up (tests/setup_vm.sh).
sudo python3 tests/regress.py --full-matrix --channel 100 \
--vm-name devourer-testrig --vm-ssh josephnef@<vm-ip>Or minimally for one ordered pair:
sudo python3 tests/regress.py --tx-pid 0x0120 --rx-pid 0x8813 \
--channel 100 --vm-name devourer-testrig --vm-ssh josephnef@<vm-ip>Inspect cell logs under /tmp/devourer-regress-last/ (or --keep-logs).
What's known
- This is pre-existing and unrelated to RTL8814AU: devourer TX degrades to LIBUSB_ERROR_IO after USB passthrough cycles #36 / PR RTL8814AU: drop REG_CR=0 post-fwdl write that wedges bulk-OUT #49. The bulk-OUT-FIFO wedge that PR RTL8814AU: drop REG_CR=0 post-fwdl write that wedges bulk-OUT #49 fixed was on the TX side only.
- Affected: only
devourer-RXcells where the DUT is RTL8814AU (and possibly RTL8821AU per the matrix snapshot above — needs confirmation in a 1-pair re-run). - Not affected:
devourer-RXon RTL8812AU;devourer-TXon any chipset;kernel-RXon any chipset. - Today's session focused on TX investigation and didn't touch RX. The full-matrix data captured above is from 2026-05-26 16:43 run (post-PR-RTL8814AU: drop REG_CR=0 post-fwdl write that wedges bulk-OUT #49-merge).
Likely surfaces
src/RtlUsbAdapter.cpp:InitDvObj— bulk-IN endpoint discovery (_bulk_in_ep).src/RtlUsbAdapter.cppasync RX submission path (or sync? — needs verification).src/FrameParser.cpp— RX descriptor parsing per chip family. 8814 uses a different RX descriptor layout than 8812 in some fields.src/HalModule.cpp_InitQueueReservedPage_8814AUsb— page allocation for RX FIFO. Today's bisect verified TX FIFO drains; RX FIFO is separate.
Acceptance criteria
tests/regress.py --full-matrix --channel 100 --vm-name devourer-testrig --vm-ssh josephnef@... shows ≥ 1 hit in cells [11, 12, 19, 20]. (Cells 23/24 belong to a separate bug if the 8821 RX path is also broken.)
Not in scope here
- 8814AU on-air emission silence (devourer-TX) — separate issue.
- RTL8814AU: devourer TX degrades to LIBUSB_ERROR_IO after USB passthrough cycles #36 — closed.
Activity
josephnef commentedon Jun 3, 2026
Status after #77 — still valid, not unblocked.
PR #77 (8814A band-switch + channel-set chain port) runs the full 8814A-specific BB/RF setup on the RX side too (
phy_SwChnl8814Afires fromSetMonitorChannelduringRtlJaguarDevice::Init). Hardware re-verification at ch100 with the merged code:0 / 4500 TX0 / 237 TXIdentical to the pre-PR baseline. So the BB/RF channel-set chain is not the gate — band/channel state is now programmed correctly, RX still surfaces nothing.
For contrast, at ch6 the same kernel-TX 8821 → dev-RX 8814 cell produces ~200 hits. The gate is 5GHz-specific.
This rules out the "missing 8814A channel-set" theory and points back at the issue's original "Likely surfaces" list —
RtlUsbAdapterbulk-IN read path, 8814 RX descriptor parse inFrameParser, or_InitQueueReservedPage_8814AUsbRX FIFO setup — none of which #77 touched.Keeping open. Next investigation step should follow that list, starting from a bulk-IN endpoint trace (
usbmonon bulk EP 0x81 during a ch100 kernel-TX-into-devourer-RX run) to see whether the chip is even handing frames over the bulk pipe at 5G.josephnef commentedon Jun 10, 2026
Root-caused and fixed — 5 GHz RX now works on hardware (PR #93)
Root cause: the 8814 init ran the 8812 band-switch (
PHY_SwitchWirelessBand8812) instead ofPHY_SwitchWirelessBand8814A. The 8812 version marks the band already-set via the CCK-check register, so the later per-chip dispatch inphy_SwBand8812seesBandToSW == Bandand skips the 8814A band-switch — the 5 GHz RFE pinmux (phy_SetRFEReg8814A), path-C/D config and AGC-table register were never programmed, leaving the 5 GHz RX front-end misrouted (hence the bulk-INLIBUSB_ERROR_TIMEOUT).This is exactly the surface the issue suspected ("the chip isn't handing frames over the bulk pipe at 5G"), one layer up: the chip can't, because its 5 GHz RX path was never configured.
How it was found: a kernel (
aircrack-ng/rtl8814au, in a pinned-kernel VM) vs. devourer usbmon register diff. devourer's runtime0xCB0read0x77337717instead of the correct 5 GHz0x33173317, provingphy_SetRFEReg8814Anever ran. (Notably, source-reading alone said the value was correct — the function just was never called.) The kernel driver RXes this exact dongle fine at 5 GHz, confirming the hardware is sound and the gate was software.Validation (real hardware,
0bda:8813): devourer-RX now surfaces tens of thousands of frames at 5 GHz:The acceptance cells (devourer-RX 8814 at 5 GHz) now pass.
Keeping this open until the rest is confirmed on hardware:
RF_MOD_AG=0x501sub-band) — pending one fresh-chip run; identical code path to ch36/ch100, expected to pass. Testing is rate-limited by RTL8814AU: devourer TX degrades to LIBUSB_ERROR_IO after USB passthrough cycles #36 chip degradation (the 8814 needs to idle-recover after ~2 RX runs / USB-passthrough cycles).8814: run PHY_SwitchWirelessBand8814A at initial band-set (fixes 5GHz…
josephnef commentedon Jun 11, 2026
Re-validated in the issue's own framing (regress matrix, RX = RTL8814AU devourer) — all green. Closing.
The root-cause fix (#93, init band-switch dispatch) plus the 3081-MCU firmware-boot fix (#95 / PR #97) are both on master (
63b9834). Matrix: TX=RTL8812AU, RX=RTL8814AU, VM-mode kernel cells, 15 s/cell:Every cell with the RTL8814AU as devourer-RX now receives, at 2.4 GHz, UNII-1, and UNII-2 — the exact cells this issue tabulated as
0 hits. (The 8821-as-RX cells from the original table were the separate 8821 5 GHz gate, resolved by PR #70.)