lkml.org 
[lkml]   [2010]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
SubjectRe: kernel BUG in iwl-agn-rs.c:2076, WAS: iwlagn + some accesspoint == hardlock
From
Date
Hi Nils,

On Thu, 2010-05-13 at 08:05 -0700, Nils Radtke wrote:
> Attached the output from the debug-enabled in-tree iwlwifi driver connects.

To keep track, this is 2.6.33.3.

>
> The order of trial is: site A first, then site B. The sites have thus been visited
> in the same order as last time and the commands executed have been equally the
> same. The failures evenly.. All the log entries that caught my eye last time
> can be found in the attached one also. I'm sending it bz2 compressed. My uplink
> is a poor man's volume limited UMTS one.

Thank you very much.

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)

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)


To address (1), could you please run with attached debug patch and also
enable rate scaling debugging. That will be "modprobe iwlagn
debug=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?

Regarding (3): Seems like driver is getting a request to scan after a
request to remove interface. I am still inquiring about this.

Reinette

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);
\
 
 \ /
  Last update: 2010-05-18 01:21    [W:0.137 / U:1.900 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site