[PATCH 1/2] mac80211: Make beacon-loss-count configurable.

[PATCH 1/2] mac80211: Make beacon-loss-count configurable.

[greearb]

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

[PATCH 2/2] mac80211: Make un-found-rate splat a warn-once.

[greearb]

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

Re: [PATCH 2/2] mac80211: Make un-found-rate splat a warn-once.

[Johannes Berg]

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

Re: [PATCH 1/2] mac80211: Make beacon-loss-count configurable.

[Johannes Berg]

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

Re: [PATCH 2/2] mac80211: Make un-found-rate splat a warn-once.

[Ben Greear]

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

Re: [PATCH 2/2] mac80211: Make un-found-rate splat a warn-once.

[Johannes Berg]

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