Luka Gejak <luka.gejak@linux.dev> wrote:
> On August 25, 2026 6:33:08 PM GMT+02:00, luka.gejak@linux.dev wrote:
> >From: Luka Gejak <luka.gejak@linux.dev>
> >
> >This is the first of two series adding support for the Realtek RTL8723B
> >802.11n chipset and its RTL8723BS SDIO variant to rtw88. It contains
> >only the changes to the shared rtw88 core that the chip driver depends
> >on. The chip itself, the build glue and the MAINTAINERS entry are a
> >second series.
> >
> 
> ...
> 
> Hi Ping-Ke,
> 
> A tester has been running v8 on a slow ARM SDIO board. In a good signal
> environment it passes a thousand iterations of his stress test with
> nothing in the log. In a poor one he still gets "failed to get tx report
> from firmware", and a reconnection along with it. Power save was off for
> both.
> 
> Looking at why, the two ends of the tx report path are not symmetric:
> 
>   rtw_tx_report_handle() -> rtw_tx_report_tx_status()
>                          -> ieee80211_tx_status_irqsafe()
> 
>   rtw_tx_report_purge_timer() -> skb_queue_purge()

I think it should use ieee80211_purge_tx_queue() instead of skb_queue_purge().

> 
> When the report arrives mac80211 gets a verdict. When it does not, the
> frames are freed with kfree_skb() and mac80211 is told nothing at all.
> rtw_tx_report_enqueue() also re-arms the timer on every frame, so it
> fires once, 500 ms after the last enqueue, and purges everything
> outstanding, including frames queued a moment earlier.

I guess it'd simplify the design that it extends lifetime of queued frames
once a new one is queued. 

> 
> One of the frames that asks for a report is the nullfunc mac80211 sends
> to poll a link it suspects is dead. If no status comes back,
> ieee80211_sta_tx_notify() is never called, the poll counts as
> unanswered, and mac80211 tears the connection down. That fits what the
> tester sees: the warning and the reconnection arriving together, and
> only when the signal is poor enough for reports to go missing.
> 
> Raising the timeout further does not look like the answer. Patch 3 of
> this series already takes it to 2500 ms for the RTL8723BS, five times
> the default, and he still reaches it. A longer wait only delays the
> status.

I think the timeout relies on 
   static int probe_wait_ms = 500;
   module_param(probe_wait_ms, int, 0644);

So, if you enlarge the timeout in rtw_tx_report_enqueue() over 500ms,
it can't help the case.

Maybe, you can set larger number to module parameter probe_wait_ms to
see if it can help.

> 
> What looks right to me is to report the frames instead of dropping
> them: walk the queue on timeout and hand each one back with
> rtw_tx_report_tx_status(rtwdev, cur, false). That tells mac80211 the
> frame was not acknowledged, which is true, and lets it act rather than
> wait for a status that will never come. It would also stop mac80211 TX
> skbs being freed with kfree_skb() instead of being returned through
> ieee80211_tx_status().

As the comment:

 * Calls to this function, ieee80211_tx_status_skb() and
 * ieee80211_tx_status_ni() may not be mixed for a single hardware.

Should use ieee80211_tx_status_irqsafe(). 

But I feel this case, using ieee80211_purge_tx_queue() is equivalent?

> 
> That is core behaviour for every chip, not just this one, so I would
> rather ask than send it. Would you want it as a separate patch outside
> this series? 

This looks an independent patch. If you want to go faster, a separate
patch is better. If you don't concern the time, putting together with
your patchset is okay to me.

> And is reporting "not acked" what you would want on the
> other parts, or would you rather the timeout stayed silent for them and
> only this chip changed?

If using ieee80211_purge_tx_queue() can get positive result, no need
special condition for certain chips. 

Hi Ping-Ke,
On August 31, 2026 4:23:48 AM GMT+02:00, Ping-Ke Shih <pkshih@realtek.com> wrote:

The probe_wait_ms test you suggested has run, nine hours in the tester's
poor signal environment. At 2000 ms he saw one "Failed to send nullfunc
... disconnecting". At 500 ms it was one every twenty to forty seconds.
Same environment, same driver.

The reports are late rather than missing:

  txrpt: nullfunc sn=f0 queued
  wlan0: Failed to send nullfunc to AP after 500ms, disconnecting
  txrpt: nullfunc sn=f0 acked after 810ms

The frame was acknowledged and the link was alive. Nullfunc reports run
400 to 1000 ms on this chip when the link is poor, against 0 to 20 ms
for management frames on the same hardware, so it is firmware retry
time.

That also rules out the timeout path as the mechanism. It fires 2500 ms
after the last enqueue, well after mac80211 has given up, and a build
that handed the frames back as not acked instead of dropping them made
no difference. The sequence number aliasing I raised does not show up
either: every instance had one frame in the queue.

So there is nothing here for the driver to fix, and probe_wait_ms is not
something a driver can set. I am not proposing anything for it.

> But I feel this case, using ieee80211_purge_tx_queue() is equivalent?

Not equivalent. ieee80211_purge_tx_queue() calls ieee80211_free_txskb(),
which calls ieee80211_report_used_skb() with dropped = true: that
settles the airtime accounting and frees the skb properly, but never
reaches ieee80211_sta_tx_notify(). Only ieee80211_tx_status_*() does. It
fixes the ownership bug and tells the connection poll nothing, which
given the above does not matter.

Still worth doing on its own. I will send it separately, no chip
condition.

Best regards,
Luka Gejak

Luka Gejak <luka.gejak@linux.dev> wrote:
> Hi Ping-Ke,
> On August 31, 2026 4:23:48 AM GMT+02:00, Ping-Ke Shih <pkshih@realtek.com> wrote:
> 
> The probe_wait_ms test you suggested has run, nine hours in the tester's
> poor signal environment. At 2000 ms he saw one "Failed to send nullfunc
> ... disconnecting". At 500 ms it was one every twenty to forty seconds.
> Same environment, same driver.

Without proper quota message, I need coming back to previous mail and finding
out the stuff you want to discuss...

I don't know how bad the poor signal environment was. But 2000ms looks very
strange to me, it is too large. Have you captured air sniffer to see what
happened? 

I think we can check three points
1) If the probe uses low rate (e.g. 6M)
2) signal strength  
3) signal quality 
   Without hardware equipment, this is hard to us. I think we can compare
   the link rate with other WiFi card at the same distance far from AP.


> 
> > But I feel this case, using ieee80211_purge_tx_queue() is equivalent?
> 
> Not equivalent. ieee80211_purge_tx_queue() calls ieee80211_free_txskb(),
> which calls ieee80211_report_used_skb() with dropped = true: that
> settles the airtime accounting and frees the skb properly, but never
> reaches ieee80211_sta_tx_notify(). Only ieee80211_tx_status_*() does. It
> fixes the ownership bug and tells the connection poll nothing, which
> given the above does not matter.

The ieee80211_purge_tx_queue() I mentioned is to reference to the point:

> >   rtw_tx_report_purge_timer() -> skb_queue_purge()
> I think it should use ieee80211_purge_tx_queue() instead of skb_queue_purge().

Ping-Ke Shih <pkshih@realtek.com> wrote:
> Without proper quota message, I need coming back to previous mail and finding
> out the stuff you want to discuss...

Sorry, my last reply dropped your text. Quoting properly from here.

> I don't know how bad the poor signal environment was. But 2000ms looks very
> strange to me, it is too large. Have you captured air sniffer to see what
> happened?
>
> I think we can check three points
> 1) If the probe uses low rate (e.g. 6M)
> 2) signal strength
> 3) signal quality

Agreed that 2000 ms is not a sane number, and I am not proposing it as
one. I raised it only because it separates a late report from a missing
one, and it did.

No air capture: that is the tester's board and environment, not mine, so
I cannot sniff it. I will ask him for the three points above.

The one measurement I do have that speaks to all three is a comparison
within the same link and the same window. Nullfunc reports come back in
400 to 1000 ms, worst case 1460 ms (appeared only once), while management
frames on that same link come back in 0 to 20 ms. A 6M probe rate or a weak
signal would slow both, so whatever is happening is specific to the nullfunc
path rather than to the air, and it looks like firmware retry time.

So I am not asking for anything here and there is no patch attached to
it. If his three answers say otherwise I will come back with them.

> The ieee80211_purge_tx_queue() I mentioned is to reference to the point:
>
>>>   rtw_tx_report_purge_timer() -> skb_queue_purge()
>> I think it should use ieee80211_purge_tx_queue() instead of skb_queue_purge().

Understood, and that is what I have. I answered a question you had not
asked last time.

  wifi: rtw88: tx: hand timed out TX report frames back to mac80211

No chip condition. It is the same pattern rtw_txq_push_skb() already
uses in rtw-next, which hands the skb back with ieee80211_free_txskb()
when the HCI write fails, applied to the report timeout instead.

I will send it together with the SDIO padding fix once the preparation
series is applied, to keep them out of the way while that is in review.

Best regards,
Luka Gejak