From: Ben Greear <greearb@candelatech.com>
To: Michal Kazior <michal.kazior@tieto.com>
Cc: "ath10k@lists.infradead.org" <ath10k@lists.infradead.org>,
linux-wireless <linux-wireless@vger.kernel.org>,
Matti Laakso <malaakso@elisanet.fi>
Subject: Re: [RFT] ath10k: restart fw on tx-credit timeout
Date: Tue, 10 Feb 2015 09:01:11 -0800 [thread overview]
Message-ID: <54DA3957.10402@candelatech.com> (raw)
In-Reply-To: <CA+BoTQk9C_7efUs6VTZrEz5ECxsvCgfA8ObrAXKjqMpTL8pggA@mail.gmail.com>
On 02/09/2015 10:09 PM, Michal Kazior wrote:
> On 9 February 2015 at 17:03, Ben Greear <greearb@candelatech.com> wrote:
>> On 02/08/2015 10:24 PM, Michal Kazior wrote:
>>> On 6 February 2015 at 17:15, Ben Greear <greearb@candelatech.com> wrote:
> [...]
>>>> At least in my tests, I could continue
>>>> to receive network traffic while WMI was blocked.
>>>
>>>
>>> Yeah. Traffic works with the tx-credit starvation as well but what
>>> good is this if you have inconsistent driver-firmware state after
>>> failing to send a few commands?
>>
>>
>> I just mention it because someone debugging the system might
>> wonder why the firmware is 'locked up' while it is still passing traffic.
>
> I might as well include this info in the commit log.
>
>
>> If it is just powersave issue, could you force (overriding wmi tx-credits
>> limit)
>> a flush at the 1 second mark and hope it recovers by 3 second timeout?
>
> Well, there's a couple of problems with that.
>
> 1) you suggest to call wmi_flush() which calls wmi_cmd_send() *while*
> in wmi_cmd_send(),
> 2) you're out of credits, how do you intend to submit a frame,
> 3) yes, you can force it, but that's super ugly,
> 4) and this still doesn't guarantee you'll get your tx-credit due to
> firmware quirkiness.
If you do force the wmi send, ignoring credits, and even if you are running
stock firmware with wmi credits replenishment issues, then you at least
have a chance of recovering. (Upstream firmware requires lots of WMI messages
to flush, I think..like you can only flush per peer or something like that,
so maybe there is no realistic way to flush with small number of WMI messages.)
I've hacked CT firmware to do a flush of all vdevs itself when it detects WMI hang.
I don't have a good test bed to reproduce the problem reliably, but I should know
after a few days if the flush works at all. If not, then it's a moot point anyway.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2015-02-10 17:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-06 12:05 [RFT] ath10k: restart fw on tx-credit timeout Michal Kazior
2015-02-06 16:15 ` Ben Greear
2015-02-09 6:24 ` Michal Kazior
2015-02-09 16:03 ` Ben Greear
2015-02-10 6:09 ` Michal Kazior
2015-02-10 17:01 ` Ben Greear [this message]
2015-02-11 22:25 ` Ben Greear
2015-02-12 6:55 ` Michal Kazior
2015-02-12 13:21 ` Ben Greear
2015-02-11 13:30 ` Matti Laakso
2015-02-14 8:35 ` Matti Laakso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54DA3957.10402@candelatech.com \
--to=greearb@candelatech.com \
--cc=ath10k@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=malaakso@elisanet.fi \
--cc=michal.kazior@tieto.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).