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

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

[Bitterblue Smith]

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.

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)) {
 			__skb_unlink(cur, &tx_report->queue);
 			rtw_tx_report_tx_status(rtwdev, cur, st == 0);
 			break;
-- 
2.52.0

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

[Ping-Ke Shih]

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 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)?

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

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

[Bitterblue Smith]

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 added some debugging messages:

[...]
[ 1360.012011] queueing tx report request with sn 144
[ 1360.032820] received tx report with sn 144
[ 1360.157378] queueing tx report request with sn 148
[ 1360.158402] received tx report with sn 148
[ 1360.360006] queueing tx report request with sn 152
[ 1360.380687] received tx report with sn 152
[ 1360.505498] queueing tx report request with sn 156
[ 1360.507455] received tx report with sn 156
[ 1360.708000] queueing tx report request with sn 160
[ 1360.728808] received tx report with sn 160
[ 1360.853490] queueing tx report request with sn 164
[ 1360.857279] received tx report with sn 164
[ 1361.055993] queueing tx report request with sn 168
[ 1361.076800] received tx report with sn 168
[ 1361.201610] queueing tx report request with sn 172
[ 1361.203468] received tx report with sn 172
[ 1361.403988] queueing tx report request with sn 176
[ 1361.445670] received tx report with sn 176
[ 1361.601977] queueing tx report request with sn 180
[ 1361.605731] queueing tx report request with sn 184
[ 1361.611737] queueing tx report request with sn 188
[ 1361.612000] received tx report with sn 180
[ 1361.612090] received tx report with sn 184
[ 1361.615321] received tx report with sn 188

(5 minutes later, another scan:)

[ 1658.918266] queueing tx report request with sn 192
[ 1658.924667] received tx report with sn 192
[ 1659.069240] queueing tx report request with sn 196
[ 1659.075545] received tx report with sn 196
[ 1659.271741] queueing tx report request with sn 200
[ 1659.291789] received tx report with sn 200
[ 1659.417107] queueing tx report request with sn 204
[ 1659.421960] received tx report with sn 204
[ 1659.619861] queueing tx report request with sn 208
[ 1659.639910] received tx report with sn 208
[ 1659.765229] queueing tx report request with sn 212
[ 1659.770078] received tx report with sn 212
[ 1659.967855] queueing tx report request with sn 216
[ 1659.987905] received tx report with sn 216
[ 1660.113223] queueing tx report request with sn 220
[ 1660.118074] received tx report with sn 220
[ 1660.315852] queueing tx report request with sn 224
[ 1660.335900] received tx report with sn 224
[ 1660.461215] queueing tx report request with sn 228
[ 1660.466067] received tx report with sn 228
[ 1660.663845] queueing tx report request with sn 232
[ 1660.683895] received tx report with sn 232
[ 1660.809208] queueing tx report request with sn 236
[ 1660.814056] received tx report with sn 236
[ 1661.011840] queueing tx report request with sn 240
[ 1661.031886] received tx report with sn 240
[ 1661.157204] queueing tx report request with sn 244
[ 1661.158197] received tx report with sn 244
[ 1661.359836] queueing tx report request with sn 248
[ 1661.379878] received tx report with sn 248
[ 1661.528327] queueing tx report request with sn 252
[ 1661.528360] queueing tx report request with sn 0
[ 1661.528573] queueing tx report request with sn 4
[ 1661.530424] received tx report with sn 4
[ 1661.535689] received tx report with sn 252
[ 1662.058688] rtw_8723du 1-1:1.2: still have 1 unprocessed tx report requests

(5 minutes later, another scan:)

[ 1958.926214] queueing tx report request with sn 8
[ 1958.931871] received tx report with sn 0
[ 1959.077185] queueing tx report request with sn 12
[ 1959.081971] received tx report with sn 8
[ 1959.279810] queueing tx report request with sn 16
[ 1959.299858] received tx report with sn 12
[ 1959.425182] queueing tx report request with sn 20
[ 1959.429951] received tx report with sn 16
[ 1959.627801] queueing tx report request with sn 24
[ 1959.647852] received tx report with sn 20
[ 1959.773173] queueing tx report request with sn 28
[ 1959.777942] received tx report with sn 24
[ 1959.975800] queueing tx report request with sn 32
[ 1959.995844] received tx report with sn 216
[ 1960.121163] queueing tx report request with sn 36
[ 1960.125935] received tx report with sn 32
[ 1960.323788] queueing tx report request with sn 40
[ 1960.343840] received tx report with sn 36
[ 1960.469162] queueing tx report request with sn 44
[ 1960.473955] received tx report with sn 40
[ 1960.671784] queueing tx report request with sn 48
[ 1960.691711] received tx report with sn 44
[ 1960.817278] queueing tx report request with sn 52
[ 1960.822047] received tx report with sn 48
[ 1961.019780] queueing tx report request with sn 56
[ 1961.039704] received tx report with sn 52
[ 1961.165150] queueing tx report request with sn 60
[ 1961.169920] received tx report with sn 56
[ 1961.367772] queueing tx report request with sn 64
[ 1961.387701] received tx report with sn 60
[ 1961.535771] queueing tx report request with sn 68
[ 1961.535805] queueing tx report request with sn 72
[ 1961.536015] queueing tx report request with sn 76
[ 1961.537739] received tx report with sn 64
[ 1961.543622] received tx report with sn 76
[ 1961.543655] received tx report with sn 68
[ 1962.058691] rtw_8723du 1-1:1.2: still have 2 unprocessed tx report requests

Here the number of reports matches the number of requests.
I assume st is correct, but I'm not sure how to test that.

(5 minutes later, another scan:)

[ 2258.930888] queueing tx report request with sn 80
[ 2258.931968] received tx report with sn 72
[ 2259.074009] queueing tx report request with sn 84
[ 2259.075296] received tx report with sn 80
[ 2259.276268] queueing tx report request with sn 88
[ 2259.292578] received tx report with sn 84
[ 2259.417771] queueing tx report request with sn 92
[ 2259.421069] received tx report with sn 88
[ 2259.620249] queueing tx report request with sn 96
[ 2259.636439] received tx report with sn 0
[ 2259.761876] queueing tx report request with sn 100
[ 2259.763314] received tx report with sn 96
[ 2259.964239] queueing tx report request with sn 104
[ 2260.006304] received tx report with sn 100
[ 2260.129871] queueing tx report request with sn 108
[ 2260.131799] received tx report with sn 104
[ 2260.332240] queueing tx report request with sn 112
[ 2260.348426] received tx report with sn 108
[ 2260.473732] queueing tx report request with sn 116
[ 2260.475262] received tx report with sn 112
[ 2260.680223] queueing tx report request with sn 120
[ 2260.737903] received tx report with sn 116
[ 2260.870463] queueing tx report request with sn 124
[ 2260.885589] received tx report with sn 120
[ 2261.071970] queueing tx report request with sn 128
[ 2261.213583] queueing tx report request with sn 132
[ 2261.416138] queueing tx report request with sn 136
[ 2261.576217] queueing tx report request with sn 140
[ 2261.576323] queueing tx report request with sn 144
[ 2261.828937] received tx report with sn 124
[ 2262.090722] rtw_8723du 1-1:1.2: still have 6 unprocessed tx report requests
[ 2262.470953] queueing tx report request with sn 148
[ 2262.472454] received tx report with sn 144
[ 2262.986738] rtw_8723du 1-1:1.2: still have 1 unprocessed tx report requests

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

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

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

[Ping-Ke Shih]

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. 

[...]

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

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

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

[Bitterblue Smith]

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.

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.

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

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

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

[Ping-Ke Shih]

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

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

[Bitterblue Smith]

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

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

[Bitterblue Smith]

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

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

[Ping-Ke Shih]

Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> 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.

Then let's take the solution you newly found. :)

> 
> > FYI. Having the lunar New Year next week, I will not reply your mail soon.
> >
> 
> Have a good holiday!

Thanks. I'm getting back. 

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