[PATCH rtw-next 0/2] rtw88: recover a stopped TX queue, and notice a stalled ring

[Abdurrahman Karadag <abdurrahmankaradag19@gmail.com>]

From: abkarada <abdurrahmankaradag19@gmail.com>

These come out of a long thread about an RTL8821CE whose TX dies while
the link stays associated:

  https://lore.kernel.org/linux-wireless/20260826162514.80580-1-abdurrahmankaradag19@gmail.com/

Ping-Ke asked whether triggering the driver's recovery resolves the
stuck ring. Trying to answer that turned up patch 1, which is a real
bug and independent of whatever makes the hardware stop in the first
place.

Patch 1: for a queue stopped by the PCI TX ring-full path, the flag and
the stop reason are released only from the completion loop in
rtw_pci_tx_isr(). Resetting the rings drops the pending descriptors and
frees their skbs directly, so that loop never runs for them, and the
stop survives over an empty ring that will never complete anything
again. ieee80211_restart_hw() therefore cannot recover a device that
had stopped a queue - which is precisely when you would want it to. The
patch records the queue mappings that path stops and releases them both
from the completion loop and when the reset empties the ring.

I can produce that state on demand by pausing TX in hardware, which
freezes the read index while the driver keeps submitting, the same
shape the chip shows when it wedges by itself. Same script both ways,
only the patch differs:

                              without patch        with patch
  BE queue stopped after      1 s                  1 s
  doorbell rewrite            no effect            no effect
  rtw_fw_recovery()           ran                  ran
  BE stop reason afterwards   0x1                  0x0
  traffic                     none in 90 s         back within 2 s

In the failing run the station reassociated twice inside those 90 s, so
the link was up; only the queue was still stopped.

Patch 2 is diagnostic and unrelated to the above: there is currently no
sign anywhere when a TX ring stops advancing. I have five captures
where the hardware read index is frozen while the write index runs on,
with power save off and REG_TXPAUSE at 0x00, and in four of them the
ring had not even filled yet - traffic was simply gone, with nothing in
the log. This warns once per episode. Checked silent across 180 s of
saturated TX, about 600 MB.

Patch 2 is the detection half of a patch I sent and withdrew in
September; its recovery was a doorbell rewrite, which I measured as
ineffective and which is gone.

Both build clean with W=1 and pass checkpatch --strict.

Abdurrahman Karadag (2):
  wifi: rtw88: pci: wake the TX queues when the rings are reset
  wifi: rtw88: pci: warn when a TX ring stops advancing

 drivers/net/wireless/realtek/rtw88/hci.h  |   7 ++
 drivers/net/wireless/realtek/rtw88/main.c |   2 +
 drivers/net/wireless/realtek/rtw88/pci.c  | 128 ++++++++++++++++++++--
 drivers/net/wireless/realtek/rtw88/pci.h  |   4 +
 4 files changed, 134 insertions(+), 7 deletions(-)


base-commit: 7cde94dab0e74434ccc0a387d7ad373fb3becda0
-- 
2.55.0