From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from wolverine01.qualcomm.com ([199.106.114.254]) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1bkXD5-00011t-7A for ath10k@lists.infradead.org; Thu, 15 Sep 2016 14:00:19 +0000 From: "Valo, Kalle" Subject: Re: [PATCH v2 04/21] ath10k: rate-limit packet tx errors Date: Thu, 15 Sep 2016 13:59:48 +0000 Message-ID: <87sht1b6wc.fsf@kamboji.qca.qualcomm.com> References: <1462986153-16318-1-git-send-email-greearb@candelatech.com> <1462986153-16318-5-git-send-email-greearb@candelatech.com> <87wpieefr9.fsf@kamboji.qca.qualcomm.com> <57D96669.20209@candelatech.com> In-Reply-To: <57D96669.20209@candelatech.com> (Ben Greear's message of "Wed, 14 Sep 2016 08:02:01 -0700") Content-Language: en-US Content-ID: <571942CE57C08940933F53F9A3705739@qualcomm.com> MIME-Version: 1.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "ath10k" Errors-To: ath10k-bounces+kvalo=adurom.com@lists.infradead.org To: Ben Greear Cc: "linux-wireless@vger.kernel.org" , "ath10k@lists.infradead.org" Ben Greear writes: > On 09/14/2016 07:07 AM, Valo, Kalle wrote: >> greearb@candelatech.com writes: >> >>> From: Ben Greear >>> >>> 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 >>> --- >>> 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