* [PATCH 1/2] mac80211: Make beacon-loss-count configurable.
@ 2013-03-19 21:19 greearb
2013-03-19 21:19 ` [PATCH 2/2] mac80211: Make un-found-rate splat a warn-once greearb
2013-03-22 10:31 ` [PATCH 1/2] mac80211: Make beacon-loss-count configurable Johannes Berg
0 siblings, 2 replies; 6+ messages in thread
From: greearb @ 2013-03-19 21:19 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear
From: Ben Greear <greearb@candelatech.com>
On loaded systems with lots of VIFs, I see lots of beacon
timeouts, even though the connection to the AP is very
good. Allow tuning the beacon-loss-count variable to
give the system longer to process beacons if the user
prefers.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 da805e2... 1f1e889... M net/mac80211/mlme.c
net/mac80211/mlme.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index da805e2..1f1e889 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -54,7 +54,10 @@ MODULE_PARM_DESC(max_probe_tries,
* probe on beacon miss before declaring the connection lost
* default to what we want.
*/
-#define IEEE80211_BEACON_LOSS_COUNT 7
+static int beacon_loss_count = 7;
+module_param(beacon_loss_count, int, 0644);
+MODULE_PARM_DESC(beacon_loss_count,
+ "Number of beacon intervals before we decide beacon was lost.");
/*
* Time the connection can be idle before we probe
@@ -1319,7 +1322,7 @@ static void ieee80211_set_associated(struct ieee80211_sub_if_data *sdata,
bss_conf->assoc_capability, bss->has_erp_value, bss->erp_value);
sdata->u.mgd.beacon_timeout = usecs_to_jiffies(ieee80211_tu_to_usec(
- IEEE80211_BEACON_LOSS_COUNT * bss_conf->beacon_int));
+ beacon_loss_count * bss_conf->beacon_int));
sdata->u.mgd.associated = cbss;
memcpy(sdata->u.mgd.bssid, cbss->bssid, ETH_ALEN);
--
1.7.3.4
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH 2/2] mac80211: Make un-found-rate splat a warn-once.
2013-03-19 21:19 [PATCH 1/2] mac80211: Make beacon-loss-count configurable greearb
@ 2013-03-19 21:19 ` greearb
2013-03-22 10:28 ` Johannes Berg
2013-03-22 10:31 ` [PATCH 1/2] mac80211: Make beacon-loss-count configurable Johannes Berg
1 sibling, 1 reply; 6+ messages in thread
From: greearb @ 2013-03-19 21:19 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear
From: Ben Greear <greearb@candelatech.com>
After that, print it out with net_ratelimit. We saw a system
continually hit this warning, for reasons unknown, and it
seems it bogged the system down enough to make it go OOM.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 e03a8e9... 2eab7d8... M net/mac80211/tx.c
net/mac80211/tx.c | 26 +++++++++++++++++++-------
1 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index e03a8e9..2eab7d8 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -672,14 +672,26 @@ ieee80211_tx_h_rate_ctrl(struct ieee80211_tx_data *tx)
* Lets not bother rate control if we're associated and cannot
* talk to the sta. This should not happen.
*/
- if (WARN(test_bit(SCAN_SW_SCANNING, &tx->local->scanning) && assoc &&
- !rate_usable_index_exists(sband, &tx->sta->sta),
- "%s: Dropped data frame as no usable bitrate found while "
- "scanning and associated. Target station: "
- "%pM on %d GHz band\n",
- tx->sdata->name, hdr->addr1,
- info->band ? 5 : 2))
+ if (test_bit(SCAN_SW_SCANNING, &tx->local->scanning) && assoc &&
+ !rate_usable_index_exists(sband, &tx->sta->sta)) {
+ static bool do_once = true;
+ if (do_once) {
+ WARN(1, "%s: Dropped data frame as no usable bitrate found while "
+ "scanning and associated. Target station: "
+ "%pM on %d GHz band\n",
+ tx->sdata->name, hdr->addr1,
+ info->band ? 5 : 2);
+ do_once = false;
+ }
+ else {
+ net_info_ratelimited("%s: Dropped data frame as no usable bitrate found while "
+ "scanning and associated. Target station: "
+ "%pM on %d GHz band\n",
+ tx->sdata->name, hdr->addr1,
+ info->band ? 5 : 2);
+ }
return TX_DROP;
+ }
/*
* If we're associated with the sta at this point we know we can at
--
1.7.3.4
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH 2/2] mac80211: Make un-found-rate splat a warn-once.
2013-03-19 21:19 ` [PATCH 2/2] mac80211: Make un-found-rate splat a warn-once greearb
@ 2013-03-22 10:28 ` Johannes Berg
2013-03-22 15:59 ` Ben Greear
0 siblings, 1 reply; 6+ messages in thread
From: Johannes Berg @ 2013-03-22 10:28 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless
On Tue, 2013-03-19 at 14:19 -0700, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> After that, print it out with net_ratelimit. We saw a system
> continually hit this warning, for reasons unknown, and it
> seems it bogged the system down enough to make it go OOM.
I'm not really sure I like this ... that points to a deeper problem, and
this just papers over it while causing more cost in the TX path for all
the different checks.
johannes
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/2] mac80211: Make beacon-loss-count configurable.
2013-03-19 21:19 [PATCH 1/2] mac80211: Make beacon-loss-count configurable greearb
2013-03-19 21:19 ` [PATCH 2/2] mac80211: Make un-found-rate splat a warn-once greearb
@ 2013-03-22 10:31 ` Johannes Berg
1 sibling, 0 replies; 6+ messages in thread
From: Johannes Berg @ 2013-03-22 10:31 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless
On Tue, 2013-03-19 at 14:19 -0700, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> On loaded systems with lots of VIFs, I see lots of beacon
> timeouts, even though the connection to the AP is very
> good. Allow tuning the beacon-loss-count variable to
> give the system longer to process beacons if the user
> prefers.
Applied, I also added the number to the message, just in case somebody
sets it to 0 or 1 or something like that ... :-)
johannes
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/2] mac80211: Make un-found-rate splat a warn-once.
2013-03-22 10:28 ` Johannes Berg
@ 2013-03-22 15:59 ` Ben Greear
2013-04-03 12:41 ` Johannes Berg
0 siblings, 1 reply; 6+ messages in thread
From: Ben Greear @ 2013-03-22 15:59 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
On 03/22/2013 03:28 AM, Johannes Berg wrote:
> On Tue, 2013-03-19 at 14:19 -0700, greearb@candelatech.com wrote:
>> From: Ben Greear <greearb@candelatech.com>
>>
>> After that, print it out with net_ratelimit. We saw a system
>> continually hit this warning, for reasons unknown, and it
>> seems it bogged the system down enough to make it go OOM.
>
> I'm not really sure I like this ... that points to a deeper problem, and
> this just papers over it while causing more cost in the TX path for all
> the different checks.
If I add an 'unlikely' to the initial check, that gets back to the original
TX path cost, or are you worried about something else?
I think in most cases we should be using some variation of WARN_ONCE
in all the places that splat a warning...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/2] mac80211: Make un-found-rate splat a warn-once.
2013-03-22 15:59 ` Ben Greear
@ 2013-04-03 12:41 ` Johannes Berg
0 siblings, 0 replies; 6+ messages in thread
From: Johannes Berg @ 2013-04-03 12:41 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
On Fri, 2013-03-22 at 08:59 -0700, Ben Greear wrote:
> On 03/22/2013 03:28 AM, Johannes Berg wrote:
> > On Tue, 2013-03-19 at 14:19 -0700, greearb@candelatech.com wrote:
> >> From: Ben Greear <greearb@candelatech.com>
> >>
> >> After that, print it out with net_ratelimit. We saw a system
> >> continually hit this warning, for reasons unknown, and it
> >> seems it bogged the system down enough to make it go OOM.
> >
> > I'm not really sure I like this ... that points to a deeper problem, and
> > this just papers over it while causing more cost in the TX path for all
> > the different checks.
>
> If I add an 'unlikely' to the initial check, that gets back to the original
> TX path cost, or are you worried about something else?
>
> I think in most cases we should be using some variation of WARN_ONCE
> in all the places that splat a warning...
Let's just make this WARN_ONCE() then maybe?
johannes
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-04-03 12:41 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-03-19 21:19 [PATCH 1/2] mac80211: Make beacon-loss-count configurable greearb
2013-03-19 21:19 ` [PATCH 2/2] mac80211: Make un-found-rate splat a warn-once greearb
2013-03-22 10:28 ` Johannes Berg
2013-03-22 15:59 ` Ben Greear
2013-04-03 12:41 ` Johannes Berg
2013-03-22 10:31 ` [PATCH 1/2] mac80211: Make beacon-loss-count configurable Johannes Berg
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).