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

["Luka Gejak" <luka.gejak@linux.dev>]

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