Skip to content

Follow-ups left open by the TX page-ring fix and its review follow-up (#451, #453) #455

Description

@josephnef

Items deferred out of #451 (the REG_CR 0xFF-before-LLT-init fix) and #453 (its review follow-up), all pre-existing on master or deliberately left as they are. None changes the fix itself.

Beacon lifecycle

  1. StopBeacon result contract. It returns false both for "nothing active" (the IRadio contract) and for "a disable write was refused", so a caller cannot tell them apart. txdemo's TxBeaconGuard therefore ends its loop on any false, and a refused disable on Jaguar2 (which has no teardown power-down) can leave the beacon airing until re-enumeration. Fix shape: a distinct result from StopBeacon (tri-state or a BeaconStopResult), after which the guard retries only the refused case. Interim without an API change: after a successful StartBeacon (armed == true) both Jaguar2 and Jaguar3 return false only on a refused disable and keep _bcn_hw_touched, so if (!dev->StopBeacon() && armed) continue; in the guard's loop already gives the retry that matters.
  2. A failed pre-touch step during a Jaguar2/3 re-arm leaves the old beacon airing (jaguar2/3: enable the MAC protocol engine before the LLT init - the TX page-ring fix #451 review round 10).
  3. Jaguar1 StartBeacon returns true after a failed PinBeaconTbtt(0) re-download (jaguar2/3: enable the MAC protocol engine before the LLT init - the TX page-ring fix #451 round 7).
  4. Kestrel has no StopBeacon: it inherits the IRadio no-op, so a Kestrel beaconing session cannot disarm mid-session (jaguar2/3: enable the MAC protocol engine before the LLT init - the TX page-ring fix #451 round 3; untestable on that PR's bench).

Send path

  1. Jaguar1 and Jaguar2 copy _ampdu unsynchronized on the send path (jaguar2/3: enable the MAC protocol engine before the LLT init - the TX page-ring fix #451 round 9); Jaguar3 was fixed there, the other two were not.
  2. Below 3 bulk-OUT endpoints the SetAmpduMode TID lands on data frames that ride endpoint 0: a descriptor/endpoint mismatch on the 1- and 2-endpoint shapes, deliberately kept and pinned by tests/txqueue_selftest.cpp (src/jaguar3/TxQueueMap.h). Neither the 1/2- nor the 4-endpoint shape has been measured; the DEVOURER_TX_QSEL override can produce the same mismatch on any shape.

TXDMA_STATUS decoding

  1. Only two bits of REG_TXDMA_STATUS are decoded (IRtlRadio::GetTxDmaStatus): bit 18 BIT_TXPKTBUF_REQ_ERR, the one measured with the wedge, and bit 13 BIT_PAYLOAD_OVF_8822C, which latches under max-duty USB2 backpressure while TX continues. The 8812BU's wedge read 0x10 then 0x15, undecoded. The bit-13 latch is intermittent: seen from the first sample on an 8812CU at DEVOURER_TX_GAP_US=0 on 2026-09-26/27, and absent in 26/26 samples of an otherwise identical cold-cycled run at jaguar2/3: #451 review follow-up - TXDMA_STATUS bit semantics, send_packets drop warning, beacon-guard retry #453's head. A poller that wants a "stopped" verdict needs the remaining bits decoded against halmac_bit_8822c.h / the 8822B equivalent and each one measured.

Bench

  1. The 8812EU cell is unusable at max-duty 1400-byte TX: the bare module (external 5 V, 0bda:a81a) drops off USB about 2 s in, every build, so jaguar2/3: enable the MAC protocol engine before the LLT init - the TX page-ring fix #451 and jaguar2/3: #451 review follow-up - TXDMA_STATUS bit semantics, send_packets drop warning, beacon-guard retry #453 were validated on the 8812CU and 8812BU only. Consistent with the pre-existing 5 GHz flood NAK behaviour plus a likely supply brownout; needs a powered fixture before the EU die can be a witness for either fix.

Context and measurements: #451 and #453 bodies, docs/jaguar3-tx-ring.md, src/jaguar3/CLAUDE.md.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions