Prev: Staging: cxt1e1: Fix build error
Next: [PATCH 2.6.34-rc6] mxc: gadget: Fix bitfield for calculating maximum packet size
From: Nils Radtke on 20 May 2010 10:20

Hi,

# > Attached the output from the debug-enabled in-tree iwlwifi driver connects.
# To keep track, this is 2.6.33.3.

# So from what I can tell (to summarize your previous emails) there are
# three issues:
# 1) Error messages like:
# iwlagn 0000:03:00.0: expected_tpt should have been calculated by now
#
# 2) Frequent deaths with code like:
# eth1: deauthenticated from 00:40:96:aa:aa:aa (Reason: 2)
Appropriate misspelling, I assume, no pun intended? ;)

#
# 3) Error as follows:
# [ 4148.141064] iwlagn 0000:03:00.0: TX Power requested while scanning!
# [ 4148.141070] iwlagn 0000:03:00.0: Error sending TX power (-11)

This is correct.

#
# To address (1), could you please run with attached debug patch and also
# enable rate scaling debugging. That will be "modprobe iwlagn
# debug=0x143fff).
drivers/net/wireless/iwlwifi/iwl-agn-rs.c: In function 'rs_collect_tx_data':
drivers/net/wireless/iwlwifi/iwl-agn-rs.c:364: error: 'priv' undeclared (first use in this function)
drivers/net/wireless/iwlwifi/iwl-agn-rs.c:364: error: (Each undeclared identifier is reported only once
drivers/net/wireless/iwlwifi/iwl-agn-rs.c:364: error: for each function it appears in.)

This happens when compiling w/ the patch applied cleanly against .33.3
I'll try to fix it, then conduct the field test. For the latter, do
you need the same kind of log as for the previous one?

# Regarding (2): This is a common issue in busy environments where AP
# decides to deathenticate station after it does not receive an ack for
# data sent after a few retries. Was this test done in busy environment?
Both. This happens in busy environment as well as in an idle one. Can't tell
yet whether there're more of those msgs in busy env. I start to feel against
Cisco APs..

# Regarding (3): Seems like driver is getting a request to scan after a
# request to remove interface. I am still inquiring about this.
Probably due to me switching of via RF_KILLSWITCH. But anyway I assume this
msg should not happen..

Thanks, Reginette.


Cheers,

Nils

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Nils Radtke on 20 May 2010 10:40

Hi Reinette,

Did the fix like the patch below, applied on top of yours. Builds well,
not tested yet.

Do you ACK this patch?

Thanks,

Nils


# 1) Error messages like:
# iwlagn 0000:03:00.0: expected_tpt should have been calculated by now
# To address (1), could you please run with attached debug patch and also
# enable rate scaling debugging. That will be "modprobe iwlagn
# debug=0x143fff).

# diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
# index b93e491..60e5323 100644
# --- a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
# +++ b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
# @@ -361,6 +361,8 @@ static int rs_collect_tx_data(struct iwl_rate_scale_data *windows,
# * subtract "1" from the success counter (this is the main reason
# * we keep these bitmaps!).
# */
# + IWL_DEBUG_RATE(priv, "attempts = %d, window->counter = %d\n",
# + attempts, window->counter);
# while (attempts > 0) {
# if (window->counter >= IWL_RATE_MAX_WINDOW) {
#
# @@ -389,6 +391,7 @@ static int rs_collect_tx_data(struct iwl_rate_scale_data *windows,
# attempts--;
# }
#
# + IWL_DEBUG_RATE(priv, "window counter = %d \n", window->counter);
# /* Calculate current success ratio, avoid divide-by-0! */
# if (window->counter > 0)
# window->success_ratio = 128 * (100 * window->success_counter)
# @@ -849,6 +852,7 @@ static void rs_tx_status(void *priv_r, struct ieee80211_supported_band *sband,
# * first index into rate scale table.
# */
# if (info->flags & IEEE80211_TX_STAT_AMPDU) {
# + IWL_DEBUG_RATE(priv, "Updating aggregation history\n");
# tx_rate = le32_to_cpu(table->rs_table[0].rate_n_flags);
# rs_get_tbl_info_from_mcs(tx_rate, priv->band, &tbl_type,
# &rs_index);
# @@ -868,6 +872,7 @@ static void rs_tx_status(void *priv_r, struct ieee80211_supported_band *sband,
# * For legacy, update frame history with for each Tx retry.
# */
# retries = info->status.rates[0].count - 1;
# + IWL_DEBUG_RATE(priv, "Updating legacy history. retries = %d \n", retries);
# /* HW doesn't send more than 15 retries */
# retries = min(retries, 15);
#

---

drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

Index: linux-2.6.33.3_clean/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
===================================================================
--- linux-2.6.33.3_clean.orig/drivers/net/wireless/iwlwifi/iwl-agn-rs.c 2010-05-20 14:25:42.000000000 +0200
+++ linux-2.6.33.3_clean/drivers/net/wireless/iwlwifi/iwl-agn-rs.c 2010-05-20 14:26:50.000000000 +0200
@@ -341,7 +341,7 @@
*/
static int rs_collect_tx_data(struct iwl_rate_scale_data *windows,
int scale_index, s32 tpt, int attempts,
- int successes)
+ int successes, struct iwl_priv *priv)
{
struct iwl_rate_scale_data *window = NULL;
static const u64 mask = (((u64)1) << (IWL_RATE_MAX_WINDOW - 1));
@@ -859,7 +859,7 @@
tpt = get_expected_tpt(curr_tbl, rs_index);
rs_collect_tx_data(window, rs_index, tpt,
info->status.ampdu_ack_len,
- info->status.ampdu_ack_map);
+ info->status.ampdu_ack_map, priv);

/* Update success/fail counts if not searching for new mode */
if (lq_sta->stay_in_tbl) {
@@ -897,10 +897,10 @@
/* Constants mean 1 transmission, 0 successes */
if (i < retries)
rs_collect_tx_data(window, rs_index, tpt, 1,
- 0);
+ 0, priv);
else
rs_collect_tx_data(window, rs_index, tpt, 1,
- legacy_success);
+ legacy_success, priv);
}

/* Update success/fail counts if not searching for new mode */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: reinette chatre on 20 May 2010 14:30
On Thu, 2010-05-20 at 05:31 -0700, Nils Radtke wrote:
> Hi Reinette,
>
> Did the fix like the patch below, applied on top of yours. Builds well,
> not tested yet.
>
> Do you ACK this patch?

I do. I'm very sorry about the problem with the one I provided.

Reinette


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: reinette chatre on 20 May 2010 14:40
On Thu, 2010-05-20 at 05:15 -0700, Nils Radtke wrote:
> #
> # To address (1), could you please run with attached debug patch and also
> # enable rate scaling debugging. That will be "modprobe iwlagn
> # debug=0x143fff).
> drivers/net/wireless/iwlwifi/iwl-agn-rs.c: In function 'rs_collect_tx_data':
> drivers/net/wireless/iwlwifi/iwl-agn-rs.c:364: error: 'priv' undeclared (first use in this function)
> drivers/net/wireless/iwlwifi/iwl-agn-rs.c:364: error: (Each undeclared identifier is reported only once
> drivers/net/wireless/iwlwifi/iwl-agn-rs.c:364: error: for each function it appears in.)
>
> This happens when compiling w/ the patch applied cleanly against .33.3
> I'll try to fix it, then conduct the field test.

Sorry ... and thanks.

> For the latter, do
> you need the same kind of log as for the previous one?

The goal of this patch is to find the reason behind the error
"expected_tpt should have been calculated by now". From what I
understand you only encountered that in one of your tests, not all. Any
test you can run to reproduce that error will be welcome.

Thinking about your question more ... I believe your previous debug logs
were created with debug flag 0x43fff. For this iteration, please use
debug flag 0x143fff.

>
> # Regarding (2): This is a common issue in busy environments where AP
> # decides to deathenticate station after it does not receive an ack for
> # data sent after a few retries. Was this test done in busy environment?
> Both. This happens in busy environment as well as in an idle one. Can't tell
> yet whether there're more of those msgs in busy env. I start to feel against
> Cisco APs..

I don't know ... perhaps these APs have been set up to be strict wrt
delays.


> # Regarding (3): Seems like driver is getting a request to scan after a
> # request to remove interface. I am still inquiring about this.
> Probably due to me switching of via RF_KILLSWITCH. But anyway I assume this
> msg should not happen..

Absolutely. What are the exact steps you run when you encounter this
issue?

Reinette



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: David Miller on 20 May 2010 18:40

Wireless bug reports and patches should be posted with
linux-wireless(a)vger.kernel.org on the CC: list.

Otherwise the wireless developers will not see this discussion.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Staging: cxt1e1: Fix build error
Next: [PATCH 2.6.34-rc6] mxc: gadget: Fix bitfield for calculating maximum packet size