All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
Subject: Re: [PATCH 2/2] ath10k:  do not ratelimit ath10k_warn messages
Date: Thu, 13 Feb 2014 12:32:34 -0800	[thread overview]
Message-ID: <52FD2BE2.50706@candelatech.com> (raw)
In-Reply-To: <87fvnm7pml.fsf@kamboji.qca.qualcomm.com>

On 02/13/2014 11:56 AM, Kalle Valo wrote:
> greearb@candelatech.com writes:
> 
>> These are too important to miss, and if we ever do have some
>> that are overly verbose
> 
> The thing is that in some platforms excessive amount log messages will
> cause watchdog to forcefully reboot the device. So I'm hesitant to
> remove this.
> 
> First of all, the goal is that ath10k will never issue even a single
> warning message. So even if you see just one, it means something is
> wrong. And just seeing the first few warnings should give you a pretty
> good hint what's going on.

I see lots of EAGAIN (-11) warnings sometime, and they come in bunches
in my scenario (with lots of vifs).

> Secondly, it's not like net_ratelimit() will hide all the warning
> messages. It will still show some of the messages even if it starts to
> throttle them.

In my case, it hid exactly the messages I needed to see in a hard
to reproduce bug, so I was a bit peeved :P

>> could ratelimit the call to ath10k_warn instead of doing the ratelimit
>> inside of ath10k_warn.
> 
> Not sure if I got this idea. Only to ratelimit some of the warnings or
> what do you mean by ratelimiting it outside ath10k_warn()?

If there are warnings that are likely to spam continuously,
then ratelimit only those, so something like:

if (netratelimit()) {
  ath10k_warn(...)
}


But, this is an easy patch for me to carry, so no worries if it
doesn't go upstream.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

WARNING: multiple messages have this Message-ID (diff)
From: Ben Greear <greearb@candelatech.com>
To: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
Subject: Re: [PATCH 2/2] ath10k:  do not ratelimit ath10k_warn messages
Date: Thu, 13 Feb 2014 12:32:34 -0800	[thread overview]
Message-ID: <52FD2BE2.50706@candelatech.com> (raw)
In-Reply-To: <87fvnm7pml.fsf@kamboji.qca.qualcomm.com>

On 02/13/2014 11:56 AM, Kalle Valo wrote:
> greearb@candelatech.com writes:
> 
>> These are too important to miss, and if we ever do have some
>> that are overly verbose
> 
> The thing is that in some platforms excessive amount log messages will
> cause watchdog to forcefully reboot the device. So I'm hesitant to
> remove this.
> 
> First of all, the goal is that ath10k will never issue even a single
> warning message. So even if you see just one, it means something is
> wrong. And just seeing the first few warnings should give you a pretty
> good hint what's going on.

I see lots of EAGAIN (-11) warnings sometime, and they come in bunches
in my scenario (with lots of vifs).

> Secondly, it's not like net_ratelimit() will hide all the warning
> messages. It will still show some of the messages even if it starts to
> throttle them.

In my case, it hid exactly the messages I needed to see in a hard
to reproduce bug, so I was a bit peeved :P

>> could ratelimit the call to ath10k_warn instead of doing the ratelimit
>> inside of ath10k_warn.
> 
> Not sure if I got this idea. Only to ratelimit some of the warnings or
> what do you mean by ratelimiting it outside ath10k_warn()?

If there are warnings that are likely to spam continuously,
then ratelimit only those, so something like:

if (netratelimit()) {
  ath10k_warn(...)
}


But, this is an easy patch for me to carry, so no worries if it
doesn't go upstream.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


  reply	other threads:[~2014-02-13 20:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-13 19:09 [PATCH 1/2] ath10k: add vdev-id, return code to error codes greearb
2014-02-13 19:09 ` greearb
2014-02-13 19:09 ` [PATCH 2/2] ath10k: do not ratelimit ath10k_warn messages greearb
2014-02-13 19:09   ` greearb
2014-02-13 19:56   ` Kalle Valo
2014-02-13 19:56     ` Kalle Valo
2014-02-13 20:32     ` Ben Greear [this message]
2014-02-13 20:32       ` Ben Greear
2014-02-14  6:06 ` [PATCH 1/2] ath10k: add vdev-id, return code to error codes Kalle Valo
2014-02-14  6:06   ` Kalle Valo
2014-02-14 15:33   ` Ben Greear
2014-02-14 15:33     ` Ben Greear
2014-03-03 15:32     ` Kalle Valo
2014-03-03 15:32       ` Kalle Valo
2014-02-26 18:28   ` Ben Greear
2014-02-26 18:28     ` Ben Greear
2014-02-27  8:43     ` Kalle Valo
2014-02-27  8:43       ` Kalle Valo
2014-03-03 15:39 ` Kalle Valo
2014-03-03 15:39   ` Kalle Valo

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=52FD2BE2.50706@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=ath10k@lists.infradead.org \
    --cc=kvalo@qca.qualcomm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.