RE: [rtw88] purge skb(s) not reported by firmware

[Tony Chuang]

> Subject: [rtw88] purge skb(s) not reported by firmware
> 
> Hi folks.
> I recently joined testing the rtw88 driver.
> In just a few days, I already catches such WARNING twice times:
> 
> 
> [ 4899.601656] rtw_pci 0000:05:00.0: failed to send h2c command
> [ 9084.661382] rtw_pci 0000:05:00.0: firmware failed to restore hardware
> setting
> [ 9085.167364] ------------[ cut here ]------------
> [ 9085.167370] purge skb(s) not reported by firmware
> [ 9085.167417] WARNING: CPU: 9 PID: 0 at
> drivers/net/wireless/realtek/rtw88/tx.c:155
> rtw_tx_report_purge_timer+0x20/0x50 [rtw88]
> [ 9085.167419] Modules linked in: uinput rfcomm xt_CHECKSUM
> xt_MASQUERADE xt_conntrack ipt_REJECT nf_nat_tftp nf_conntrack_tftp

...

> [ 9085.167596]  do_idle+0x1e4/0x280
> [ 9085.167599]  cpu_startup_entry+0x19/0x20
> [ 9085.167603]  start_secondary+0x162/0x1b0
> [ 9085.167606]  secondary_startup_64+0xb6/0xc0
> [ 9085.167610] ---[ end trace f734f2b1bc40ebdb ]---
> [12111.505901] rtw_pci 0000:05:00.0: failed to send h2c command
> [12111.505956] rtw_pci 0000:05:00.0: failed to send h2c command
> 
> 
> Yes, it seems like nothing bad happened, except frequent network disconnect.
> Unfortunately I don't know how exactly reproduce it.
> But I think if someone propose patch and this WARNING after applying
> didn't appears againn at least a week then we can assume that the
> problem is fixed.
> 

It seems like the firmware is not responsive, and is not reporting TX
status or consuming H2C commands.
The first trace dump "purge skb(s) not reported by firmware" will be
printed when driver timed-out for TX status report. It could happen
sometimes when driver turns power off too quickly after de-auth sent.
Or firmware just missed it. Originally I was thinking that the TX status
missing means that the firmware is not working, but seems it's not
true. So I think I might lower the print level (WARN() -> rtw_warn()).

But from your kernel log I can see that the h2c commands failed to
be sent to firmware, which means there's another things that cause
firmware to stall. It will be better if you can turn the debug masks on,
and reproduce it, to help me so see what happened.
To turn the debug masks on:
$ echo 0xffffffff > /sys/module/rtw88/parameters/debug_mask

Yan-Hsuan