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:
> > could you please give summarize the causes you found and the solutions
> > you adopted?
> 
> Two things, and I only have a fix for the second.
> 
>   (a) The BE TX ring's hardware read index stops advancing. The driver
>       keeps submitting until avail_desc() drops below 2, and from then on
>       the ring-full path holds the queue stopped. Why it freezes is still
>       unknown.
> 
>   (b) ring->queue_stopped is cleared only by the completion loop in
>       rtw_pci_tx_isr(). That loop does not run while the read index is
>       frozen, and a ring reset rewinds the indices, so nothing is left
>       that could complete and run it. The queue then stays stopped for
>       good.
> 
> v2 of patch 1 fixes (b), with ieee80211_wake_queues() as you suggested. I
> have nothing to offer for (a). Patch 2 is dropped rather than resent.

Okay. Let's move discussion to the patch. 
(Two interleave threads are hard to read.)

> 
> The five events from my 3 October mail stand unchanged: the same five,
> power save off, REG_TXPAUSE 0x00 in every sample.
> 
> > Can you dig why REG_TXPAUSE becomes 0xff?
> > I wonder this is the cause PCI TX gets stuck?
> 
> It is station power save, and it is not the cause.

Got it. Thanks for the info.

> 
> Nothing in the driver writes it on this chip. rtw8821c_mac_init() writes
> 0; rtw_core_enable_beacon() returns early unless ap_active and only
> touches BIT_HIGH_QUEUE; ps.c never references the register; the 0xff in
> rtw_wow_bb_stop() is unreachable because 8821c declares no wowlan_stub;
> and 8821c has no act_to_lps power sequence. The other writers are in chip
> files an 8821ce does not load. That leaves the firmware, which enters LPS
> over H2C rather than by writing 0x522, so there is no host write to
> catch.
> 
> The correlation is clean. Of 48 register dumps, the 6 taken while "iw dev
> wlan0 get power_save" reported on all read 0xff; the 42 taken with it off
> never did. REG_CR agrees: 9 of the 11 0xff samples read 0x043f instead of
> 0x06ff, and the difference 0x02c0 is BIT_MACTXEN, BIT_MACRXEN and
> BIT_MAC_SEC_EN cleared.
> 
> But it is neither necessary nor sufficient for the stall. All five events
> read 0x00 with power save off. And 08-29 04:35 reads 0xff with the BE
> ring filling and draining normally - read index equal to write index in
> every sample - and the link was still 100% lost. So I am dropping this
> line.

It looks like you did experiments with power save on/off cases.
I suggest to turn it off for all experiments, since you are trying
to narrow down the cause. 

> The monitor capture I still owe you. I will stop promising it against the
> next event and send it when I have it.

No rush because it might be not important clues to dig why TX gets stuck.

Though we have not found cause, could you describe how you resolve the
stuck (by the method of your previous patch, maybe v1)?
I'd think the workaround a little bit.

Ping-Ke