Re: [PATCH rtw-next 0/5] wifi: rtw88: pci: Support an older design, like RTL8821AE/RTL8812AE

[Bitterblue Smith <rtl8821cerfe2@gmail.com>]

On 31/10/2026 09:42, Luka Gejak wrote:
> Hi Bitterblue,
> 
> I had taken a look at the RX slowdown on the RTL8821AE and I don't think
> it is the PCIe link that causes it.
> 
> October 30, 2026 at 7:47 PM, "Bitterblue Smith" <rtl8821cerfe2@gmail.com> wrote:
> 
>>
>> On 30/10/2026 02:43, Ping-Ke Shih wrote:
>>
>>>
>>> Have you dug the cause RX speed is low? The PHY rate becomes low at that time?
>>> Or can air capture see any weird packets? Or did you think PCIE get stuck
>>> somehow?
>>
>> I think it's a PCIE problem. Before the first IMR_RDU the RX speed is normal.
>> After, it's low. I will test the RTL8821AE again probably next week.
> 
> As far as I can see, the RX descriptors are never given back to the
> hardware on power on. The RX ring is set up only once in probe, and on
> every power on this runs:
> 
>         rtw_hci_setup()
>           rtw_pci_setup()
>             rtw_pci_old_reset()
>               rtw_pci_old_reset_buf_desc()
> 
> which only resets the indexes and the base address:
> 
>         rtwpci->rx_rings[RTW_RX_QUEUE_MPDU].r.rp = 0;
>         rtwpci->rx_rings[RTW_RX_QUEUE_MPDU].r.wp = 0;
>         rtw_write32(rtwdev, REG_RX_DESA,
>                     rtwpci->rx_rings[RTW_RX_QUEUE_MPDU].r.dma);
> 
> On the way down, rtw_pci_stop() turns off the interrupt and NAPI, but RX
> keeps running until rtw88xxa_power_off() clears REG_CR. A frame that lands
> in the ring after the last NAPI poll stays in its descriptor with OWN
> cleared.
> 
> So if I read it right, after the next power on the driver and the
> hardware both start at descriptor 0, while some descriptors are still
> owned by the host. If descriptor 0 is one of them:
> 
>         hardware fills 511, finds 0 owned by the host, raises IMR_RDU
>         driver handles 511, then 0 (an old frame), then waits at 1
>         hardware gets 0 back, fills it with a new frame, then 1, 2...
> 
> The new frame in descriptor 0 is now behind the driver, so it is only
> picked up after the next wrap, and the same thing happens again. So the
> hardware seems to be right about IMR_RDU, the descriptor it wants really
> belongs to the host, even with 510 or 511 others free.
> 
> This doesn't go away by itself. I put the ring logic in a small
> simulation, and with one stale descriptor at 0 it shows your exact order
> (511, 0, wait at 1) and an IMR_RDU on almost every lap. The frame from
> descriptor 0 is about 511 frames old by then. That is far behind the
> reorder window, so I think mac80211 drops it as out of date, and TCP sees
> a loss on every lap. That could well cap it at 70 to 100 Mbps.
> 
> It would also fit the rest of what you saw. The idle interface powers off
> and on a lot, so there are many chances to leave a frame behind. A power
> cycle doesn't help because the stale descriptors are still there after
> it, and reloading the driver helps because rtw_pci_init_rx_ring() sets up
> a fresh ring. Maybe the Bluetooth headphones matter because the
> C2H_BT_INFO reports come in through the same RX ring.
> 
> rtlwifi doesn't run into this because rtl_pci_reset_trx_ring() clears
> every RX descriptor and sets the buffer address, PKT_LEN and OWN again,
> with EOR on the last one. It is called from rtl_pci_start() and from
> rtl_ps_enable_nic(). Would it make sense to do the same in
> rtw_pci_old_reset_buf_desc()? Maybe the descriptor part of
> rtw_pci_old_reset_rx_desc() could be split out and reused there.
> 
> Sending rtw_pci_reset_trx_ring() through pci_gen for the stop path, as
> you planned for patch 4, would fix the registers, but I think it would
> still leave the descriptors as they are.
> 
> Best regards,
> Luka Gejak

I remember thinking there is nothing wrong with the RX ring because
"it looks fine".

But you're right, IMR_RDU is caused by a packet arriving after
rtw_pci_stop(). Resetting the RX ring fixes it.