RE: [BUG] rtw88 8821ce: connection wedges (100% loss until reboot) with station power save

[Ping-Ke Shih <pkshih@realtek.com>]

Abdurrahman Karadag <abdurrahmankaradag19@gmail.com> wrote:
> > Checking commits between 7.0.12 and 7.1.9, the only related commit might be
> >    c95323ea9dfb ("wifi: rtw88: coex: Solve LE-HID lag & update coex version
> >    to 26020420")
> > You can revert the patch from 7.1.9 to see if it becomes normal.
> 
> I reverted it from 7.1.9 and the wedge still happened, about an hour after
> boot, so that commit is not the cause. BT is disabled on this machine
> anyway (coex_info reports "BT disabled", BT status non-conn).

I wonder even you use driver of 7.0.12 (on 7.1.9). It will still happen.
Not sure if host side change something?
Can you 100% ensure 7.0.12 is fine?

> 
> Rather than continue bisecting, I set up a watchdog that dumps
> queues/aqm/TXBD indices at the moment of the wedge, before anything
> touches the interface. I have five such dumps now (I discount one of
> them, taken on a captive portal network where the ping probes are
> unreliable), plus healthy baselines, and they show a consistent
> driver-level failure. I have also been able to reproduce that failure
> deterministically and to recover from it. Details below; I am
> sending a patch as a separate mail.
> 
> 1. What the wedge looks like from inside the driver
> ---------------------------------------------------
> 
> This is the dump from 2026-08-28 22:05, taken with power save off, on
> 5 GHz, 91 minutes into the association:
> 
>   /sys/kernel/debug/ieee80211/phy0/queues
>     00: 0x00000000/0   (VO)
>     01: 0x00000000/0   (VI)
>     02: 0x00000001/0   (BE)  <- stopped, reason bit 0 = DRIVER
>     03: 0x00000000/0   (BK)
> 
>   stations/<ap>/aqm tid 0 (BE): backlog 20941 -> 26960 bytes,
>     94 -> 144 packets, flags DIRTY, still growing while sampled
> 
>   iw station dump, 5 s apart:
>     tx packets  116017 -> 116017   (frozen)
>     rx packets  244885 -> 244992
>     beacon rx    53304 ->  53353
> 
>   TXBD_IDX_BEQ (0x3A8) = 0x003c003a in all four samples, taken over
>     about 15 seconds

Hardware read index is 0x3c, and host write index is 0x3a.
So, it reaches the limit of stop queue. 

[...]

> 
> I will send the patch separately so that it lands in patchwork on its
> own. It only adds the stall detection and the re-kick; it does not touch
> the normal TX path, it skips rings with nothing in flight so an idle
> device is never poked, and it warns once per stall rather than on every
> retry.

As your experiments, the cause is hardware never reads TX buffer and gets
stuck, right?

I quickly check the patch. It looks like the way to unlock this state is
to call rtw_pci_tx_kick_off_queue() again?

Which means not a driver side bug (stop queue but not restart queue properly),
right? 

> 
> One question, in case a re-kick turns out not to be enough in the field.
> The out-of-tree rtw88 driver has a pci_old.c for the older PCIe
> generation, where the PCIe DMA is reset after a TRX hang using the two
> status bits at REG_DBI_CTRL + 3 (bit 0 TX, bit 1 RX), with bit 2
> enabling the detection. Is that status bit valid on 8821CE as well? If
> it is, I can dump it during the next wedge and, if it confirms a DMA
> hang, a reset could be added as a second stage.

I checked vendor driver. It only does this at initial step, not to recover
it at runtime.