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

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

Abdurrahman Karadag <abdurrahmankaradag19@gmail.com> wrote:
> > I re-think ring->queue_stopped and restart work. I feel the flow
> > should be [...]
> > I'll discuss above flow internally, and give back to you.

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

This can resolve two cases -- restart_hw and interface down/up while
queue_stopped is flagging. Just like initialize or reset to variables. 

No need 3 steps I mentioned. (So I'd not reply your trace.)

> Your other two questions were in the bug thread; bringing them here as
> you asked.
> 
> > could you describe how you resolve the stuck (by the method of your
> > previous patch, maybe v1)?
> 
> Nothing the driver did on its own. Over the five events, power save off:
> 
>   rewrite the TXBD host index   0/3   read index never moved
>   ip neigh flush                0/4
>   iwd reconnect, new PTK        2/4   cleared 08-28 20:32, 09-06 03:17
>   ip link set wlan0 down/up     1/2   cleared 09-14 17:48
>   reboot                              always

So there is no solution for now. Since 3th and 4th events will stop/start
pci, if the cause to fail to recovery is flagged queue_stopped, our above
idea will be helpful. 

Another test is to remove/insert driver ko. It will reset queue states.

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

[...]

> One thing I should flag before you read the dumps. My ladder pokes
> debugfs fw_crash anyway, so nine of the captures print
> "rtw_fw_recovery() tetikleniyor" - Turkish for "being triggered" - six
> on 27 September, two on 14 October, and one where the knob was not
> writable. Eight of them follow it with "fw_crash ->
> ieee80211_restart_hw: 100% packet loss". Both strings are labels my
> script prints for that rung, not anything the driver reported.
> rtw_debugfs_set_fw_crash() never calls rtw_fw_recovery(): it leaves deep
> LPS, sets RTW_FLAG_RESTART_TRIGGERING and writes REG_HRCV_MSG, and
> recovery is entered only through the C2H path I described on 3 October,
> which matches your point that the knob only takes effect on 8822C. So
> nothing was triggered and nothing was tested at that rung. Section 4 of
> the six September dumps also reads fw_crash as 1 before that dump's own
> write, because the file prints RTW_FLAG_RESTART_TRIGGERING and only
> __fw_recovery_work() clears it; all six are the same boot. The two
> October ones are later boots and read 0.

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