[RFTv2 2/5] ath10k: fix wmi-htc tx credit starvation

[Michal Kazior]

On 4 February 2015 at 11:55, Matti Laakso <malaakso at elisanet.fi> wrote:
> On 29 January 2015 at 02:32, YanBo <dreamfly281 at gmail.com> wrote:
>> Hi Michal,
>>
>> What the conclusion about this patch, it  looks like this patch not be
>> merged into ath10K due to introduce some unstable issue, I'v got
>> another issue that when move the station enter hibernate mode. the AP
>> will continue report message like before
>> [ 3958.681293] ath10k_pci 0000:01:00.0: Spurious quick kickout for STA
>> 00:03:7f:40:04:5b
>> [ 3959.681449] ath10k_pci 0000:01:00.0: Spurious quick kickout for STA
>> 00:03:7f:40:04:5b
>> [ 3960.681696] ath10k_pci 0000:01:00.0: Spurious quick kickout for STA
>> 00:03:7f:40:04:5b
>> [ 3961.681877] ath10k_pci 0000:01:00.0: Spurious quick kickout for STA
>> 00:03:7f:40:04:5b
>> [ 3962.682080] ath10k_pci 0000:01:00.0: Spurious quick kickout for STA
>> 00:03:7f:40:04:5b
>> [ 3963.682361] ath10k_pci 0000:01:00.0: Spurious quick kickout for STA
>> 00:03:7f:40:04:5b
>> [ 3964.682550] ath10k_pci 0000:01:00.0: Spurious quick kickout for STA
>> 00:03:7f:40:04:5b
>> [ 3965.682743] ath10k_pci 0000:01:00.0: Spurious quick kickout for STA
>> 00:03:7f:40:04:5b
>
> The spurious STA kickout alone is most likely an aftermath of HTX Tx
> credit starvation when client was detected as inactive by hostapd and
> was subsequently disassociated. However due to starvation
> wmi-peer-delete was never sent to firmware so fw thinks the peer is
> still there.
>
> I suppose fw should be restarted when ath10k is unable to submit a
> configuration command like wmi-peer-delete. It doesn't make sense to
> continue since fw-host state loses coherency and weird things can
> start to happen (spurious sta kickout is the best known example).
>
>
> Hi Michał,
>
> We've received some bug reports in OpenWrt (ath10k is from last November,
> firmware-3.bin_10.2-00082-4-2) about a similar issue (see e.g.
> https://dev.openwrt.org/ticket/18794 ), where spurious sta kickouts are
> reported, eventually leading to "number of peers exceeded" and the inability
> to connect more clients. After this happens a network restart usually causes
> an ath10k firmware crash. The clients that cause this are always mobile
> devices which regularly go in and out of the AP range. In my case this
> usually starts to happen after a couple of days' uptime.
>
> Do you think this is the same issue? Is there something I could do to help
> eventually fix this?

The crash could be unrelated. Otherwise it fits perfectly to the tx
credit starvation problem.

I tried playing around with using ath10k_htt_tx() to send mgmt frames
on 10.2 as raw tx but firmware discards them for some reason that I
haven't investigated yet.

Perhaps it's about time we roll out the workaround, i.e. perform fw
restart on tx credit timeout...


Michał