From: "Valo, Kalle" <kvalo@qca.qualcomm.com>
To: Ben Greear <greearb@candelatech.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>
Subject: Re: [PATCH v2 04/21] ath10k: rate-limit packet tx errors
Date: Thu, 15 Sep 2016 13:59:48 +0000 [thread overview]
Message-ID: <87sht1b6wc.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <57D96669.20209@candelatech.com> (Ben Greear's message of "Wed, 14 Sep 2016 08:02:01 -0700")
Ben Greear <greearb@candelatech.com> writes:
> On 09/14/2016 07:07 AM, Valo, Kalle wrote:
>> greearb@candelatech.com writes:
>>
>>> From: Ben Greear <greearb@candelatech.com>
>>>
>>> When firmware crashes, stack can continue to send packets
>>> for a bit, and existing code was spamming logs.
>>>
>>> So, rate-limit the error message for tx failures.
>>>
>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>> ---
>>> drivers/net/wireless/ath/ath10k/mac.c | 5 +++--
>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
>>> index cd3016d..42cac32 100644
>>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>>> @@ -3432,8 +3432,9 @@ static int ath10k_mac_tx_submit(struct ath10k *ar,
>>> }
>>>
>>> if (ret) {
>>> - ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
>>> - ret);
>>> + if (net_ratelimit())
>>> + ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
>>> + ret);
>>> ieee80211_free_txskb(ar->hw, skb);
>>> }
>>
>> ath10k_warn() is already rate limited. If there's something wrong then
>> that function should be fixed, not the callers.
>>
>> void ath10k_warn(struct ath10k *ar, const char *fmt, ...)
>> {
>> struct va_format vaf = {
>> .fmt = fmt,
>> };
>> va_list args;
>>
>> va_start(args, fmt);
>> vaf.va = &args;
>> dev_warn_ratelimited(ar->dev, "%pV", &vaf);
>> trace_ath10k_log_warn(ar, &vaf);
>>
>> va_end(args);
>> }
>
> The problem with having the ratelimit here is that you may miss
> rare warnings due to a flood of common warnings.
>
> That is why it is still useful to ratelimit potential floods
> of warnings.
I think this is a common problem in kernel, not specific to ath10k. For
starters you could configure the limits dev_warn_ratelimited() has, not
trying to workaround it in the driver.
> I would like to remove the ratelimit from ath10k_warn eventually.
I think that's not a good idea, it might cause unnecessary host reboots
in problem cases. Rate limitting the messages is much better option.
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2016-09-15 14:00 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-11 17:02 [PATCH v2 00/21] ath10k patches, generic and CT firmware related greearb
2016-05-11 17:02 ` [PATCH v2 01/21] ath10k: Fix crash related to printing features greearb
2016-06-07 11:38 ` [v2,01/21] " Kalle Valo
2016-06-20 20:49 ` [PATCH v2 01/21] " Ben Greear
2016-06-20 21:56 ` Valo, Kalle
2016-05-11 17:02 ` [PATCH v2 02/21] ath10k: fix typo in logging message greearb
2016-09-27 12:19 ` [v2,02/21] " Kalle Valo
2016-05-11 17:02 ` [PATCH v2 03/21] ath10k: Allow changing ath10k debug mask at runtime greearb
2016-09-14 14:06 ` Valo, Kalle
2016-09-14 15:33 ` Ben Greear
2016-09-15 14:19 ` Valo, Kalle
2016-09-15 15:07 ` Ben Greear
2016-05-11 17:02 ` [PATCH v2 04/21] ath10k: rate-limit packet tx errors greearb
2016-09-14 14:07 ` Valo, Kalle
2016-09-14 15:02 ` Ben Greear
2016-09-15 13:59 ` Valo, Kalle [this message]
2016-09-15 15:22 ` Ben Greear
2016-05-11 17:02 ` [PATCH v2 05/21] ath10k: save firmware debug log messages greearb
2016-05-11 17:02 ` [PATCH v2 06/21] ath10k: save firmware stacks upon firmware crash greearb
2016-05-11 17:02 ` [PATCH v2 07/21] ath10k: save firmware RAM and ROM BSS sections on crash greearb
2016-05-11 17:02 ` [PATCH v2 08/21] ath10k: make firmware text debug messages more verbose greearb
2016-09-14 14:12 ` Valo, Kalle
2016-09-14 15:06 ` Ben Greear
2016-09-15 14:02 ` Valo, Kalle
2016-09-15 15:17 ` Ben Greear
2016-05-11 17:02 ` [PATCH v2 09/21] ath10k: print fw debug messages in hex greearb
2016-09-14 14:18 ` Valo, Kalle
2016-09-14 15:13 ` Ben Greear
2016-09-15 14:06 ` Valo, Kalle
2016-09-15 15:14 ` Ben Greear
2016-09-15 17:34 ` Grumbach, Emmanuel
2016-09-15 17:59 ` Ben Greear
2016-09-15 18:08 ` Ben Greear
2016-09-15 20:22 ` Grumbach, Emmanuel
2016-05-11 17:02 ` [PATCH v2 10/21] ath10k: support logging ath10k_info as KERN_DEBUG greearb
2016-09-14 14:19 ` Valo, Kalle
2016-09-14 15:14 ` Ben Greear
2016-09-15 14:12 ` Valo, Kalle
2016-09-15 15:11 ` Ben Greear
2016-05-11 17:02 ` [PATCH v2 11/21] ath10k: add fw-powerup-fail to ethtool stats greearb
2016-09-14 14:25 ` Valo, Kalle
2016-09-14 15:19 ` Ben Greear
2016-05-11 17:02 ` [PATCH v2 12/21] ath10k: Support up to 64 vdevs greearb
2016-09-14 15:01 ` Valo, Kalle
2016-05-11 17:02 ` [PATCH v2 13/21] ath10k: Document cycle count related counters greearb
2016-05-11 17:02 ` [PATCH v2 14/21] ath10k: Add tx/rx bytes, cycle counters to ethtool stats greearb
2016-05-11 17:02 ` [PATCH v2 15/21] ath10k: support CT firmware flag greearb
2016-09-14 14:30 ` Valo, Kalle
2016-09-14 15:24 ` Ben Greear
2016-09-15 14:15 ` Valo, Kalle
2016-09-15 14:43 ` Ben Greear
2016-05-11 17:02 ` [PATCH v2 16/21] ath10k: Support 32+ stations greearb
2016-05-11 17:02 ` [PATCH v2 17/21] ath10k: Enable detecting failure to install key in firmware (CT) greearb
2016-05-11 17:02 ` [PATCH v2 18/21] ath10k: Note limitation on beaconing vdevs greearb
2016-05-11 17:02 ` [PATCH v2 19/21] ath10k: Enable adhoc mode for CT firmware greearb
2016-09-14 14:37 ` Valo, Kalle
2016-09-14 15:28 ` Ben Greear
2016-05-11 17:02 ` [PATCH v2 20/21] ath10k: read firmware crash over ioread32 if CE fails greearb
2016-05-11 17:02 ` [PATCH v2 21/21] ath10k: Read dbglog buffers over register ping-pong greearb
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=87sht1b6wc.fsf@kamboji.qca.qualcomm.com \
--to=kvalo@qca.qualcomm.com \
--cc=ath10k@lists.infradead.org \
--cc=greearb@candelatech.com \
--cc=linux-wireless@vger.kernel.org \
/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