RE: [PATCH rtw-next] wifi: rtw88: Ignore TX report sequence number from the 8051 chips

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

Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> On 10/02/2026 08:44, Ping-Ke Shih wrote:
> > Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> >> On 09/02/2026 10:19, Ping-Ke Shih wrote:
> >>> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> >>>> When connected to a network in the 2.4 GHz band, wpa_supplicant (or
> >>>> NetworkManager?) triggers a scan every five minutes. During these scans
> >>>> mac80211 transmits many QoS Null frames in quick succession. Because
> >>>> these frames are marked with IEEE80211_TX_CTL_REQ_TX_STATUS, rtw88
> >>>> asks the firmware to report the TX ACK status for each of these frames.
> >>>> Sometimes the firmware can't process the TX status requests quickly
> >>>> enough, they add up, it only processes some of them, and then marks
> >>>> every subsequent TX status report with the wrong number.
> >>>
> >>> Does it mean number of reports is correct? But with incorrect sequence number?
> >>> Then, you just ignore checking 'sn' but assume 'st' is correct.
> >>>
> >>
> >> The number of reports is correct most of the time. Only when the firmware
> >> is overwhelmed (?) it doesn't provide every report, but later it recovers.
> >>
> >
> > I was not aware that this happened while scanning, so we might apply this loose
> > checking under scan condition -- test_bit(RTW_FLAG_SCANNING, rtwdev->flags)"?
> > If TX report is because of re-key, it can still use original rule.
> >
> > [...]
> >
> 
> We can't do that because the sequence number is permanently messed up.

Indeed...

> 
> I thought about ignoring IEEE80211_TX_CTL_REQ_TX_STATUS on null frames
> sent during scans, but unfortunately the last 2 or 3 QOS Null frames
> are sent after RTW_FLAG_SCANNING is unset, and they still trigger the
> problem.
> 
> While poking around today I noticed that only non-QOS null frames are
> treated like management frames. QOS null frames are treated like data
> frames. So I tried this change:
> 
> diff --git a/drivers/net/wireless/realtek/rtw88/tx.c b/drivers/net/wireless/realtek/rtw88/tx.c
> index 783975acdcff..ea83daa9d60d 100644
> --- a/drivers/net/wireless/realtek/rtw88/tx.c
> +++ b/drivers/net/wireless/realtek/rtw88/tx.c
> @@ -424,7 +424,7 @@ void rtw_tx_pkt_info_update(struct rtw_dev *rtwdev,
>                 pkt_info->mac_id = rtwvif->mac_id;
>         }
> 
> -       if (ieee80211_is_mgmt(fc) || ieee80211_is_nullfunc(fc))
> +       if (ieee80211_is_mgmt(fc) || ieee80211_is_any_nullfunc(fc))
>                 rtw_tx_mgmt_pkt_info_update(rtwdev, pkt_info, sta, skb);
>         else if (ieee80211_is_data(fc))
>                 rtw_tx_data_pkt_info_update(rtwdev, pkt_info, sta, skb);
> 
> With this I can't trigger the problem anymore. The sequence numbers
> are normal every time. Well, it's too soon to be sure, so I will keep
> testing for a few days.

Good finding. Please keep testing it.

FYI. Having the lunar New Year next week, I will not reply your mail soon.

> 
> >>
> >>>>
> >>>> The symptom is that after a while the warning "failed to get tx report
> >>>> from firmware" appears every five minutes.
> >>>>
> >>>> This problem apparently happens only with the older RTL8723D, RTL8821A,
> >>>> RTL8812A, and probably RTL8703B chips. Ignore the TX report sequence
> >>>> number reported by these chips and match the reports with the requests
> >>>> in the order they come in.
> >>>>
> >>>> Tested with RTL8821AU and RTL8723DU.
> >>>>
> >>>> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
> >>>> ---
> >>>>  drivers/net/wireless/realtek/rtw88/tx.c | 2 +-
> >>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/drivers/net/wireless/realtek/rtw88/tx.c b/drivers/net/wireless/realtek/rtw88/tx.c
> >>>> index c04ff31d0f1e..98215ecc884a 100644
> >>>> --- a/drivers/net/wireless/realtek/rtw88/tx.c
> >>>> +++ b/drivers/net/wireless/realtek/rtw88/tx.c
> >>>> @@ -248,7 +248,7 @@ void rtw_tx_report_handle(struct rtw_dev *rtwdev, struct sk_buff *skb, int src)
> >>>>         spin_lock_irqsave(&tx_report->q_lock, flags);
> >>>>         skb_queue_walk_safe(&tx_report->queue, cur, tmp) {
> >>>>                 n = (u8 *)IEEE80211_SKB_CB(cur)->status.status_driver_data;
> >>>> -               if (*n == sn) {
> >>>> +               if (*n == sn || rtw_chip_wcpu_8051(rtwdev)) {
> >>>
> >>> Can we only limit to USB devices (or non-PCI devices)?
> >>>
> >>
> >> I don't think so. RTL8821AE also has this problem. I didn't mention it
> >> in the commit message because support for RTL8821AE in rtw88 is
> >> unofficial. (I modified rtw88_pci to handle the older generation, see
> >> the use_new_trx_flow=false code path in rtlwifi.)
> >
> > How about official RTL8723DE?
> >
> 
> I don't have RTL8723DE. I can try with RTL8723DS, although it's annoying
> to use. (The host is some kind of single board computer. It has only a
> serial interface and when I connect that to my laptop it makes the
> touchpad slow for some reason.)

I found a RTL8723DE and tested scan during connection over 10 times
(with local modification to print TX-sn/RX-sn).
I'd say RTL8723DE doesn't have this problem.

> 
> >>
> >>>>                         __skb_unlink(cur, &tx_report->queue);
> >>>>                         rtw_tx_report_tx_status(rtwdev, cur, st == 0);
> >>>>                         break;
> >>>> --
> >>>> 2.52.0
> >>>
> >