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

[Bitterblue Smith <rtl8821cerfe2@gmail.com>]

On 11/02/2026 04:03, Ping-Ke Shih wrote:
> 
> 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.
> 

Still no problem two days later.

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

Have a good holiday!

>>
>>>>
>>>>>>
>>>>>> 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.
> 

It can take hours, although with RTL8821AE it happens in just a few
minutes.

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