[BUG] ath12k: WCN7850 firmware stops uplink TX on EHT (CMD_REMOVE_AGED_FRAMES)

[Enrico]

Hi,

On EHT, the WCN7850 firmware stops transmitting uplink data for 1-4
minutes while the association stays up. The driver keeps handing it
frames, the firmware releases them as CMD_REMOVE_AGED_FRAMES, and the
AP receives only the few frames the firmware reports as acked.
Downlink keeps working and the kernel logs nothing. I saw 11 stalls
in 57 hours on EHT and 0 in 24 hours after switching the AP's 5 GHz
radio to 802.11ax.

Setup:
- Client: Framework laptop, WCN785x [17cb:1107] rev 01,
  subsystem 1eac:8000, ath12k_wifi7_pci
- Kernel: 7.2.7
- Firmware: WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3
  (fw_version 0x1103006c, latest in linux-firmware)
- AP: TP-Link EAP770(EU) v1.0 (IPQ9574), firmware 1.0.0, channel 36,
  80 MHz, WPA/WPA2-PSK with TKIP group cipher
- Link: EHT-MCS 12, 80 MHz, 2 NSS, no MLO, signal -31 to -38 dBm
  at the client

Client side, sampled every 2 s with bpftrace (ath12k_wifi7_mac_op_tx
calls, ar->dp.num_tx_pending, deltas of
ath12k_dp.device_stats.tqm_rel_reason):

During a stall the firmware acks only 7-15% of the frames enqueued
and num_tx_pending grows to 1616-4360 (the 9 stalls recorded with
bpftrace). Frames come back in batches as CMD_REMOVE_AGED_FRAMES and
some as CMD_REMOVE_MPDU. At the end the whole queue completes within
2 s.
Sums from stall start to recovery for the 4 stalls recorded with the
release counters (FRAME_ACKED includes the recovery burst):

  stall start        enqueued  FRAME_ACKED  AGED_FRAMES  REMOVE_MPDU
  10-13 22:19:13        20546         9916        10630            6
  10-14 01:28:35        28114         8799        19219           94
  10-14 03:16:57        27658         8811        17770         1075
  10-14 12:14:35        43663        17485        23012         3146

mac80211 and cfg80211 tracepoints show no flush, queue stop, sta
state change, beacon loss or connection loss in any of the 9 stalls.
The only events inside the stalls are scans: 5 of the 9 contain one
or two back-to-back 8-9 s scans, 4 contain none.

AP side, per-station counters (apstats -s -m <client MAC>) every 2 s
during the stall from 2026-10-14 12:14:35 to 12:17:36:

  time      AP rx data  AP tx data/ok  client FRAME_ACKED/AGED
  12:14:01         +48        +44/+44  87/0
  12:15:05          +0        +19/+19  0/224
  12:17:30          +0        +22/+22  0/993 at 12:17:31, pending 1990
  12:17:36       +3273    +2399/+2398  15033/0 at 12:17:37, pending 1
  12:17:38      +12498    +9273/+9268

>From 12:14:41 to 12:17:34, in 61 of 87 samples the AP receives no
data from the client. The
other 26 show 1-213 frames, and each matches a FRAME_ACKED batch on
the client in the same 2 s. The AP's TxSuccessDataPackets stays
within 1 of TxDataPackets in every sample.

802.11ax: the client links at HE-MCS 11, 2 NSS, 80 MHz. Over 24
hours CMD_REMOVE_AGED_FRAMES stayed at 0 out of 3.42M frames
enqueued.

I can send the full logs and the bpftrace script, and test firmware
builds or patches.

Thanks,
Vladimir