Re: [PATCH rtw-next v2] wifi: rtw88: pci: wake the TX queues when the rings are reset

[Abdurrahman Karadag]

> I discussed internally, and we suggest to add ieee80211_wake_queues()
> and clear queue_stopped flags in rtw_pci_start().

Done, sent as v4, with restart_hw named in the subject as you asked.

One difference: the flags are reset unconditionally, the wake is not.
mac80211 keeps one non-refcounted DRIVER slot per queue, and
rtw_hw_scan_start() takes it shortly before it reaches rtw_pci_start()
from idle, so an unconditional wake would release the scan's stop too.
This does not resolve stop ownership when a ring stop and a scan stop
overlap; it only skips the wake when no ring was recorded as stopped.

What is measured and what is not: the controlled A/B is on v3. Two
builds differing by nothing but the patch, the ring filling on its own
under load with no TXPAUSE write, the restart the only thing I
triggered. Unpatched left the DRIVER stop dangling and the link dead;
patched woke the queue and traffic returned. v4 has not been through
that test - it sits earlier on the same start path, so I expect it to
cover the same case, but that is reasoning, not a measurement.

> Another test is to remove/insert driver ko.

Not done - my script stops at iface down/up, so it has never run on a
live wedge. I am adding it, by hand rather than unattended.

> (I suppose you did these tests without changing any behavior as was).

Mostly. Most captures are on the stock distribution driver. Two builds
differ: one carries a five-line debug.c change of mine, one is the
c95323ea9dfb revert you asked me to try.

> I need your help to summarize the dumps. I don't have much time to
> analyze them. Sorry.

A watchdog takes a capture when the gateway stops answering, reads the
TX ring indices and the mac80211 stop masks a few times seconds apart,
then walks a short recovery ladder.

They fall into two main groups: stalled TX rings, and a dead link
despite continuing ring progress. In the first the hardware read index
stops advancing while the ring fills behind it, and in a couple it had
filled and the queue was stopped - the state v4 clears. In this group
recovery was observed only after reconnect or interface down/up. The
second group is the larger one and I have nothing for it; that is what
the monitor capture would be for. The patch does not claim to address
every link loss.

What the captures do not give me is a case where the wake would have
recovered the link. The three with the BE stop bit I listed on 10
October are still the only ones in that state, and none is a clean
test: one had no ladder run against it, one is power-save-on, and in
the third the read index was still advancing.

Checks so far, in case they save you time. REG_TXPAUSE reads 0x00
except in the power-save-on captures. disable_aspm made no difference,
and it does not disable host ASPM anyway. The correctable PCIe receiver
errors appear on a healthy link too. The wedge also occurs with station
power save off, so enabling it is not required to reproduce the failure.

One observation I cannot place: HISR0 reads the same value in every
capture that samples it, with none of those bits covered by
irq_mask[0]. I have not established any connection to the link loss.

Two things in the dumps would mislead you. The fw_crash rung measured
nothing, as I flagged - those lines are my script's labels, not driver
output. And the "SINIF:" line is computed from the first sample only.

I can send you the raw captures if they would help.