linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 1/1] ath5k: fix hw rate index condition
@ 2009-02-26 22:44 Jiri Slaby
  2009-02-26 23:15 ` Bob Copeland
  0 siblings, 1 reply; 32+ messages in thread
From: Jiri Slaby @ 2009-02-26 22:44 UTC (permalink / raw)
  To: John W. Linville
  Cc: linux-wireless, ath5k-devel, linux-kernel, Jiri Slaby,
	Nick Kossifidis, Luis R. Rodriguez, Bob Copeland

Make sure we print out a warning when the index is out of bounds,
i.e. even on hw_rix == AR5K_MAX_RATES.

Also change to WARN and print text with the reported hw_rix.

Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Nick Kossifidis <mickflemm@gmail.com>
Cc: Luis R. Rodriguez <lrodriguez@atheros.com>
Cc: Bob Copeland <me@bobcopeland.com>
---
 drivers/net/wireless/ath5k/base.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/net/wireless/ath5k/base.c b/drivers/net/wireless/ath5k/base.c
index c06d1cc..08d691d 100644
--- a/drivers/net/wireless/ath5k/base.c
+++ b/drivers/net/wireless/ath5k/base.c
@@ -1100,7 +1100,8 @@ ath5k_mode_setup(struct ath5k_softc *sc)
 static inline int
 ath5k_hw_to_driver_rix(struct ath5k_softc *sc, int hw_rix)
 {
-	WARN_ON(hw_rix < 0 || hw_rix > AR5K_MAX_RATES);
+	WARN(hw_rix < 0 || hw_rix >= AR5K_MAX_RATES,
+			"hw_rix out of bounds: %x\n", hw_rix);
 	return sc->rate_idx[sc->curband->band][hw_rix];
 }
 
-- 
1.6.1.3


^ permalink raw reply related	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/1] ath5k: fix hw rate index condition
  2009-02-26 22:44 [PATCH 1/1] ath5k: fix hw rate index condition Jiri Slaby
@ 2009-02-26 23:15 ` Bob Copeland
  2009-02-26 23:19   ` Jiri Slaby
  0 siblings, 1 reply; 32+ messages in thread
From: Bob Copeland @ 2009-02-26 23:15 UTC (permalink / raw)
  To: Jiri Slaby, John W. Linville
  Cc: linux-wireless, ath5k-devel, linux-kernel, Nick Kossifidis,
	Luis R. Rodriguez

On Thu, 26 Feb 2009 23:44:31 +0100, Jiri Slaby wrote
> Make sure we print out a warning when the index is out of bounds,
> i.e. even on hw_rix == AR5K_MAX_RATES.
> 
> Also change to WARN and print text with the reported hw_rix.

ACK.

Speaking of, I think there's another potential oob array access at:

if (rxs.rate_idx >= 0 && rs.rs_rate == 
    sc->curband->bitrates[rxs.rate_idx].hw_value_short)
        rxs.flag |= RX_FLAG_SHORTPRE;

because sc->rate_idx is u8 instead of s8.

-- 
Bob Copeland %% www.bobcopeland.com



^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/1] ath5k: fix hw rate index condition
  2009-02-26 23:15 ` Bob Copeland
@ 2009-02-26 23:19   ` Jiri Slaby
  2009-02-26 23:28     ` [ath5k-devel] " Bob Copeland
  0 siblings, 1 reply; 32+ messages in thread
From: Jiri Slaby @ 2009-02-26 23:19 UTC (permalink / raw)
  To: Bob Copeland
  Cc: John W. Linville, linux-wireless, ath5k-devel, linux-kernel,
	Nick Kossifidis, Luis R. Rodriguez

On 27.2.2009 00:15, Bob Copeland wrote:
> Speaking of, I think there's another potential oob array access at:
>
> if (rxs.rate_idx>= 0&&  rs.rs_rate ==
>      sc->curband->bitrates[rxs.rate_idx].hw_value_short)
>          rxs.flag |= RX_FLAG_SHORTPRE;
>
> because sc->rate_idx is u8 instead of s8.

strcmp("sc->rate_idx", "rxs.rate_idx") != 0 :)

Or did I miss something?

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [ath5k-devel] [PATCH 1/1] ath5k: fix hw rate index condition
  2009-02-26 23:19   ` Jiri Slaby
@ 2009-02-26 23:28     ` Bob Copeland
  2009-02-26 23:32       ` Jiri Slaby
  0 siblings, 1 reply; 32+ messages in thread
From: Bob Copeland @ 2009-02-26 23:28 UTC (permalink / raw)
  To: Jiri Slaby; +Cc: linux-wireless, linux-kernel, John W. Linville, ath5k-devel

On Thu, Feb 26, 2009 at 6:19 PM, Jiri Slaby <jirislaby@gmail.com> wrote:
> On 27.2.2009 00:15, Bob Copeland wrote:
>> Speaking of, I think there's another potential oob array access at:
>>
>> if (rxs.rate_idx>= 0&&  rs.rs_rate ==
>>      sc->curband->bitrates[rxs.rate_idx].hw_value_short)
>>          rxs.flag |= RX_FLAG_SHORTPRE;
>>
>> because sc->rate_idx is u8 instead of s8.
>
> strcmp("sc->rate_idx", "rxs.rate_idx") != 0 :)
>
> Or did I miss something?

:)  Sorry, I should've been clearer.

hw_to_driver_rix() returns sc->rate_idx[x][y] as an int, and that
array is initialized to (u8)-1 for invalid rates.  So, it can
return 255 if the hardware rate index (y) is bad, then the check
"rxs.rate_idx >= 0" would always be true, right?  If it's not a
real bug yet, it likely will be one day :)

-- 
Bob Copeland %% www.bobcopeland.com

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [ath5k-devel] [PATCH 1/1] ath5k: fix hw rate index condition
  2009-02-26 23:28     ` [ath5k-devel] " Bob Copeland
@ 2009-02-26 23:32       ` Jiri Slaby
  2009-02-27  2:27         ` Bob Copeland
  0 siblings, 1 reply; 32+ messages in thread
From: Jiri Slaby @ 2009-02-26 23:32 UTC (permalink / raw)
  To: Bob Copeland; +Cc: linux-wireless, linux-kernel, John W. Linville, ath5k-devel

On 27.2.2009 00:28, Bob Copeland wrote:
> hw_to_driver_rix() returns sc->rate_idx[x][y] as an int, and that
> array is initialized to (u8)-1 for invalid rates.  So, it can
> return 255 if the hardware rate index (y) is bad, then the check
> "rxs.rate_idx>= 0" would always be true, right?  If it's not a
> real bug yet, it likely will be one day :)

Ah, yes, it really is a bug(tm), care to post a fix?

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [ath5k-devel] [PATCH 1/1] ath5k: fix hw rate index condition
  2009-02-26 23:32       ` Jiri Slaby
@ 2009-02-27  2:27         ` Bob Copeland
  2009-02-27  2:39           ` Luis R. Rodriguez
  2009-03-01  5:07           ` Pavel Roskin
  0 siblings, 2 replies; 32+ messages in thread
From: Bob Copeland @ 2009-02-27  2:27 UTC (permalink / raw)
  To: Jiri Slaby, proski
  Cc: linux-wireless, linux-kernel, John W. Linville, ath5k-devel

On Fri, Feb 27, 2009 at 12:32:55AM +0100, Jiri Slaby wrote:
> On 27.2.2009 00:28, Bob Copeland wrote:
>> hw_to_driver_rix() returns sc->rate_idx[x][y] as an int, and that
>> array is initialized to (u8)-1 for invalid rates.  So, it can
>> return 255 if the hardware rate index (y) is bad, then the check
>> "rxs.rate_idx>= 0" would always be true, right?  If it's not a
>> real bug yet, it likely will be one day :)
>
> Ah, yes, it really is a bug(tm), care to post a fix?

Actually, I remembered in the dark recesses of my moldering brain 
that someone had a lost patch for this a while ago, so I searched
the archives.  Pavel, ok to add your s-o-b?

From: Pavel Roskin <proski@gnu.org>
Subject: [PATCH] ath5k: use signed elements for rate index table

A lookup table is used to convert from hardware rate indexes back
to driver-based rate indexes.  For unknown hardware rates, we
initialize these values to -1, but since the array elements are of
type u8, they will be in the range 0-255.  This can cause array
overruns because subsequent sanity checks only check for negative
values.

Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
 drivers/net/wireless/ath5k/base.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/wireless/ath5k/base.h b/drivers/net/wireless/ath5k/base.h
index 20e0d14..8229561 100644
--- a/drivers/net/wireless/ath5k/base.h
+++ b/drivers/net/wireless/ath5k/base.h
@@ -112,7 +112,7 @@ struct ath5k_softc {
 	struct ieee80211_supported_band sbands[IEEE80211_NUM_BANDS];
 	struct ieee80211_channel channels[ATH_CHAN_MAX];
 	struct ieee80211_rate	rates[IEEE80211_NUM_BANDS][AR5K_MAX_RATES];
-	u8			rate_idx[IEEE80211_NUM_BANDS][AR5K_MAX_RATES];
+	s8			rate_idx[IEEE80211_NUM_BANDS][AR5K_MAX_RATES];
 	enum nl80211_iftype	opmode;
 	struct ath5k_hw		*ah;		/* Atheros HW */
 
-- 
1.5.4.1


-- 
Bob Copeland %% www.bobcopeland.com


^ permalink raw reply related	[flat|nested] 32+ messages in thread

* Re: [ath5k-devel] [PATCH 1/1] ath5k: fix hw rate index condition
  2009-02-27  2:27         ` Bob Copeland
@ 2009-02-27  2:39           ` Luis R. Rodriguez
  2009-02-27  3:06             ` Bob Copeland
  2009-03-01  5:07           ` Pavel Roskin
  1 sibling, 1 reply; 32+ messages in thread
From: Luis R. Rodriguez @ 2009-02-27  2:39 UTC (permalink / raw)
  To: Bob Copeland
  Cc: Jiri Slaby, proski, ath5k-devel, linux-wireless, linux-kernel,
	John W. Linville

On Thu, Feb 26, 2009 at 06:27:04PM -0800, Bob Copeland wrote:
> On Fri, Feb 27, 2009 at 12:32:55AM +0100, Jiri Slaby wrote:
> > On 27.2.2009 00:28, Bob Copeland wrote:
> >> hw_to_driver_rix() returns sc->rate_idx[x][y] as an int, and that
> >> array is initialized to (u8)-1 for invalid rates.  So, it can
> >> return 255 if the hardware rate index (y) is bad, then the check
> >> "rxs.rate_idx>= 0" would always be true, right?  If it's not a
> >> real bug yet, it likely will be one day :)
> >
> > Ah, yes, it really is a bug(tm), care to post a fix?
> 
> Actually, I remembered in the dark recesses of my moldering brain
> that someone had a lost patch for this a while ago, so I searched
> the archives.  Pavel, ok to add your s-o-b?
> 
> From: Pavel Roskin <proski@gnu.org>
> Subject: [PATCH] ath5k: use signed elements for rate index table
> 
> A lookup table is used to convert from hardware rate indexes back
> to driver-based rate indexes.  For unknown hardware rates, we
> initialize these values to -1, but since the array elements are of
> type u8, they will be in the range 0-255.  This can cause array
> overruns because subsequent sanity checks only check for negative
> values.
> 
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
> ---
>  drivers/net/wireless/ath5k/base.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath5k/base.h b/drivers/net/wireless/ath5k/base.h
> index 20e0d14..8229561 100644
> --- a/drivers/net/wireless/ath5k/base.h
> +++ b/drivers/net/wireless/ath5k/base.h
> @@ -112,7 +112,7 @@ struct ath5k_softc {
>         struct ieee80211_supported_band sbands[IEEE80211_NUM_BANDS];
>         struct ieee80211_channel channels[ATH_CHAN_MAX];
>         struct ieee80211_rate   rates[IEEE80211_NUM_BANDS][AR5K_MAX_RATES];
> -       u8                      rate_idx[IEEE80211_NUM_BANDS][AR5K_MAX_RATES];
> +       s8                      rate_idx[IEEE80211_NUM_BANDS][AR5K_MAX_RATES];

Might be worth adding a note why this is the case. Can't we simply avoid
this by checking earlier for the error or simply assigning it an actual
default _good_ hw rate value?

  Luis

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [ath5k-devel] [PATCH 1/1] ath5k: fix hw rate index condition
  2009-02-27  2:39           ` Luis R. Rodriguez
@ 2009-02-27  3:06             ` Bob Copeland
  2009-02-27  3:15               ` Luis R. Rodriguez
  2009-03-01  5:21               ` Pavel Roskin
  0 siblings, 2 replies; 32+ messages in thread
From: Bob Copeland @ 2009-02-27  3:06 UTC (permalink / raw)
  To: Luis R. Rodriguez
  Cc: Jiri Slaby, proski, ath5k-devel, linux-wireless, linux-kernel,
	John W. Linville

On Thu, Feb 26, 2009 at 06:39:12PM -0800, Luis R. Rodriguez wrote:
> Might be worth adding a note why this is the case. Can't we simply avoid
> this by checking earlier for the error or simply assigning it an actual
> default _good_ hw rate value?

I guess an alternative is to initialize to 0, that would count any rx
packets whose hw rate we don't know about as the base rate, so it would
probably bias the RC to 1mb, but this is already one of those 'should 
never happen' cases.  Also I can't forsee having a rate index > 127 so
changing the sign is pretty low risk.

-- 
Bob Copeland %% www.bobcopeland.com


^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [ath5k-devel] [PATCH 1/1] ath5k: fix hw rate index condition
  2009-02-27  3:06             ` Bob Copeland
@ 2009-02-27  3:15               ` Luis R. Rodriguez
  2009-03-01  5:21               ` Pavel Roskin
  1 sibling, 0 replies; 32+ messages in thread
From: Luis R. Rodriguez @ 2009-02-27  3:15 UTC (permalink / raw)
  To: Bob Copeland
  Cc: Luis Rodriguez, Jiri Slaby, proski, ath5k-devel, linux-wireless,
	linux-kernel, John W. Linville

On Thu, Feb 26, 2009 at 07:06:08PM -0800, Bob Copeland wrote:
> On Thu, Feb 26, 2009 at 06:39:12PM -0800, Luis R. Rodriguez wrote:
> > Might be worth adding a note why this is the case. Can't we simply avoid
> > this by checking earlier for the error or simply assigning it an actual
> > default _good_ hw rate value?
> 
> I guess an alternative is to initialize to 0, that would count any rx
> packets whose hw rate we don't know about as the base rate, so it would
> probably bias the RC to 1mb, but this is already one of those 'should
> never happen' cases.

Understood.

> Also I can't forsee having a rate index > 127 so
> changing the sign is pretty low risk.

Sure, it just seems a bit strange to see a signed rate index,
that's all. And if its to deal with an error I think it may
be nicer to actually use a rate that works and then warn
rather than warn and not use a valid rate at all.

Mind you I haven't checked this code in while.

  Luis

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [ath5k-devel] [PATCH 1/1] ath5k: fix hw rate index condition
  2009-02-27  2:27         ` Bob Copeland
  2009-02-27  2:39           ` Luis R. Rodriguez
@ 2009-03-01  5:07           ` Pavel Roskin
  2009-03-01 14:36             ` Bob Copeland
  1 sibling, 1 reply; 32+ messages in thread
From: Pavel Roskin @ 2009-03-01  5:07 UTC (permalink / raw)
  To: Bob Copeland
  Cc: Jiri Slaby, linux-wireless, linux-kernel, John W. Linville, ath5k-devel

On Thu, 2009-02-26 at 21:27 -0500, Bob Copeland wrote:

> Actually, I remembered in the dark recesses of my moldering brain 
> that someone had a lost patch for this a while ago, so I searched
> the archives.  Pavel, ok to add your s-o-b?

Since my patch was dropped and the new patch was implemented without my
participation, it makes no sense to put my s-o-b on the code I didn't
write (even though I wrote something similar before).

-- 
Regards,
Pavel Roskin

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [ath5k-devel] [PATCH 1/1] ath5k: fix hw rate index condition
  2009-02-27  3:06             ` Bob Copeland
  2009-02-27  3:15               ` Luis R. Rodriguez
@ 2009-03-01  5:21               ` Pavel Roskin
  2009-03-03  3:46                 ` Bob Copeland
  1 sibling, 1 reply; 32+ messages in thread
From: Pavel Roskin @ 2009-03-01  5:21 UTC (permalink / raw)
  To: Bob Copeland
  Cc: Luis R. Rodriguez, Jiri Slaby, ath5k-devel, linux-wireless,
	linux-kernel, John W. Linville

On Thu, 2009-02-26 at 22:06 -0500, Bob Copeland wrote:
> On Thu, Feb 26, 2009 at 06:39:12PM -0800, Luis R. Rodriguez wrote:
> > Might be worth adding a note why this is the case. Can't we simply avoid
> > this by checking earlier for the error or simply assigning it an actual
> > default _good_ hw rate value?
> 
> I guess an alternative is to initialize to 0, that would count any rx
> packets whose hw rate we don't know about as the base rate, so it would
> probably bias the RC to 1mb, but this is already one of those 'should 
> never happen' cases.

I would prefer that we don't hide problems.

If we don't know why we cannot get a valid rate, we should use WARN_ON
and find out why and when it happens.  I'm fine with using a bogus rate
with WARN_ON.

If we decide that we indeed cannot find the actual rate, then WARN_ON
should be removed and the bogus rate replaced with an "unknown rate",
that is, a special value that is never translated to a valid rate and
never given to any rate control algorithm.  Using a bogus rate without a
warning is wrong in my opinion.

It should be possible to represent "unknown rate" as such.  That applies
to all drivers.  I remember that b43 also failed to report the rate in
some cases (for the first received packet or something like that).

-- 
Regards,
Pavel Roskin

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [ath5k-devel] [PATCH 1/1] ath5k: fix hw rate index condition
  2009-03-01  5:07           ` Pavel Roskin
@ 2009-03-01 14:36             ` Bob Copeland
  0 siblings, 0 replies; 32+ messages in thread
From: Bob Copeland @ 2009-03-01 14:36 UTC (permalink / raw)
  To: Pavel Roskin
  Cc: ath5k-devel, linux-wireless, Jiri Slaby, John W. Linville, linux-kernel

On Sun, Mar 1, 2009 at 12:07 AM, Pavel Roskin <proski@gnu.org> wrote:
> On Thu, 2009-02-26 at 21:27 -0500, Bob Copeland wrote:
>
>> Actually, I remembered in the dark recesses of my moldering brain
>> that someone had a lost patch for this a while ago, so I searched
>> the archives.  Pavel, ok to add your s-o-b?
>
> Since my patch was dropped and the new patch was implemented without my
> participation, it makes no sense to put my s-o-b on the code I didn't
> write (even though I wrote something similar before).

Ok, I just wanted to be sure to maintain proper credit, the "From" should
suffice.  I did rewrite the patch but it actually had an identical diff.
FWIW, the thread didn't give a clue why it didn't make it upstream, just
missed I guess (http://marc.info/?l=linux-wireless&m=122480002519627&w=2,
ultimately that problem was fixed by correctly setting the rs_more flag).

Anyway, the patch, while IMO correct, will still result in mac80211
warning in ieee80211_rx with -1 just as 255 will; it just fixes the
subsequent out of bound read.  If we want to tell mac80211 a real rate,
I think we should change it to s8 then hw_to_driver_rix should do
something like:

idx = array[x][y];
if (WARN_ON(idx < 0))
   idx = 0;

return idx;

Then we get the warning in the driver and we also return a real rate up
the stack.  I'll prep a patch for this unless there are any objections.

-- 
Bob Copeland %% www.bobcopeland.com

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [ath5k-devel] [PATCH 1/1] ath5k: fix hw rate index condition
  2009-03-01  5:21               ` Pavel Roskin
@ 2009-03-03  3:46                 ` Bob Copeland
  2009-03-03  4:31                   ` Nick Kossifidis
  0 siblings, 1 reply; 32+ messages in thread
From: Bob Copeland @ 2009-03-03  3:46 UTC (permalink / raw)
  To: Pavel Roskin
  Cc: Luis R. Rodriguez, Jiri Slaby, ath5k-devel, linux-wireless,
	linux-kernel, John W. Linville, mickflemm

On Sun, Mar 01, 2009 at 12:21:52AM -0500, Pavel Roskin wrote:
> I would prefer that we don't hide problems.
> 
> If we don't know why we cannot get a valid rate, we should use WARN_ON
> and find out why and when it happens.  I'm fine with using a bogus rate
> with WARN_ON.

So here is at least stage one of this, not yet the global "unknown rate"
infrastructure, but hopefully it will allow us to track down the issue.

It makes hw_to_driver_rix a little uglier, but oh well.  Thoughts?

From: Bob Copeland <me@bobcopeland.com>
Date: Mon, 2 Mar 2009 21:55:18 -0500
Subject: [PATCH] ath5k: warn and correct rate for unknown hw rate indexes

ath5k sets up a mapping table from the hardware rate index to
the rate index used by mac80211; however, we have seen some
received frames with incorrect rate indexes.  Such frames
normally get dropped with a warning in __ieee80211_rx(), but the 
warning doesn't include enough context to track down the error.

This patch adds a warning to hw_to_driver_rix for any lookups
that result in a rate index of -1, then returns a valid rate so
the frame can be processed.

This also includes the bug fix suggested by Pavel Roskin, in which
the mapping table is made signed, so rates initialized to -1 stay
that way.

Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
 drivers/net/wireless/ath5k/base.c |   15 ++++++++++++---
 drivers/net/wireless/ath5k/base.h |    2 +-
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath5k/base.c b/drivers/net/wireless/ath5k/base.c
index f7c424d..8d4b11c 100644
--- a/drivers/net/wireless/ath5k/base.c
+++ b/drivers/net/wireless/ath5k/base.c
@@ -1100,9 +1100,18 @@ ath5k_mode_setup(struct ath5k_softc *sc)
 static inline int
 ath5k_hw_to_driver_rix(struct ath5k_softc *sc, int hw_rix)
 {
-	WARN(hw_rix < 0 || hw_rix >= AR5K_MAX_RATES,
-			"hw_rix out of bounds: %x\n", hw_rix);
-	return sc->rate_idx[sc->curband->band][hw_rix];
+	int rix;
+
+	/* return base rate on errors */
+	if (WARN(hw_rix < 0 || hw_rix >= AR5K_MAX_RATES,
+			"hw_rix out of bounds: %x\n", hw_rix))
+		return 0;
+
+	rix = sc->rate_idx[sc->curband->band][hw_rix];
+	if (WARN(rix < 0, "invalid hw_rix: %x\n", hw_rix))
+		rix = 0;
+
+	return rix;
 }
 
 /***************\
diff --git a/drivers/net/wireless/ath5k/base.h b/drivers/net/wireless/ath5k/base.h
index 20e0d14..8229561 100644
--- a/drivers/net/wireless/ath5k/base.h
+++ b/drivers/net/wireless/ath5k/base.h
@@ -112,7 +112,7 @@ struct ath5k_softc {
 	struct ieee80211_supported_band sbands[IEEE80211_NUM_BANDS];
 	struct ieee80211_channel channels[ATH_CHAN_MAX];
 	struct ieee80211_rate	rates[IEEE80211_NUM_BANDS][AR5K_MAX_RATES];
-	u8			rate_idx[IEEE80211_NUM_BANDS][AR5K_MAX_RATES];
+	s8			rate_idx[IEEE80211_NUM_BANDS][AR5K_MAX_RATES];
 	enum nl80211_iftype	opmode;
 	struct ath5k_hw		*ah;		/* Atheros HW */
 
-- 
1.6.0.6



-- 
Bob Copeland %% www.bobcopeland.com


^ permalink raw reply related	[flat|nested] 32+ messages in thread

* Re: [ath5k-devel] [PATCH 1/1] ath5k: fix hw rate index condition
  2009-03-03  3:46                 ` Bob Copeland
@ 2009-03-03  4:31                   ` Nick Kossifidis
  2009-03-03 13:02                     ` Bob Copeland
  0 siblings, 1 reply; 32+ messages in thread
From: Nick Kossifidis @ 2009-03-03  4:31 UTC (permalink / raw)
  To: Bob Copeland
  Cc: Pavel Roskin, Luis R. Rodriguez, Jiri Slaby, ath5k-devel,
	linux-wireless, linux-kernel, John W. Linville

2009/3/3 Bob Copeland <me@bobcopeland.com>:
> On Sun, Mar 01, 2009 at 12:21:52AM -0500, Pavel Roskin wrote:
>> I would prefer that we don't hide problems.
>>
>> If we don't know why we cannot get a valid rate, we should use WARN_ON
>> and find out why and when it happens.  I'm fine with using a bogus rate
>> with WARN_ON.
>
> So here is at least stage one of this, not yet the global "unknown rate"
> infrastructure, but hopefully it will allow us to track down the issue.
>
> It makes hw_to_driver_rix a little uglier, but oh well.  Thoughts?
>
> From: Bob Copeland <me@bobcopeland.com>
> Date: Mon, 2 Mar 2009 21:55:18 -0500
> Subject: [PATCH] ath5k: warn and correct rate for unknown hw rate indexes
>
> ath5k sets up a mapping table from the hardware rate index to
> the rate index used by mac80211; however, we have seen some
> received frames with incorrect rate indexes.  Such frames
> normally get dropped with a warning in __ieee80211_rx(), but the
> warning doesn't include enough context to track down the error.
>
> This patch adds a warning to hw_to_driver_rix for any lookups
> that result in a rate index of -1, then returns a valid rate so
> the frame can be processed.
>
> This also includes the bug fix suggested by Pavel Roskin, in which
> the mapping table is made signed, so rates initialized to -1 stay
> that way.
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
> ---
>  drivers/net/wireless/ath5k/base.c |   15 ++++++++++++---
>  drivers/net/wireless/ath5k/base.h |    2 +-
>  2 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/ath5k/base.c b/drivers/net/wireless/ath5k/base.c
> index f7c424d..8d4b11c 100644
> --- a/drivers/net/wireless/ath5k/base.c
> +++ b/drivers/net/wireless/ath5k/base.c
> @@ -1100,9 +1100,18 @@ ath5k_mode_setup(struct ath5k_softc *sc)
>  static inline int
>  ath5k_hw_to_driver_rix(struct ath5k_softc *sc, int hw_rix)
>  {
> -       WARN(hw_rix < 0 || hw_rix >= AR5K_MAX_RATES,
> -                       "hw_rix out of bounds: %x\n", hw_rix);
> -       return sc->rate_idx[sc->curband->band][hw_rix];
> +       int rix;
> +
> +       /* return base rate on errors */
> +       if (WARN(hw_rix < 0 || hw_rix >= AR5K_MAX_RATES,
> +                       "hw_rix out of bounds: %x\n", hw_rix))
> +               return 0;
> +
> +       rix = sc->rate_idx[sc->curband->band][hw_rix];
> +       if (WARN(rix < 0, "invalid hw_rix: %x\n", hw_rix))
> +               rix = 0;
> +
> +       return rix;
>  }
>
>  /***************\
> diff --git a/drivers/net/wireless/ath5k/base.h b/drivers/net/wireless/ath5k/base.h
> index 20e0d14..8229561 100644
> --- a/drivers/net/wireless/ath5k/base.h
> +++ b/drivers/net/wireless/ath5k/base.h
> @@ -112,7 +112,7 @@ struct ath5k_softc {
>        struct ieee80211_supported_band sbands[IEEE80211_NUM_BANDS];
>        struct ieee80211_channel channels[ATH_CHAN_MAX];
>        struct ieee80211_rate   rates[IEEE80211_NUM_BANDS][AR5K_MAX_RATES];
> -       u8                      rate_idx[IEEE80211_NUM_BANDS][AR5K_MAX_RATES];
> +       s8                      rate_idx[IEEE80211_NUM_BANDS][AR5K_MAX_RATES];
>        enum nl80211_iftype     opmode;
>        struct ath5k_hw         *ah;            /* Atheros HW */
>
> --
> 1.6.0.6
>

Another thought...

According to docs the rate field is only valid if more flag is clear
(we have the last descriptor) and only if the receive ok flag is set
or both receive ok and phy error flags are cleared. We never do such
checks so we might actually try to process this field when we already
know we shouldn't...

Also the following rate codes are reserved (except XR codes that we
already know):

0x00
0x04 -> the short preamble flag
0x05
0x10 - 0x17
0x1f

and i don't believe i've ever seen them, so we can warn on them too
and print something like "Reserved rate code: %x", also it would be
nice to warn on XR rates (1,2,3,6,7) in case we want to debug this in
the future.


-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [ath5k-devel] [PATCH 1/1] ath5k: fix hw rate index condition
  2009-03-03  4:31                   ` Nick Kossifidis
@ 2009-03-03 13:02                     ` Bob Copeland
  0 siblings, 0 replies; 32+ messages in thread
From: Bob Copeland @ 2009-03-03 13:02 UTC (permalink / raw)
  To: Nick Kossifidis
  Cc: Pavel Roskin, Luis R. Rodriguez, Jiri Slaby, ath5k-devel,
	linux-wireless, linux-kernel, John W. Linville

On Tue, Mar 03, 2009 at 06:31:05AM +0200, Nick Kossifidis wrote:
> 
> According to docs the rate field is only valid if more flag is clear
> (we have the last descriptor) and only if the receive ok flag is set
> or both receive ok and phy error flags are cleared. We never do such
> checks so we might actually try to process this field when we already
> know we shouldn't...

Well, we do skip rs_more packets without getting the rate, hopefully 
phy error packets too.  The warning would definitely show if we have 
any bugs there.

> Also the following rate codes are reserved (except XR codes that we
> already know):
[snip]
> and i don't believe i've ever seen them, so we can warn on them too
> and print something like "Reserved rate code: %x", also it would be
> nice to warn on XR rates (1,2,3,6,7) in case we want to debug this in
> the future.

Good idea, though I'm somewhat of the mind that we should let the 
current patch go in for a bit and see if any of these pop up.  But 
that's because I'm lazy :)  

-- 
Bob Copeland %% www.bobcopeland.com


^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/1] ath5k: fix hw rate index condition
  2009-03-31  3:51                       ` Dhaval Giani
@ 2009-03-31 12:23                         ` Bob Copeland
  0 siblings, 0 replies; 32+ messages in thread
From: Bob Copeland @ 2009-03-31 12:23 UTC (permalink / raw)
  To: Dhaval Giani
  Cc: Jiri Slaby, Dhaval Giani, linville, davem, linux-wireless,
	ath5k-devel, Nick Kossifidis, Luis R. Rodriguez, linux-kernel

On Tue, Mar 31, 2009 at 09:21:40AM +0530, Dhaval Giani wrote:
> Am not sure what the PID controller is, and google gave me a number of
> results, which did not make too much sense in the context.

CONFIG_MAC80211_RC_PID -- unfortunately I recall having to jump through
a few config hoops to enable it.

> One way I have found of reproducing it is to connect to open networks,
> but it does not happen always. At home, when my network is set to open,
> I do not see this issue, whereas at the airport, kaboom.

Ok - that is a useful data point.  Perhaps something to do with the rates
the peer supports; it would help if you could grab a scan next time you
are in the area.  Turn off auto-connect to open networks, then do:

 # iw dev wlan0 scan trigger
 # iw dev wlan0 scan dump >> dump.out    # do this a few times

Then if a particular peer triggers the problem, we can look at the 
advertised rates to see if anything jumps out.

-- 
Bob Copeland %% www.bobcopeland.com


^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/1] ath5k: fix hw rate index condition
  2009-03-30 18:13                     ` Bob Copeland
@ 2009-03-31  3:51                       ` Dhaval Giani
  2009-03-31 12:23                         ` Bob Copeland
  0 siblings, 1 reply; 32+ messages in thread
From: Dhaval Giani @ 2009-03-31  3:51 UTC (permalink / raw)
  To: Bob Copeland
  Cc: Jiri Slaby, Dhaval Giani, linville, davem, linux-wireless,
	ath5k-devel, Nick Kossifidis, Luis R. Rodriguez, linux-kernel

On Mon, Mar 30, 2009 at 02:13:35PM -0400, Bob Copeland wrote:
> On Mon, Mar 30, 2009 at 1:59 PM, Dhaval Giani <dhaval@linux.vnet.ibm.com> wrote:
> > ok, so my kernel does hve this patch applied, and this is what I get,
> >
> >  ------------[ cut here ]------------
> >  WARNING: at include/net/mac80211.h:1956 minstrel_get_rate+0xa1/0x4b9 [mac80211]()
> 
> I believe this is something different (tx path not rx).  I think it's
> that minstrel rate table bug again, which we never solved for ath5k.
> 
> Are you using adhoc or managed mode?  Do you have the slab/slub debugging
> options turned on?  Any steps that consistently reproduce it?  Do you
> get any warnings with PID controller?
> 

[dhaval@gondor ~]$ iwconfig wlan0
wlan0     IEEE 802.11abg  ESSID:"linksys_SES_62338"
          Mode:Managed  Frequency:2.462 GHz  Access Point: 00:1A:70:D6:2D:06
          Bit Rate=36 Mb/s   Tx-Power=23 dBm
          Retry min limit:7   RTS thr:off   Fragment thr=2352 B
          Power Management:off
          Link Quality=100/100  Signal level:-49 dBm  Noise level=-96 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

[dhaval@gondor ~]$

[dhaval@gondor linux-2.6]$ grep -i slub .config
CONFIG_SLUB_DEBUG=y
CONFIG_SLUB=y
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
[dhaval@gondor linux-2.6]$

Am not sure what the PID controller is, and google gave me a number of
results, which did not make too much sense in the context.

Yes, I think I know how to reproduce it, but I am not sure what is the
real cause.

One way I have found of reproducing it is to connect to open networks,
but it does not happen always. At home, when my network is set to open,
I do not see this issue, whereas at the airport, kaboom.

I've also seen it on LEAP networks, but there were also a few open
networks around. This warning is generally accompanied by a disconnect
from the LEAP connected network, and then the system reconnects. Let me
know if you have patches, I can give them a run and report back.

Thanks,
-- 
regards,
Dhaval

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/1] ath5k: fix hw rate index condition
  2009-03-30 17:59                   ` Dhaval Giani
@ 2009-03-30 18:13                     ` Bob Copeland
  2009-03-31  3:51                       ` Dhaval Giani
  0 siblings, 1 reply; 32+ messages in thread
From: Bob Copeland @ 2009-03-30 18:13 UTC (permalink / raw)
  To: Dhaval Giani
  Cc: Jiri Slaby, Dhaval Giani, linville, davem, linux-wireless,
	ath5k-devel, Nick Kossifidis, Luis R. Rodriguez, linux-kernel

On Mon, Mar 30, 2009 at 1:59 PM, Dhaval Giani <dhaval@linux.vnet.ibm.com> wrote:
> ok, so my kernel does hve this patch applied, and this is what I get,
>
>  ------------[ cut here ]------------
>  WARNING: at include/net/mac80211.h:1956 minstrel_get_rate+0xa1/0x4b9 [mac80211]()

I believe this is something different (tx path not rx).  I think it's
that minstrel rate table bug again, which we never solved for ath5k.

Are you using adhoc or managed mode?  Do you have the slab/slub debugging
options turned on?  Any steps that consistently reproduce it?  Do you
get any warnings with PID controller?

-- 
Bob Copeland %% www.bobcopeland.com

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/1] ath5k: fix hw rate index condition
  2009-03-30 16:58                 ` Bob Copeland
@ 2009-03-30 17:59                   ` Dhaval Giani
  2009-03-30 18:13                     ` Bob Copeland
  0 siblings, 1 reply; 32+ messages in thread
From: Dhaval Giani @ 2009-03-30 17:59 UTC (permalink / raw)
  To: Bob Copeland
  Cc: Jiri Slaby, Dhaval Giani, linville, davem, linux-wireless,
	ath5k-devel, Nick Kossifidis, Luis R. Rodriguez, linux-kernel

On Mon, Mar 30, 2009 at 12:58:28PM -0400, Bob Copeland wrote:
> On Mon, Mar 30, 2009 at 4:59 AM, Dhaval Giani <dhaval@linux.vnet.ibm.com> wrote:
> > Where is the fix? Is it merged in? I still see this happen on 2.6.29
> >
> > thanks,
> 
> It's in b726604706ad88d8b28bc487e45e710f58cc19ee in Linus' tree, after
> 2.6.29.  You still might get a warning, but this time from the driver
> side instead of higher up the stack -- if you do please post it.
> 

ok, so my kernel does hve this patch applied, and this is what I get,

 ------------[ cut here ]------------
 WARNING: at include/net/mac80211.h:1956 minstrel_get_rate+0xa1/0x4b9 [mac80211]()
 Hardware name: 2007CS3
 Modules linked in: fuse radeon drm ipt_MASQUERADE iptable_nat nf_nat bridge stp bnep sco l2cap bluetooth ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand acpi_cpufreq dm_multipath kvm_intel kvm uinput snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_seq_dummy arc4 snd_seq_oss snd_seq_midi_event snd_seq ecb ath5k nsc_ircc snd_seq_device snd_pcm_oss video snd_mixer_oss snd_pcm mac80211 snd_timer snd yenta_socket i2c_i801 thinkpad_acpi rfkill irda output iTCO_wdt rsrc_nonstatic pcspkr hwmon cfg80211 joydev i2c_core iTCO_vendor_support soundcore crc_ccitt snd_page_alloc [last unloaded: scsi_wait_scan]
 Pid: 2389, comm: wpa_supplicant Tainted: G        W  2.6.29-tip #28
 Call Trace:
 [<c0431b0e>] warn_slowpath+0x76/0xad
 [<c04523e1>] ? print_lock_contention_bug+0x14/0xd7
 [<c042e874>] ? default_wake_function+0x10/0x12
 [<c04523e1>] ? print_lock_contention_bug+0x14/0xd7
 [<f7d31879>] minstrel_get_rate+0xa1/0x4b9 [mac80211]
 [<c0450fa4>] ? trace_hardirqs_on+0xb/0xd
 [<c0424909>] ? __wake_up+0x36/0x40
 [<f7d272fe>] ? invoke_tx_handlers+0x3b1/0xa50 [mac80211]
 [<f7d21b1e>] rate_control_get_rate+0x7e/0xbe [mac80211]
 [<f7d27330>] invoke_tx_handlers+0x3e3/0xa50 [mac80211]
 [<c0450e61>] ? trace_hardirqs_on_caller+0x18/0x150
 [<f7d26c03>] ? __ieee80211_tx_prepare+0x24b/0x288 [mac80211]
 [<f7d286ad>] ieee80211_master_start_xmit+0x38b/0x4b2 [mac80211]
 [<c069d1f4>] dev_hard_start_xmit+0x219/0x280
 [<c06ac17e>] __qdisc_run+0xca/0x1b0
 [<c069d6de>] dev_queue_xmit+0x398/0x4bf
 [<f7d2a116>] ieee80211_tx_skb+0x53/0x56 [mac80211]
 [<f7d1dac4>] ieee80211_send_deauth_disassoc+0xd7/0xdf [mac80211]
 [<f7d1dbc1>] ieee80211_set_disassoc+0xf5/0x209 [mac80211]
 [<f7d1ddc6>] ieee80211_sta_req_auth+0x47/0x69 [mac80211]
 [<f7d17c5a>] ieee80211_ioctl_siwgenie+0x50/0x5d [mac80211]
 [<c06f9720>] ioctl_standard_call+0x1b4/0x268
 [<c069b3ce>] ? dev_name_hash+0x1b/0x47
 [<c06f92e7>] wext_handle_ioctl+0xe7/0x17d
 [<f7d17c0a>] ? ieee80211_ioctl_siwgenie+0x0/0x5d [mac80211]
 [<c04937ba>] ? might_fault+0x83/0x85
 [<c069f06f>] dev_ioctl+0x5c6/0x5e6
 [<c0690bf3>] ? sockfd_lookup_light+0x1b/0x4e
 [<c0691b65>] ? sys_sendto+0xa9/0xc8
 [<c04cf997>] ? dnotify_parent+0x22/0x63
 [<c0690746>] ? sock_ioctl+0x0/0x1f0
 [<c069092a>] sock_ioctl+0x1e4/0x1f0
 [<c0690746>] ? sock_ioctl+0x0/0x1f0
 [<c04b6d55>] vfs_ioctl+0x27/0x6e
 [<c04b72d4>] do_vfs_ioctl+0x46f/0x4a8
 [<c0691ba1>] ? sys_send+0x1d/0x1f
 [<c04b7352>] sys_ioctl+0x45/0x5f
 [<c04032a4>] sysenter_do_call+0x12/0x38
 ---[ end trace 0e3d1a2e9037b74b ]---


> -- 
> Bob Copeland %% www.bobcopeland.com

-- 
regards,
Dhaval

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/1] ath5k: fix hw rate index condition
  2009-03-30  8:59               ` Dhaval Giani
@ 2009-03-30 16:58                 ` Bob Copeland
  2009-03-30 17:59                   ` Dhaval Giani
  0 siblings, 1 reply; 32+ messages in thread
From: Bob Copeland @ 2009-03-30 16:58 UTC (permalink / raw)
  To: Dhaval Giani
  Cc: Jiri Slaby, Dhaval Giani, linville, davem, linux-wireless,
	ath5k-devel, Nick Kossifidis, Luis R. Rodriguez, linux-kernel

On Mon, Mar 30, 2009 at 4:59 AM, Dhaval Giani <dhaval@linux.vnet.ibm.com> wrote:
> Where is the fix? Is it merged in? I still see this happen on 2.6.29
>
> thanks,

It's in b726604706ad88d8b28bc487e45e710f58cc19ee in Linus' tree, after
2.6.29.  You still might get a warning, but this time from the driver
side instead of higher up the stack -- if you do please post it.

-- 
Bob Copeland %% www.bobcopeland.com

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/1] ath5k: fix hw rate index condition
  2009-02-28 23:08             ` Jiri Slaby
@ 2009-03-30  8:59               ` Dhaval Giani
  2009-03-30 16:58                 ` Bob Copeland
  0 siblings, 1 reply; 32+ messages in thread
From: Dhaval Giani @ 2009-03-30  8:59 UTC (permalink / raw)
  To: Jiri Slaby
  Cc: Bob Copeland, Dhaval Giani, linville, davem, linux-wireless,
	ath5k-devel, Nick Kossifidis, Luis R. Rodriguez, linux-kernel

On Sun, Mar 01, 2009 at 12:08:07AM +0100, Jiri Slaby wrote:
> On 15.2.2009 14:47, Bob Copeland wrote:
>> On Mon, Feb 02, 2009 at 01:27:39PM +0530, Dhaval Giani wrote:
>>> So I finally managed to hit this on 2.6.29-rc3. It is hard to
>>> reproduce, so I hope so much information is enough to give you a good
>>> guess. This time it hit while trying to connect to an open network at
>>> the airport.
>>
>>> WARNING: at net/mac80211/rx.c:2236 __ieee80211_rx+0x96/0x571 [mac80211]()
>>> Hardware name: 2007CS3
>>> RATE=255, BAND=8
>>
>> band is supposed to be sc->curband?  8 is way wrong.
>
> If you look into the patch which outputs this (backtrace in this  
> thread), sband->n_bitrates is 8. I have no idea what I have been smoking  
> the day I wrote it, but BAND= for sure isn't the right name for that  
> thing. Sorry for the confusion.
>
>> rate could be 255
>> if, for some reason, the hardware rate wasn't in the rate table.
>
> So, we have a fix for this, right? I mean the u8->s8 sc->rate_idx  
> conversion or alike...

Where is the fix? Is it merged in? I still see this happen on 2.6.29

thanks,
-- 
regards,
Dhaval

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/1] ath5k: fix hw rate index condition
  2009-03-23  0:45       ` Stefan Lippers-Hollmann
@ 2009-03-23  2:31         ` Bob Copeland
  0 siblings, 0 replies; 32+ messages in thread
From: Bob Copeland @ 2009-03-23  2:31 UTC (permalink / raw)
  To: Stefan Lippers-Hollmann
  Cc: Jiri Slaby, Dhaval Giani, linville, davem, linux-wireless,
	ath5k-devel, Nick Kossifidis, Luis R. Rodriguez, linux-kernel,
	bcm43xx-dev

On Mon, Mar 23, 2009 at 01:45:58AM +0100, Stefan Lippers-Hollmann wrote:
>
> Post scriptum: I'm not able to trigger this trace with ath5k/ AR2425.

Okay, well just to be clear ath5k had the same issue (I posted a patch
a couple of weeks ago - I think it got lost and I need to repost it).  

But this is separate from the problem where the rate controller is 
choosing a bad rate index for TX in adhoc mode, that's still an unknown, 
unsolved problem.

-- 
Bob Copeland %% www.bobcopeland.com


^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/1] ath5k: fix hw rate index condition
  2009-03-15 21:27     ` Stefan Lippers-Hollmann
  2009-03-15 21:35       ` Michael Buesch
@ 2009-03-23  0:45       ` Stefan Lippers-Hollmann
  2009-03-23  2:31         ` Bob Copeland
  1 sibling, 1 reply; 32+ messages in thread
From: Stefan Lippers-Hollmann @ 2009-03-23  0:45 UTC (permalink / raw)
  To: Jiri Slaby
  Cc: Dhaval Giani, linville, davem, linux-wireless, ath5k-devel,
	Nick Kossifidis, Luis R. Rodriguez, Bob Copeland, linux-kernel,
	bcm43xx-dev

Hi

On Sonntag, 15. März 2009, Stefan Lippers-Hollmann wrote:
> Hi
> 
> On Mittwoch, 7. Januar 2009, Jiri Slaby wrote:
> > On 01/07/2009 02:51 PM, Jiri Slaby wrote:
> > > Dhaval Giani wrote:
> > >> I see this on current git. Not sure how to reproduce it, has happened on
> > >> two random occasions. At both times, I was not connected to a wireless
> > >> network, but to wired networks.
> > >>
> > >> ------------[ cut here ]------------
> > >> WARNING: at net/mac80211/rx.c:2234 __ieee80211_rx+0x7f/0x559
> > >> ...
> > >> Call Trace:
> > >>  [<f80d4192>] __ieee80211_rx+0x7f/0x559 [mac80211]
> > >>  [<f80a19f4>] ath5k_tasklet_rx+0x4f7/0x53b [ath5k]
> > >> ...
> > > 
> > > Hmm, maybe ath5k is culprit. Could you apply the attached patch and
> > > use the kernel till the problem appears again?
> 
> It seems as if this problem wouldn't be restricted to ath5k, I just 
> triggered something very similar on b43 and 2.6.29-rc8-git1 (i386, hard 
> preemption):
> 
> b43-phy0: Broadcom 4306 WLAN found (core revision 5)
[...]
> wlan1: no IPv6 routers present
> b43-phy0 ERROR: PHY transmission error
> b43-phy0 ERROR: PHY transmission error
> 
> [ lots of these, likely to be caused by minstrel being a little too 
>   optimistic about the possible wlan rates (it was more conservative in 
>   2.6.28 and didn't happen there); the distance between both stations is 
>   on the upper end ]
> 
> b43-phy0 ERROR: PHY transmission error
> __ratelimit: 9 callbacks suppressed
> b43-phy0 ERROR: PHY transmission error
> b43-phy0 ERROR: PHY transmission error
> ------------[ cut here ]------------
> WARNING: at net/mac80211/rx.c:2234 __ieee80211_rx+0xa2/0x6a0 [mac80211]()
> Hardware name: Amilo D-Series
> Modules linked in: ppdev lp aes_i586 aes_generic ipv6 af_packet rfkill_input arc4 ecb b43 rfkill rng_core mac80211 cfg80211 led_class input_polldev ssb joydev pcmcia snd_via82xx gameport snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device i2c_viapro serio_raw snd i2c_core pcspkr psmouse evdev soundcore via686a via_agp shpchp yenta_socket rsrc_nonstatic pcmcia_core pci_hotplug rtc_cmos battery rtc_core rtc_lib parport_pc parport ac button ext3 jbd mbcache sg sr_mod cdrom sd_mod ata_generic pata_acpi pata_via uhci_hcd ehci_hcd floppy firewire_ohci libata tulip firewire_core crc_itu_t usbcore scsi_mod thermal processor fan
> Pid: 0, comm: swapper Not tainted 2.6.29-rc8-sidux-686 #1
> Call Trace:
>  [<c01319d7>] warn_slowpath+0x87/0xe0
>  [<d00523b7>] op32_set_current_rxslot+0x27/0x40 [b43]
>  [<d0052d93>] b43_dma_rx+0x193/0x420 [b43]
>  [<c0124fc3>] __wake_up_common+0x43/0x70
>  [<cfffcc62>] __ieee80211_rx+0xa2/0x6a0 [mac80211]
>  [<c011e9a5>] default_spin_lock_flags+0x5/0x10
>  [<c03a3f2e>] _spin_lock_irqsave+0x3e/0x60
>  [<cffeb337>] ieee80211_tasklet_handler+0x107/0x130 [mac80211]
>  [<c013692c>] tasklet_action+0x6c/0xf0
>  [<c0137147>] __do_softirq+0x87/0x140
>  [<c011e9a5>] default_spin_lock_flags+0x5/0x10
>  [<c03a3f2e>] _spin_lock_irqsave+0x3e/0x60
>  [<c0137255>] do_softirq+0x55/0x60
>  [<c0137495>] irq_exit+0x75/0x90
>  [<c0106378>] do_IRQ+0x48/0x90
>  [<c0104527>] common_interrupt+0x27/0x2c
>  [<cf8372e4>] acpi_idle_enter_simple+0x17a/0x1f4 [processor]
>  [<c02fd3bf>] cpuidle_idle_call+0x6f/0xc0
>  [<c0102de6>] cpu_idle+0x66/0xa0
> ---[ end trace c754f566bbe5ac47 ]---
[...]
> Sometimes even the firmware crashes and gets reloaded continously.
[...]
> Setting a fixed wlan rate (like 11M) seems to avoid this problem.
> 
> > I don't think this will print anything, the rate won't be 32, it's rather
> > too high. Could you apply also the appended debug one?
> 
> I will apply this patch and give it some more testing tomorrow evening, 
> this problem is almost 100% reproducable for me at the end of my router's
> range and doesn't happen in closer proximity.
[...]

Sorry for the late response, but I've been unexpectedly away from my 
BCM4306 system until today.

Thanks to the following (not yet mainline) patches by Michael Buesch and 
Lorenzo Nava on top of 2.6.29-rc8-git5, these problems seem to be "fixed" 
(well, the PHY errors are basically just hidden, but as they don't 
trigger the firmware watchdog anymore, it's much less of a problem and 
isn't actually a user visible problem anymore).

[PATCH] b43: Mask PHY TX error interrupt, if not debugging
	http://marc.info/?l=linux-wireless&m=123748731831778&w=2

[PATCH] b43: fix b43_plcp_get_bitrate_idx_ofdm return type
	http://marc.info/?l=linux-wireless&m=123774585529189&w=2


Confirming the patch descriptions, Jiri Slaby's debugging patch did reveal 
a signedness problem of the return value of in 
b43_plcp_get_bitrate_idx_ofdm(), which has been fixed by the patch above:

[ this trace happened *without* "b43: fix b43_plcp_get_bitrate_idx_ofdm 
  return type", and only "b43: Mask PHY TX error interrupt, if not 
  debugging" applied on top of 2.6.29-rc8-git5 ]
------------[ cut here ]------------
WARNING: at net/mac80211/rx.c:2236 __ieee80211_rx+0xab/0x6b0 [mac80211]()
Hardware name: Amilo D-Series
RATE=255, BAND=c
Modules linked in: ppdev lp aes_i586 aes_generic ipv6 af_packet rfkill_input arc4 ecb b43 rfkill rng_core mac80211 cfg80211 led_class input_polldev ssb joydev snd_via82xx gameport snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss pcmcia snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi i2c_viapro serio_raw snd_seq_device pcspkr i2c_core psmouse snd evdev soundcore via686a shpchp yenta_socket rsrc_nonstatic pcmcia_core via_agp pci_hotplug rtc_cmos parport_pc battery rtc_core rtc_lib parport ac button ext3 jbd mbcache sg sr_mod cdrom sd_mod ata_generic pata_acpi pata_via uhci_hcd ehci_hcd floppy firewire_ohci libata tulip firewire_core crc_itu_t usbcore scsi_mod thermal processor fan
Pid: 0, comm: swapper Not tainted 2.6.29-rc8-sidux-686 #1
Call Trace:
 [<c0131a67>] warn_slowpath+0x87/0xe0
 [<d002d377>] op32_set_current_rxslot+0x27/0x40 [b43]
 [<d002dd53>] b43_dma_rx+0x193/0x420 [b43]
 [<c01ae229>] add_partial+0x19/0x70
 [<cfcd834f>] ieee80211_tasklet_handler+0x11f/0x130 [mac80211]
 [<c03a4195>] _spin_unlock+0x5/0x20
 [<cfce9c6b>] __ieee80211_rx+0xab/0x6b0 [mac80211]
 [<c011ea35>] default_spin_lock_flags+0x5/0x10
 [<c03a3d7e>] _spin_lock_irqsave+0x3e/0x60
 [<cfcd8337>] ieee80211_tasklet_handler+0x107/0x130 [mac80211]
 [<c01369bc>] tasklet_action+0x6c/0xf0
 [<c01371d7>] __do_softirq+0x87/0x140
 [<c011ea35>] default_spin_lock_flags+0x5/0x10
 [<c03a3d7e>] _spin_lock_irqsave+0x3e/0x60
 [<c01372e5>] do_softirq+0x55/0x60
 [<c0137525>] irq_exit+0x75/0x90
 [<c0106378>] do_IRQ+0x48/0x90
 [<c0104527>] common_interrupt+0x27/0x2c
 [<cf8372cb>] acpi_idle_enter_simple+0x17a/0x1f4 [processor]
 [<c02fcfcf>] cpuidle_idle_call+0x6f/0xc0
 [<c0102de6>] cpu_idle+0x66/0xa0
---[ end trace ba8601a4d52a20d2 ]---
------------[ cut here ]------------		

So far (after 2.9 GB continuous kernel tarball downloads from a local 
mirror) b43 seems to be fine again:

wlan1     IEEE 802.11bg  ESSID:"gemini"
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:21:27:FF:51:A8
          Bit Rate=54 Mb/s   Tx-Power=20 dBm
          Retry min limit:7   RTS thr:off   Fragment thr=2352 B
          Power Management:off
          Link Quality=54/100  Signal level:-82 dBm  Noise level=-69 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

wlan1     Link encap:Ethernet  HWaddr 00:0f:66:d8:67:ca
          inet addr:192.168.0.70  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::20f:66ff:fed8:67ca/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2090104 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1082081 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3146865411 (2.9 GiB)  TX bytes:93054386 (88.7 MiB)

Fetched 83.2MB in 1min18s (1058kB/s)
[...]
Fetched 83.2MB in 1min1s (1362kB/s)

Thank you and sorry about the late response.

Regards
	Stefan Lippers-Hollmann


Post scriptum: I'm not able to trigger this trace with ath5k/ AR2425.
-- 
> >  net/mac80211/rx.c |    6 ++++--
> >  1 files changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> > index 7175ae8..5e17e57 100644
> > --- a/net/mac80211/rx.c
> > +++ b/net/mac80211/rx.c
> > @@ -2230,8 +2230,10 @@ void __ieee80211_rx(struct ieee80211_hw *hw, struct sk_buff *skb,
> >  		 * MCS aware. */
> >  		rate = &sband->bitrates[sband->n_bitrates - 1];
> >  	} else {
> > -		if (WARN_ON(status->rate_idx < 0 ||
> > -			    status->rate_idx >= sband->n_bitrates))
> > +		if (WARN(status->rate_idx < 0 ||
> > +			    status->rate_idx >= sband->n_bitrates,
> > +			    "RATE=%u, BAND=%x\n", status->rate_idx,
> > +			    sband->n_bitrates))
> >  			return;
> >  		rate = &sband->bitrates[status->rate_idx];
> >  	}

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/1] ath5k: fix hw rate index condition
  2009-03-15 21:27     ` Stefan Lippers-Hollmann
@ 2009-03-15 21:35       ` Michael Buesch
  2009-03-23  0:45       ` Stefan Lippers-Hollmann
  1 sibling, 0 replies; 32+ messages in thread
From: Michael Buesch @ 2009-03-15 21:35 UTC (permalink / raw)
  To: bcm43xx-dev
  Cc: Stefan Lippers-Hollmann, Jiri Slaby, Luis R. Rodriguez,
	Dhaval Giani, Bob Copeland, linux-wireless, linux-kernel,
	Nick Kossifidis, ath5k-devel, davem

On Sunday 15 March 2009 22:27:13 Stefan Lippers-Hollmann wrote:
> Hi
> 
> On Mittwoch, 7. Januar 2009, Jiri Slaby wrote:
> > On 01/07/2009 02:51 PM, Jiri Slaby wrote:
> > > Dhaval Giani wrote:
> > >> I see this on current git. Not sure how to reproduce it, has happened on
> > >> two random occasions. At both times, I was not connected to a wireless
> > >> network, but to wired networks.
> > >>
> > >> ------------[ cut here ]------------
> > >> WARNING: at net/mac80211/rx.c:2234 __ieee80211_rx+0x7f/0x559

I also see this triggering frequently on b43.
I'm not quite sure why it happens.

> Sometimes even the firmware crashes and gets reloaded continously.

Nah, that's most likely a separate bug.

-- 
Greetings, Michael.

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/1] ath5k: fix hw rate index condition
  2009-01-07 14:36   ` Jiri Slaby
  2009-01-07 15:22     ` Dhaval Giani
@ 2009-03-15 21:27     ` Stefan Lippers-Hollmann
  2009-03-15 21:35       ` Michael Buesch
  2009-03-23  0:45       ` Stefan Lippers-Hollmann
  1 sibling, 2 replies; 32+ messages in thread
From: Stefan Lippers-Hollmann @ 2009-03-15 21:27 UTC (permalink / raw)
  To: Jiri Slaby
  Cc: Dhaval Giani, linville, davem, linux-wireless, ath5k-devel,
	Nick Kossifidis, Luis R. Rodriguez, Bob Copeland, linux-kernel,
	bcm43xx-dev

Hi

On Mittwoch, 7. Januar 2009, Jiri Slaby wrote:
> On 01/07/2009 02:51 PM, Jiri Slaby wrote:
> > Dhaval Giani wrote:
> >> I see this on current git. Not sure how to reproduce it, has happened on
> >> two random occasions. At both times, I was not connected to a wireless
> >> network, but to wired networks.
> >>
> >> ------------[ cut here ]------------
> >> WARNING: at net/mac80211/rx.c:2234 __ieee80211_rx+0x7f/0x559
> >> ...
> >> Call Trace:
> >>  [<f80d4192>] __ieee80211_rx+0x7f/0x559 [mac80211]
> >>  [<f80a19f4>] ath5k_tasklet_rx+0x4f7/0x53b [ath5k]
> >> ...
> > 
> > Hmm, maybe ath5k is culprit. Could you apply the attached patch and
> > use the kernel till the problem appears again?

It seems as if this problem wouldn't be restricted to ath5k, I just 
triggered something very similar on b43 and 2.6.29-rc8-git1 (i386, hard 
preemption):

b43-phy0: Broadcom 4306 WLAN found (core revision 5)
wmaster0 (b43): not using net_device_ops yet
phy0: Selected rate control algorithm 'minstrel'
wlan0 (b43): not using net_device_ops yet
Broadcom 43xx driver loaded [ Features: PMLR, Firmware-ID: FW13 ]
udev: renamed network interface wlan0 to wlan1
[...]
input: b43-phy0 as /devices/virtual/input/input8
b43 ssb0:0: firmware: requesting b43/ucode5.fw
b43 ssb0:0: firmware: requesting b43/pcm5.fw
b43 ssb0:0: firmware: requesting b43/b0g0initvals5.fw
b43 ssb0:0: firmware: requesting b43/b0g0bsinitvals5.fw
b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
Registered led device: b43-phy0::tx
Registered led device: b43-phy0::rx
Registered led device: b43-phy0::radio
b43-phy0: Radio turned on by software
[...]
ADDRCONF(NETDEV_UP): wlan1: link is not ready
wlan1: authenticate with AP 00:15:f2:7e:9b:7d
wlan1: authenticated
wlan1: associate with AP 00:15:f2:7e:9b:7d
wlan1: RX AssocResp from 00:15:f2:7e:9b:7d (capab=0x411 status=0 aid=2)
wlan1: associated
ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[...]
wlan1: no IPv6 routers present
b43-phy0 ERROR: PHY transmission error
b43-phy0 ERROR: PHY transmission error

[ lots of these, likely to be caused by minstrel being a little too 
  optimistic about the possible wlan rates (it was more conservative in 
  2.6.28 and didn't happen there); the distance between both stations is 
  on the upper end ]

b43-phy0 ERROR: PHY transmission error
__ratelimit: 9 callbacks suppressed
b43-phy0 ERROR: PHY transmission error
b43-phy0 ERROR: PHY transmission error
------------[ cut here ]------------
WARNING: at net/mac80211/rx.c:2234 __ieee80211_rx+0xa2/0x6a0 [mac80211]()
Hardware name: Amilo D-Series
Modules linked in: ppdev lp aes_i586 aes_generic ipv6 af_packet rfkill_input arc4 ecb b43 rfkill rng_core mac80211 cfg80211 led_class input_polldev ssb joydev pcmcia snd_via82xx gameport snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device i2c_viapro serio_raw snd i2c_core pcspkr psmouse evdev soundcore via686a via_agp shpchp yenta_socket rsrc_nonstatic pcmcia_core pci_hotplug rtc_cmos battery rtc_core rtc_lib parport_pc parport ac button ext3 jbd mbcache sg sr_mod cdrom sd_mod ata_generic pata_acpi pata_via uhci_hcd ehci_hcd floppy firewire_ohci libata tulip firewire_core crc_itu_t usbcore scsi_mod thermal processor fan
Pid: 0, comm: swapper Not tainted 2.6.29-rc8-sidux-686 #1
Call Trace:
 [<c01319d7>] warn_slowpath+0x87/0xe0
 [<d00523b7>] op32_set_current_rxslot+0x27/0x40 [b43]
 [<d0052d93>] b43_dma_rx+0x193/0x420 [b43]
 [<c0124fc3>] __wake_up_common+0x43/0x70
 [<cfffcc62>] __ieee80211_rx+0xa2/0x6a0 [mac80211]
 [<c011e9a5>] default_spin_lock_flags+0x5/0x10
 [<c03a3f2e>] _spin_lock_irqsave+0x3e/0x60
 [<cffeb337>] ieee80211_tasklet_handler+0x107/0x130 [mac80211]
 [<c013692c>] tasklet_action+0x6c/0xf0
 [<c0137147>] __do_softirq+0x87/0x140
 [<c011e9a5>] default_spin_lock_flags+0x5/0x10
 [<c03a3f2e>] _spin_lock_irqsave+0x3e/0x60
 [<c0137255>] do_softirq+0x55/0x60
 [<c0137495>] irq_exit+0x75/0x90
 [<c0106378>] do_IRQ+0x48/0x90
 [<c0104527>] common_interrupt+0x27/0x2c
 [<cf8372e4>] acpi_idle_enter_simple+0x17a/0x1f4 [processor]
 [<c02fd3bf>] cpuidle_idle_call+0x6f/0xc0
 [<c0102de6>] cpu_idle+0x66/0xa0
---[ end trace c754f566bbe5ac47 ]---
------------[ cut here ]------------
WARNING: at net/mac80211/rx.c:2234 __ieee80211_rx+0xa2/0x6a0 [mac80211]()
Hardware name: Amilo D-Series
Modules linked in: ppdev lp aes_i586 aes_generic ipv6 af_packet rfkill_input arc4 ecb b43 rfkill rng_core mac80211 cfg80211 led_class input_polldev ssb joydev pcmcia snd_via82xx gameport snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device i2c_viapro serio_raw snd i2c_core pcspkr psmouse evdev soundcore via686a via_agp shpchp yenta_socket rsrc_nonstatic pcmcia_core pci_hotplug rtc_cmos battery rtc_core rtc_lib parport_pc parport ac button ext3 jbd mbcache sg sr_mod cdrom sd_mod ata_generic pata_acpi pata_via uhci_hcd ehci_hcd floppy firewire_ohci libata tulip firewire_core crc_itu_t usbcore scsi_mod thermal processor fan
Pid: 0, comm: swapper Tainted: G        W  2.6.29-rc8-sidux-686 #1
Call Trace:
 [<c01319d7>] warn_slowpath+0x87/0xe0
 [<d00523b7>] op32_set_current_rxslot+0x27/0x40 [b43]
 [<d0052d93>] b43_dma_rx+0x193/0x420 [b43]
 [<d0055f15>] b43_led_turn_off+0x55/0x90 [b43]
 [<cfffcc62>] __ieee80211_rx+0xa2/0x6a0 [mac80211]
 [<c011e9a5>] default_spin_lock_flags+0x5/0x10
 [<c03a3f2e>] _spin_lock_irqsave+0x3e/0x60
 [<cffeb337>] ieee80211_tasklet_handler+0x107/0x130 [mac80211]
 [<c013692c>] tasklet_action+0x6c/0xf0
 [<c0137147>] __do_softirq+0x87/0x140
 [<c011e9a5>] default_spin_lock_flags+0x5/0x10
 [<c03a3f2e>] _spin_lock_irqsave+0x3e/0x60
 [<c0137255>] do_softirq+0x55/0x60
 [<c0137495>] irq_exit+0x75/0x90
 [<c0106378>] do_IRQ+0x48/0x90
 [<c0104527>] common_interrupt+0x27/0x2c
 [<cf8372e4>] acpi_idle_enter_simple+0x17a/0x1f4 [processor]
 [<c02fd3bf>] cpuidle_idle_call+0x6f/0xc0
 [<c0102de6>] cpu_idle+0x66/0xa0
---[ end trace c754f566bbe5ac48 ]---
------------[ cut here ]------------
WARNING: at net/mac80211/rx.c:2234 __ieee80211_rx+0xa2/0x6a0 [mac80211]()
Hardware name: Amilo D-Series
Modules linked in: ppdev lp aes_i586 aes_generic ipv6 af_packet rfkill_input arc4 ecb b43 rfkill rng_core mac80211 cfg80211 led_class input_polldev ssb joydev pcmcia snd_via82xx gameport snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device i2c_viapro serio_raw snd i2c_core pcspkr psmouse evdev soundcore via686a via_agp shpchp yenta_socket rsrc_nonstatic pcmcia_core pci_hotplug rtc_cmos battery rtc_core rtc_lib parport_pc parport ac button ext3 jbd mbcache sg sr_mod cdrom sd_mod ata_generic pata_acpi pata_via uhci_hcd ehci_hcd floppy firewire_ohci libata tulip firewire_core crc_itu_t usbcore scsi_mod thermal processor fan
Pid: 1873, comm: kjournald Tainted: G        W  2.6.29-rc8-sidux-686 #1
Call Trace:
 [<c01319d7>] warn_slowpath+0x87/0xe0
 [<d00523b7>] op32_set_current_rxslot+0x27/0x40 [b43]
 [<d0052d93>] b43_dma_rx+0x193/0x420 [b43]
 [<cfffcc62>] __ieee80211_rx+0xa2/0x6a0 [mac80211]
 [<c011e9a5>] default_spin_lock_flags+0x5/0x10
 [<c03a3f2e>] _spin_lock_irqsave+0x3e/0x60
 [<cffeb337>] ieee80211_tasklet_handler+0x107/0x130 [mac80211]
 [<c013692c>] tasklet_action+0x6c/0xf0
 [<c0137147>] __do_softirq+0x87/0x140
 [<c011e9a5>] default_spin_lock_flags+0x5/0x10
 [<c03a3f2e>] _spin_lock_irqsave+0x3e/0x60
 [<c0137255>] do_softirq+0x55/0x60
 [<c0137495>] irq_exit+0x75/0x90
 [<c0106378>] do_IRQ+0x48/0x90
 [<c01d3f44>] generic_block_bmap+0x54/0x70
 [<c0104527>] common_interrupt+0x27/0x2c
 [<cfbf723c>] __journal_file_buffer+0xdc/0x1d0 [jbd]
 [<cfbf7397>] journal_file_buffer+0x67/0xc0 [jbd]
 [<cfbfe102>] journal_write_metadata_buffer+0x1e2/0x3dc [jbd]
 [<cfbf9e26>] journal_commit_transaction+0x806/0x1120 [jbd]
 [<c013bcc7>] lock_timer_base+0x27/0x60
 [<cfbfd82c>] kjournald+0xac/0x1f0 [jbd]
 [<c01464b0>] autoremove_wake_function+0x0/0x50
 [<cfbfd780>] kjournald+0x0/0x1f0 [jbd]
 [<c01460e9>] kthread+0x39/0x70
 [<c01460b0>] kthread+0x0/0x70
 [<c0104793>] kernel_thread_helper+0x7/0x14
---[ end trace c754f566bbe5ac49 ]---
__ratelimit: 21 callbacks suppressed
b43-phy0 ERROR: PHY transmission error
[...]

Sometimes even the firmware crashes and gets reloaded continously.

wlan1     IEEE 802.11bg  ESSID:"soyuz"
          Mode:Managed  Frequency:2.422 GHz  Access Point: 00:15:F2:7E:9B:7D
          Bit Rate=18 Mb/s   Tx-Power=20 dBm
          Retry min limit:7   RTS thr:off   Fragment thr=2352 B
          Encryption key:<wpa2psk> [3]   Security mode:open
          Power Management:off
          Link Quality=53/100  Signal level:-75 dBm  Noise level=-65 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

Setting a fixed wlan rate (like 11M) seems to avoid this problem.

> I don't think this will print anything, the rate won't be 32, it's rather
> too high. Could you apply also the appended debug one?

I will apply this patch and give it some more testing tomorrow evening, 
this problem is almost 100% reproducable for me at the end of my router's
range and doesn't happen in closer proximity.

> ---
>  net/mac80211/rx.c |    6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> index 7175ae8..5e17e57 100644
> --- a/net/mac80211/rx.c
> +++ b/net/mac80211/rx.c
> @@ -2230,8 +2230,10 @@ void __ieee80211_rx(struct ieee80211_hw *hw, struct sk_buff *skb,
>  		 * MCS aware. */
>  		rate = &sband->bitrates[sband->n_bitrates - 1];
>  	} else {
> -		if (WARN_ON(status->rate_idx < 0 ||
> -			    status->rate_idx >= sband->n_bitrates))
> +		if (WARN(status->rate_idx < 0 ||
> +			    status->rate_idx >= sband->n_bitrates,
> +			    "RATE=%u, BAND=%x\n", status->rate_idx,
> +			    sband->n_bitrates))
>  			return;
>  		rate = &sband->bitrates[status->rate_idx];
>  	}

Regards
	Stefan Lippers-Hollmann

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/1] ath5k: fix hw rate index condition
  2009-02-15 13:47           ` Bob Copeland
@ 2009-02-28 23:08             ` Jiri Slaby
  2009-03-30  8:59               ` Dhaval Giani
  0 siblings, 1 reply; 32+ messages in thread
From: Jiri Slaby @ 2009-02-28 23:08 UTC (permalink / raw)
  To: Bob Copeland
  Cc: Dhaval Giani, Dhaval Giani, linville, davem, linux-wireless,
	ath5k-devel, Nick Kossifidis, Luis R. Rodriguez, linux-kernel

On 15.2.2009 14:47, Bob Copeland wrote:
> On Mon, Feb 02, 2009 at 01:27:39PM +0530, Dhaval Giani wrote:
>> So I finally managed to hit this on 2.6.29-rc3. It is hard to
>> reproduce, so I hope so much information is enough to give you a good
>> guess. This time it hit while trying to connect to an open network at
>> the airport.
>
>> WARNING: at net/mac80211/rx.c:2236 __ieee80211_rx+0x96/0x571 [mac80211]()
>> Hardware name: 2007CS3
>> RATE=255, BAND=8
>
> band is supposed to be sc->curband?  8 is way wrong.

If you look into the patch which outputs this (backtrace in this 
thread), sband->n_bitrates is 8. I have no idea what I have been smoking 
the day I wrote it, but BAND= for sure isn't the right name for that 
thing. Sorry for the confusion.

> rate could be 255
> if, for some reason, the hardware rate wasn't in the rate table.

So, we have a fix for this, right? I mean the u8->s8 sc->rate_idx 
conversion or alike...

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/1] ath5k: fix hw rate index condition
  2009-02-02  7:57         ` Dhaval Giani
@ 2009-02-15 13:47           ` Bob Copeland
  2009-02-28 23:08             ` Jiri Slaby
  0 siblings, 1 reply; 32+ messages in thread
From: Bob Copeland @ 2009-02-15 13:47 UTC (permalink / raw)
  To: Dhaval Giani
  Cc: Jiri Slaby, Dhaval Giani, linville, davem, linux-wireless,
	ath5k-devel, Nick Kossifidis, Luis R. Rodriguez, linux-kernel

On Mon, Feb 02, 2009 at 01:27:39PM +0530, Dhaval Giani wrote:
> So I finally managed to hit this on 2.6.29-rc3. It is hard to
> reproduce, so I hope so much information is enough to give you a good
> guess. This time it hit while trying to connect to an open network at
> the airport.

> WARNING: at net/mac80211/rx.c:2236 __ieee80211_rx+0x96/0x571 [mac80211]()
> Hardware name: 2007CS3
> RATE=255, BAND=8

band is supposed to be sc->curband?  8 is way wrong.  rate could be 255
if, for some reason, the hardware rate wasn't in the rate table.

> Pid: 2634, comm: X Not tainted 2.6.29-rc3 #18
> Call Trace:
>  [<c0430636>] warn_slowpath+0x76/0xad
>  [<c04508d7>] ? __lock_acquire+0xb36/0xb45
>  [<f7dd0205>] __ieee80211_rx+0x96/0x571 [mac80211]
>  [<f7e37976>] ath5k_tasklet_rx+0x4fb/0x53d [ath5k]
>  [<c06fa5c3>] ? _spin_unlock_irq+0x27/0x34
>  [<c0434f91>] tasklet_action+0x85/0xf0

Interestingly I hit this just the other day -- I was debugging something
else and had a serial console hooked up, otherwise I wouldn't have
noticed at all.  It happened at some point during a suspend-to-ram
sequence, which makes at least my version sound like a race condition
of some sort.




^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/1] ath5k: fix hw rate index condition
  2009-01-07 15:30       ` Jiri Slaby
@ 2009-02-02  7:57         ` Dhaval Giani
  2009-02-15 13:47           ` Bob Copeland
  0 siblings, 1 reply; 32+ messages in thread
From: Dhaval Giani @ 2009-02-02  7:57 UTC (permalink / raw)
  To: Jiri Slaby
  Cc: Dhaval Giani, linville, davem, linux-wireless, ath5k-devel,
	Nick Kossifidis, Luis R. Rodriguez, Bob Copeland, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 435 bytes --]

Hi Jiri,

On Wed, Jan 7, 2009 at 9:00 PM, Jiri Slaby <jirislaby@gmail.com> wrote:
> On 01/07/2009 04:22 PM, Dhaval Giani wrote:
>> I will get back to you in about a day or two.
>
> No problem. Thanks.
>

So I finally managed to hit this on 2.6.29-rc3. It is hard to
reproduce, so I hope so much information is enough to give you a good
guess. This time it hit while trying to connect to an open network at
the airport.

Thanks,
Dhaval

[-- Attachment #2: dmesg.jiri --]
[-- Type: application/octet-stream, Size: 44159 bytes --]

Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.29-rc3 (dhaval@gondor.in.ibm.com) (gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) ) #18 SMP Fri Jan 30 19:39:00 IST 2009
KERNEL supported cpus:
  Intel GenuineIntel
  AMD AuthenticAMD
  NSC Geode by NSC
  Cyrix CyrixInstead
  Centaur CentaurHauls
  Transmeta GenuineTMx86
  Transmeta TransmetaCPU
  UMC UMC UMC UMC
PAT WC disabled due to known CPU erratum.
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
 BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000d2000 - 00000000000d4000 (reserved)
 BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000007fed0000 (usable)
 BIOS-e820: 000000007fed0000 - 000000007fedf000 (ACPI data)
 BIOS-e820: 000000007fedf000 - 000000007ff00000 (ACPI NVS)
 BIOS-e820: 000000007ff00000 - 0000000080000000 (reserved)
 BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
 BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
 BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved)
 BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ff800000 - 0000000100000000 (reserved)
DMI present.
last_pfn = 0x7fed0 max_arch_pfn = 0x100000
kernel direct mapping tables up to 373fe000 @ 7000-d000
RAMDISK: 37ce2000 - 37fef6ca
Allocated new RAMDISK: 00f2d000 - 0123a6ca
Move RAMDISK from 0000000037ce2000 - 0000000037fef6c9 to 00f2d000 - 0123a6c9
ACPI: RSDP 000F67D0, 0024 (r2 LENOVO)
ACPI: XSDT 7FED1486, 0084 (r1 LENOVO TP-79        2090  LTP        0)
ACPI: FACP 7FED1600, 00F4 (r3 LENOVO TP-79        2090 LNVO        1)
ACPI Warning (tbfadt-0568): 32/64X length mismatch in Gpe0Block: 64/32 [20081204]
ACPI Warning (tbfadt-0568): 32/64X length mismatch in Gpe1Block: 0/32 [20081204]
ACPI Warning (tbfadt-0596): Optional field Gpe1Block has zero address or length: 000000000000102C/0 [20081204]
FADT: X_PM1a_EVT_BLK.bit_width (16) does not match PM1_EVT_LEN (4)
ACPI: DSDT 7FED195E, D481 (r1 LENOVO TP-79        2090 MSFT  100000E)
ACPI: FACS 7FEF4000, 0040
ACPI: SSDT 7FED17B4, 01AA (r1 LENOVO TP-79        2090 MSFT  100000E)
ACPI: ECDT 7FEDEDDF, 0052 (r1 LENOVO TP-79        2090 LNVO        1)
ACPI: TCPA 7FEDEE31, 0032 (r2 LENOVO TP-79        2090 LNVO        1)
ACPI: APIC 7FEDEE63, 0068 (r1 LENOVO TP-79        2090 LNVO        1)
ACPI: MCFG 7FEDEECB, 003C (r1 LENOVO TP-79        2090 LNVO        1)
ACPI: HPET 7FEDEF07, 0038 (r1 LENOVO TP-79        2090 LNVO        1)
ACPI: BOOT 7FEDEFD8, 0028 (r1 LENOVO TP-79        2090  LTP        1)
ACPI: SSDT 7FEF2697, 025F (r1 LENOVO TP-79        2090 INTL 20050513)
ACPI: SSDT 7FEF28F6, 00A6 (r1 LENOVO TP-79        2090 INTL 20050513)
ACPI: SSDT 7FEF299C, 04F7 (r1 LENOVO TP-79        2090 INTL 20050513)
ACPI: SSDT 7FEF2E93, 01D8 (r1 LENOVO TP-79        2090 INTL 20050513)
ACPI: Local APIC address 0xfee00000
1162MB HIGHMEM available.
883MB LOWMEM available.
  mapped low ram: 0 - 373fe000
  low ram: 00000000 - 373fe000
  bootmap 00008000 - 0000ee80
(9 early reservations) ==> bootmem [0000000000 - 00373fe000]
  #0 [0000000000 - 0000001000]   BIOS data page ==> [0000000000 - 0000001000]
  #1 [0000001000 - 0000002000]    EX TRAMPOLINE ==> [0000001000 - 0000002000]
  #2 [0000006000 - 0000007000]       TRAMPOLINE ==> [0000006000 - 0000007000]
  #3 [0000400000 - 0000f27d6c]    TEXT DATA BSS ==> [0000400000 - 0000f27d6c]
  #4 [0000f28000 - 0000f2d000]    INIT_PG_TABLE ==> [0000f28000 - 0000f2d000]
  #5 [000009f000 - 0000100000]    BIOS reserved ==> [000009f000 - 0000100000]
  #6 [0000007000 - 0000008000]          PGTABLE ==> [0000007000 - 0000008000]
  #7 [0000f2d000 - 000123a6ca]      NEW RAMDISK ==> [0000f2d000 - 000123a6ca]
  #8 [0000008000 - 000000f000]          BOOTMAP ==> [0000008000 - 000000f000]
found SMP MP-table at [c00f6810] 000f6810
Zone PFN ranges:
  DMA      0x00000000 -> 0x00001000
  Normal   0x00001000 -> 0x000373fe
  HighMem  0x000373fe -> 0x0007fed0
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
    0: 0x00000000 -> 0x0000009f
    0: 0x00000100 -> 0x0007fed0
On node 0 totalpages: 523887
free_area_init_node: node 0, pgdat c0892400, node_mem_map c123b000
  DMA zone: 60 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 3939 pages, LIFO batch:0
  Normal zone: 3255 pages used for memmap
  Normal zone: 218951 pages, LIFO batch:31
  HighMem zone: 4361 pages used for memmap
  HighMem zone: 293321 pages, LIFO batch:31
Using APIC driver default
ACPI: PM-Timer IO Port: 0x1008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
ACPI: HPET id: 0x8086a201 base: 0xfed00000
SMP: Allowing 2 CPUs, 0 hotplug CPUs
PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
PM: Registered nosave memory: 00000000000a0000 - 00000000000d2000
PM: Registered nosave memory: 00000000000d2000 - 00000000000d4000
PM: Registered nosave memory: 00000000000d4000 - 00000000000dc000
PM: Registered nosave memory: 00000000000dc000 - 0000000000100000
Allocating PCI resources starting at 88000000 (gap: 80000000:70000000)
NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:2 nr_node_ids:1
PERCPU: Allocating 1351680 bytes of per cpu data
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 516211
Kernel command line: ro root=UUID=6cd5945e-862e-4511-854c-ca4ced88434e rhgb quiet
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
Experimental hierarchical RCU implementation.
Experimental hierarchical RCU init done.
CPU 0 irqstacks, hard=c0a9a000 soft=c0a7a000
PID hash table entries: 4096 (order: 12, 16384 bytes)
Extended CMOS year: 2000
Fast TSC calibration using PIT
Detected 2161.280 MHz processor.
Console: colour VGA+ 80x25
console [tty0] enabled
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES:  8
... MAX_LOCK_DEPTH:          48
... MAX_LOCKDEP_KEYS:        8191
... CLASSHASH_SIZE:          4096
... MAX_LOCKDEP_ENTRIES:     8192
... MAX_LOCKDEP_CHAINS:      16384
... CHAINHASH_SIZE:          8192
 memory used by lock dependency info: 2591 kB
 per task-struct memory footprint: 1920 bytes
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
allocated 10479680 bytes of page_cgroup
please try cgroup_disable=memory option if you don't want
Memory: 2035428k/2095936k available (3066k kernel code, 59196k reserved, 1860k data, 1672k init, 1190728k highmem)
virtual kernel memory layout:
    fixmap  : 0xffc57000 - 0xfffff000   (3744 kB)
    pkmap   : 0xff400000 - 0xff800000   (4096 kB)
    vmalloc : 0xf7bfe000 - 0xff3fe000   ( 120 MB)
    lowmem  : 0xc0000000 - 0xf73fe000   ( 883 MB)
      .init : 0xc08d5000 - 0xc0a77000   (1672 kB)
      .data : 0xc06febde - 0xc08cfdd8   (1860 kB)
      .text : 0xc0400000 - 0xc06febde   (3066 kB)
Checking if this processor honours the WP bit even in supervisor mode...Ok.
SLUB: Genslabs=12, HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
hpet clockevent registered
HPET: 3 timers in total, 0 timers will be used for per-cpu timer
Calibrating delay loop (skipped), value calculated using timer frequency.. 4322.56 BogoMIPS (lpj=2161280)
Security Framework initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
Mount-cache hash table entries: 512
Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
Initializing cgroup subsys devices
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 2048K
[ds] using pentium m configuration
[ds] pebs not available
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
using mwait in idle threads.
Checking 'hlt' instruction... OK.
ACPI: Core revision 20081204
ftrace: converting mcount calls to 0f 1f 44 00 00
ftrace: allocating 16642 entries in 66 pages
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
CPU0: Genuine Intel(R) CPU           T2600  @ 2.16GHz stepping 08
lockdep: fixing up alternatives.
CPU 1 irqstacks, hard=c0a9b000 soft=c0a7b000
Booting processor 1 APIC 0x1 ip 0x6000
Initializing CPU#1
Calibrating delay using timer specific routine.. 4322.39 BogoMIPS (lpj=2161199)
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 2048K
[ds] using pentium m configuration
[ds] pebs not available
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Genuine Intel(R) CPU           T2600  @ 2.16GHz stepping 08
checking TSC synchronization [CPU#0 -> CPU#1]:
Measured 615459 cycles TSC warp between CPUs, turning off TSC clock.
Marking TSC unstable due to check_tsc_sync_source failed
Brought up 2 CPUs
Total of 2 processors activated (8644.95 BogoMIPS).
CPU0 attaching sched-domain:
 domain 0: span 0-1 level MC
  groups: 0 1
CPU1 attaching sched-domain:
 domain 0: span 0-1 level MC
  groups: 1 0
net_namespace: 904 bytes
Booting paravirtualized kernel on bare hardware
Time: 14:14:54  Date: 01/30/09
NET: Registered protocol family 16
ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
ACPI: bus type pci registered
PCI: MCFG configuration 0: base f0000000 segment 0 buses 0 - 63
PCI: MCFG area at f0000000 reserved in E820
PCI: Using MMCONFIG for extended config space
PCI: Using configuration type 1 for base access
bio: create slab <bio-0> at 0
ACPI: EC: EC description table is found, configuring boot EC
ACPI: EC: non-query interrupt received, switching to interrupt mode
ACPI: Interpreter enabled
ACPI: (supports S0 S3 S4 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: EC: GPE = 0x1c, I/O: command/status = 0x66, data = 0x62
ACPI: EC: driver started in interrupt mode
ACPI: ACPI Dock Station Driver: 3 docks/bays found
ACPI: PCI Root Bridge [PCI0] (0000:00)
pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
pci 0000:00:01.0: PME# disabled
pci 0000:00:1b.0: reg 10 64bit mmio: [0xee400000-0xee403fff]
pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
pci 0000:00:1b.0: PME# disabled
pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
pci 0000:00:1c.0: PME# disabled
pci 0000:00:1c.1: PME# supported from D0 D3hot D3cold
pci 0000:00:1c.1: PME# disabled
pci 0000:00:1c.2: PME# supported from D0 D3hot D3cold
pci 0000:00:1c.2: PME# disabled
pci 0000:00:1c.3: PME# supported from D0 D3hot D3cold
pci 0000:00:1c.3: PME# disabled
pci 0000:00:1d.0: reg 20 io port: [0x1800-0x181f]
pci 0000:00:1d.1: reg 20 io port: [0x1820-0x183f]
pci 0000:00:1d.2: reg 20 io port: [0x1840-0x185f]
pci 0000:00:1d.3: reg 20 io port: [0x1860-0x187f]
pci 0000:00:1d.7: reg 10 32bit mmio: [0xee404000-0xee4043ff]
pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
pci 0000:00:1d.7: PME# disabled
pci 0000:00:1f.0: quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO
pci 0000:00:1f.0: quirk: region 1180-11bf claimed by ICH6 GPIO
pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 1600 (mask 007f)
pci 0000:00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 15e0 (mask 000f)
pci 0000:00:1f.0: ICH7 LPC Generic IO decode 3 PIO at 1680 (mask 001f)
pci 0000:00:1f.1: reg 10 io port: [0x00-0x07]
pci 0000:00:1f.1: reg 14 io port: [0x00-0x03]
pci 0000:00:1f.1: reg 18 io port: [0x00-0x07]
pci 0000:00:1f.1: reg 1c io port: [0x00-0x03]
pci 0000:00:1f.1: reg 20 io port: [0x1880-0x188f]
pci 0000:00:1f.2: reg 10 io port: [0x18c8-0x18cf]
pci 0000:00:1f.2: reg 14 io port: [0x18ac-0x18af]
pci 0000:00:1f.2: reg 18 io port: [0x18c0-0x18c7]
pci 0000:00:1f.2: reg 1c io port: [0x18a8-0x18ab]
pci 0000:00:1f.2: reg 20 io port: [0x18b0-0x18bf]
pci 0000:00:1f.2: reg 24 32bit mmio: [0xee404400-0xee4047ff]
pci 0000:00:1f.2: PME# supported from D3hot
pci 0000:00:1f.2: PME# disabled
pci 0000:00:1f.3: reg 20 io port: [0x18e0-0x18ff]
pci 0000:01:00.0: reg 10 32bit mmio: [0xd0000000-0xdfffffff]
pci 0000:01:00.0: reg 14 io port: [0x2000-0x20ff]
pci 0000:01:00.0: reg 18 32bit mmio: [0xee100000-0xee10ffff]
pci 0000:01:00.0: reg 30 32bit mmio: [0x000000-0x01ffff]
pci 0000:01:00.0: supports D1 D2
pci 0000:00:01.0: bridge io port: [0x2000-0x2fff]
pci 0000:00:01.0: bridge 32bit mmio: [0xee100000-0xee1fffff]
pci 0000:00:01.0: bridge 64bit mmio pref: [0xd0000000-0xdfffffff]
pci 0000:02:00.0: reg 10 32bit mmio: [0xee000000-0xee01ffff]
pci 0000:02:00.0: reg 18 io port: [0x3000-0x301f]
pci 0000:02:00.0: PME# supported from D0 D3hot D3cold
pci 0000:02:00.0: PME# disabled
pci 0000:00:1c.0: bridge io port: [0x3000-0x3fff]
pci 0000:00:1c.0: bridge 32bit mmio: [0xee000000-0xee0fffff]
pci 0000:03:00.0: reg 10 64bit mmio: [0xedf00000-0xedf0ffff]
pci 0000:00:1c.1: bridge io port: [0x4000-0x5fff]
pci 0000:00:1c.1: bridge 32bit mmio: [0xec000000-0xedffffff]
pci 0000:00:1c.1: bridge 64bit mmio pref: [0xe4000000-0xe40fffff]
pci 0000:00:1c.2: bridge io port: [0x6000-0x7fff]
pci 0000:00:1c.2: bridge 32bit mmio: [0xe8000000-0xe9ffffff]
pci 0000:00:1c.2: bridge 64bit mmio pref: [0xe4100000-0xe41fffff]
pci 0000:00:1c.3: bridge io port: [0x8000-0x9fff]
pci 0000:00:1c.3: bridge 32bit mmio: [0xea000000-0xebffffff]
pci 0000:00:1c.3: bridge 64bit mmio pref: [0xe4200000-0xe42fffff]
pci 0000:15:00.0: reg 10 32bit mmio: [0xe4300000-0xe4300fff]
pci 0000:15:00.0: supports D1 D2
pci 0000:15:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:15:00.0: PME# disabled
pci 0000:00:1e.0: transparent bridge
pci 0000:00:1e.0: bridge io port: [0xa000-0xdfff]
pci 0000:00:1e.0: bridge 32bit mmio: [0xe4300000-0xe7ffffff]
pci 0000:00:1e.0: bridge 64bit mmio pref: [0xe0000000-0xe3ffffff]
pci_bus 0000:00: on NUMA node 0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP2._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP3._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: Power Resource [PUBS] (on)
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
NetLabel: Initializing
NetLabel:  domain hash size = 128
NetLabel:  protocols = UNLABELED CIPSOv4
NetLabel:  unlabeled traffic allowed by default
hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
hpet0: 3 comparators, 64-bit 14.318180 MHz counter
Switched to high resolution mode on CPU 0
Switched to high resolution mode on CPU 1
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 12 devices
ACPI: ACPI bus type pnp unregistered
system 00:00: iomem range 0x0-0x9ffff could not be reserved
system 00:00: iomem range 0xc0000-0xc3fff could not be reserved
system 00:00: iomem range 0xc4000-0xc7fff could not be reserved
system 00:00: iomem range 0xc8000-0xcbfff could not be reserved
system 00:00: iomem range 0xcc000-0xcffff could not be reserved
system 00:00: iomem range 0xd0000-0xd3fff could not be reserved
system 00:00: iomem range 0xdc000-0xdffff could not be reserved
system 00:00: iomem range 0xe0000-0xe3fff could not be reserved
system 00:00: iomem range 0xe4000-0xe7fff could not be reserved
system 00:00: iomem range 0xe8000-0xebfff could not be reserved
system 00:00: iomem range 0xec000-0xeffff could not be reserved
system 00:00: iomem range 0xf0000-0xfffff could not be reserved
system 00:00: iomem range 0x100000-0x7fffffff could not be reserved
system 00:00: iomem range 0xfec00000-0xfed3ffff could not be reserved
system 00:00: iomem range 0xfed41000-0xffffffff could not be reserved
system 00:02: ioport range 0x164e-0x164f has been reserved
system 00:02: ioport range 0x1000-0x107f has been reserved
system 00:02: ioport range 0x1180-0x11bf has been reserved
system 00:02: ioport range 0x800-0x80f has been reserved
system 00:02: ioport range 0x15e0-0x15ef has been reserved
system 00:02: ioport range 0x1600-0x165f could not be reserved
system 00:02: iomem range 0xf0000000-0xf3ffffff has been reserved
system 00:02: iomem range 0xfed1c000-0xfed1ffff has been reserved
system 00:02: iomem range 0xfed14000-0xfed17fff has been reserved
system 00:02: iomem range 0xfed18000-0xfed18fff has been reserved
system 00:02: iomem range 0xfed19000-0xfed19fff has been reserved
pci 0000:00:01.0: PCI bridge, secondary bus 0000:01
pci 0000:00:01.0:   IO window: 0x2000-0x2fff
pci 0000:00:01.0:   MEM window: 0xee100000-0xee1fffff
pci 0000:00:01.0:   PREFETCH window: 0x000000d0000000-0x000000dfffffff
pci 0000:00:1c.0: PCI bridge, secondary bus 0000:02
pci 0000:00:1c.0:   IO window: 0x3000-0x3fff
pci 0000:00:1c.0:   MEM window: 0xee000000-0xee0fffff
pci 0000:00:1c.0:   PREFETCH window: disabled
pci 0000:00:1c.1: PCI bridge, secondary bus 0000:03
pci 0000:00:1c.1:   IO window: 0x4000-0x5fff
pci 0000:00:1c.1:   MEM window: 0xec000000-0xedffffff
pci 0000:00:1c.1:   PREFETCH window: 0x000000e4000000-0x000000e40fffff
pci 0000:00:1c.2: PCI bridge, secondary bus 0000:04
pci 0000:00:1c.2:   IO window: 0x6000-0x7fff
pci 0000:00:1c.2:   MEM window: 0xe8000000-0xe9ffffff
pci 0000:00:1c.2:   PREFETCH window: 0x000000e4100000-0x000000e41fffff
pci 0000:00:1c.3: PCI bridge, secondary bus 0000:0c
pci 0000:00:1c.3:   IO window: 0x8000-0x9fff
pci 0000:00:1c.3:   MEM window: 0xea000000-0xebffffff
pci 0000:00:1c.3:   PREFETCH window: 0x000000e4200000-0x000000e42fffff
pci 0000:15:00.0: CardBus bridge, secondary bus 0000:16
pci 0000:15:00.0:   IO window: 0x00a000-0x00a0ff
pci 0000:15:00.0:   IO window: 0x00a400-0x00a4ff
pci 0000:15:00.0:   PREFETCH window: 0xe0000000-0xe3ffffff
pci 0000:15:00.0:   MEM window: 0x88000000-0x8bffffff
pci 0000:00:1e.0: PCI bridge, secondary bus 0000:15
pci 0000:00:1e.0:   IO window: 0xa000-0xdfff
pci 0000:00:1e.0:   MEM window: 0xe4300000-0xe7ffffff
pci 0000:00:1e.0:   PREFETCH window: 0x000000e0000000-0x000000e3ffffff
pci 0000:00:01.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
pci 0000:00:01.0: setting latency timer to 64
pci 0000:00:1c.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
pci 0000:00:1c.0: setting latency timer to 64
pci 0000:00:1c.1: PCI INT B -> GSI 21 (level, low) -> IRQ 21
pci 0000:00:1c.1: setting latency timer to 64
pci 0000:00:1c.2: PCI INT C -> GSI 22 (level, low) -> IRQ 22
pci 0000:00:1c.2: setting latency timer to 64
pci 0000:00:1c.3: PCI INT D -> GSI 23 (level, low) -> IRQ 23
pci 0000:00:1c.3: setting latency timer to 64
pci 0000:00:1e.0: enabling device (0005 -> 0007)
pci 0000:00:1e.0: setting latency timer to 64
pci 0000:15:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
pci_bus 0000:00: resource 0 io:  [0x00-0xffff]
pci_bus 0000:00: resource 1 mem: [0x000000-0xffffffff]
pci_bus 0000:01: resource 0 io:  [0x2000-0x2fff]
pci_bus 0000:01: resource 1 mem: [0xee100000-0xee1fffff]
pci_bus 0000:01: resource 2 mem: [0xd0000000-0xdfffffff]
pci_bus 0000:01: resource 3 mem: [0x0-0x0]
pci_bus 0000:02: resource 0 io:  [0x3000-0x3fff]
pci_bus 0000:02: resource 1 mem: [0xee000000-0xee0fffff]
pci_bus 0000:02: resource 2 mem: [0x0-0x0]
pci_bus 0000:02: resource 3 mem: [0x0-0x0]
pci_bus 0000:03: resource 0 io:  [0x4000-0x5fff]
pci_bus 0000:03: resource 1 mem: [0xec000000-0xedffffff]
pci_bus 0000:03: resource 2 mem: [0xe4000000-0xe40fffff]
pci_bus 0000:03: resource 3 mem: [0x0-0x0]
pci_bus 0000:04: resource 0 io:  [0x6000-0x7fff]
pci_bus 0000:04: resource 1 mem: [0xe8000000-0xe9ffffff]
pci_bus 0000:04: resource 2 mem: [0xe4100000-0xe41fffff]
pci_bus 0000:04: resource 3 mem: [0x0-0x0]
pci_bus 0000:0c: resource 0 io:  [0x8000-0x9fff]
pci_bus 0000:0c: resource 1 mem: [0xea000000-0xebffffff]
pci_bus 0000:0c: resource 2 mem: [0xe4200000-0xe42fffff]
pci_bus 0000:0c: resource 3 mem: [0x0-0x0]
pci_bus 0000:15: resource 0 io:  [0xa000-0xdfff]
pci_bus 0000:15: resource 1 mem: [0xe4300000-0xe7ffffff]
pci_bus 0000:15: resource 2 mem: [0xe0000000-0xe3ffffff]
pci_bus 0000:15: resource 3 io:  [0x00-0xffff]
pci_bus 0000:15: resource 4 mem: [0x000000-0xffffffff]
pci_bus 0000:16: resource 0 io:  [0xa000-0xa0ff]
pci_bus 0000:16: resource 1 io:  [0xa400-0xa4ff]
pci_bus 0000:16: resource 2 mem: [0xe0000000-0xe3ffffff]
pci_bus 0000:16: resource 3 mem: [0x88000000-0x8bffffff]
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 9, 2621440 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
NET: Registered protocol family 1
checking if image is initramfs... it is
Freeing initrd memory: 3125k freed
Simple Boot Flag at 0x35 set to 0x1
apm: BIOS not found.
Initializing RT-Tester: OK
audit: initializing netlink socket (disabled)
type=2000 audit(1233324895.108:1): initialized
highmem bounce pool size: 64 pages
HugeTLB registered 4 MB page size, pre-allocated 0 pages
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
msgmni has been set to 1657
SELinux:  Registering netfilter hooks
alg: No test for stdrng (krng)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci 0000:01:00.0: Boot video device
pcieport-driver 0000:00:01.0: setting latency timer to 64
pcieport-driver 0000:00:01.0: irq 24 for MSI/MSI-X
pcieport-driver 0000:00:1c.0: setting latency timer to 64
pcieport-driver 0000:00:1c.0: irq 25 for MSI/MSI-X
pcieport-driver 0000:00:1c.1: setting latency timer to 64
pcieport-driver 0000:00:1c.1: irq 26 for MSI/MSI-X
pcieport-driver 0000:00:1c.2: setting latency timer to 64
pcieport-driver 0000:00:1c.2: irq 27 for MSI/MSI-X
pcieport-driver 0000:00:1c.3: setting latency timer to 64
pcieport-driver 0000:00:1c.3: irq 28 for MSI/MSI-X
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
decode_hpp: Could not get hotplug parameters. Use defaults
acpiphp: Slot [1] registered
decode_hpp: Could not get hotplug parameters. Use defaults
acpiphp: Slot [1-1] registered
ACPI: AC Adapter [AC] (off-line)
ACPI: Battery Slot [BAT0] (battery present)
input: Power Button (FF) as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
ACPI: Power Button (FF) [PWRF]
input: Lid Switch as /devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input1
ACPI: Lid Switch [LID]
input: Sleep Button (CM) as /devices/LNXSYSTM:00/device:00/PNP0C0E:00/input/input2
ACPI: Sleep Button (CM) [SLPB]
ACPI: SSDT 7FEF1D36, 0282 (r1  PmRef  Cpu0Ist      100 INTL 20050513)
ACPI: SSDT 7FEF203D, 065A (r1  PmRef  Cpu0Cst      100 INTL 20050513)
ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
processor ACPI_CPU:00: registered as cooling_device0
ACPI: Processor [CPU0] (supports 8 throttling states)
ACPI: SSDT 7FEF1C6E, 00C8 (r1  PmRef  Cpu1Ist      100 INTL 20050513)
ACPI: SSDT 7FEF1FB8, 0085 (r1  PmRef  Cpu1Cst      100 INTL 20050513)
ACPI: CPU1 (power states: C1[C1] C2[C2] C3[C3])
processor ACPI_CPU:01: registered as cooling_device1
ACPI: Processor [CPU1] (supports 8 throttling states)
thermal LNXTHERM:01: registered as thermal_zone0
ACPI: Thermal Zone [THM0] (57 C)
thermal LNXTHERM:02: registered as thermal_zone1
ACPI: Thermal Zone [THM1] (56 C)
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Non-volatile memory driver v1.3
Linux agpgart interface v0.103
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
brd: module loaded
loop: module loaded
Intel(R) PRO/1000 Network Driver - version 7.3.20-k3-NAPI
Copyright (c) 1999-2006 Intel Corporation.
e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.3-k6
e1000e: Copyright (c) 1999-2008 Intel Corporation.
e1000e 0000:02:00.0: Disabling L1 ASPM
e1000e 0000:02:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
e1000e 0000:02:00.0: setting latency timer to 64
e1000e 0000:02:00.0: irq 29 for MSI/MSI-X
e1000e 0000:02:00.0: Warning: detected ASPM enabled in EEPROM
0000:02:00.0: eth0: (PCI Express:2.5GB/s:Width x1) 00:15:58:80:91:75
0000:02:00.0: eth0: Intel(R) PRO/1000 Network Connection
0000:02:00.0: eth0: MAC: 2, PHY: 2, PBA No: 005301-003
input: Macintosh mouse button emulation as /devices/virtual/input/input3
Driver 'sd' needs updating - please use bus_type methods
Driver 'sr' needs updating - please use bus_type methods
ahci 0000:00:1f.2: version 3.0
ahci 0000:00:1f.2: PCI INT B -> GSI 16 (level, low) -> IRQ 16
ahci 0000:00:1f.2: irq 30 for MSI/MSI-X
ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 4 ports 1.5 Gbps 0x1 impl SATA mode
ahci 0000:00:1f.2: flags: 64bit ncq pm led clo pio slum part 
ahci 0000:00:1f.2: setting latency timer to 64
scsi0 : ahci
scsi1 : ahci
scsi2 : ahci
scsi3 : ahci
ata1: SATA max UDMA/133 abar m1024@0xee404400 port 0xee404500 irq 30
ata2: DUMMY
ata3: DUMMY
ata4: DUMMY
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ACPI cmd ef/02:00:00:00:00:a0 succeeded
ata1.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out
ata1.00: ACPI cmd ef/5f:00:00:00:00:a0 succeeded
ata1.00: ACPI cmd ef/10:03:00:00:00:a0 filtered out
ata1.00: ATA-7: HTS721010G9SA00, MCZIC10V, max UDMA/100
ata1.00: 195371568 sectors, multi 16: LBA48 
ata1.00: ACPI cmd ef/02:00:00:00:00:a0 succeeded
ata1.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out
ata1.00: ACPI cmd ef/5f:00:00:00:00:a0 succeeded
ata1.00: ACPI cmd ef/10:03:00:00:00:a0 filtered out
ata1.00: configured for UDMA/100
ata1.00: configured for UDMA/100
ata1: EH complete
scsi 0:0:0:0: Direct-Access     ATA      HTS721010G9SA00  MCZI PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors: (100 GB/93.1 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors: (100 GB/93.1 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 >
sd 0:0:0:0: [sda] Attached SCSI disk
sd 0:0:0:0: Attached scsi generic sg0 type 0
ata_piix 0000:00:1f.1: version 2.12
ata_piix 0000:00:1f.1: PCI INT C -> GSI 16 (level, low) -> IRQ 16
ata_piix 0000:00:1f.1: setting latency timer to 64
scsi4 : ata_piix
scsi5 : ata_piix
ata5: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x1880 irq 14
ata6: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x1888 irq 15
ata5.00: ATAPI: HL-DT-ST DVDRAM GSA-4083N, 1.08, max UDMA/33
ata5.00: configured for UDMA/33
scsi 4:0:0:0: CD-ROM            HL-DT-ST DVDRAM GSA-4083N 1.08 PQ: 0 ANSI: 5
sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 4:0:0:0: Attached scsi CD-ROM sr0
sr 4:0:0:0: Attached scsi generic sg1 type 5
ata6: port disabled. ignoring.
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci_hcd 0000:00:1d.7: power state changed by ACPI to D0
ehci_hcd 0000:00:1d.7: PCI INT D -> GSI 19 (level, low) -> IRQ 19
ehci_hcd 0000:00:1d.7: setting latency timer to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:1d.7: debug port 1
ehci_hcd 0000:00:1d.7: cache line size of 32 is not supported
ehci_hcd 0000:00:1d.7: irq 19, io mem 0xee404000
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.29-rc3 ehci_hcd
usb usb1: SerialNumber: 0000:00:1d.7
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
uhci_hcd: USB Universal Host Controller Interface driver
uhci_hcd 0000:00:1d.0: power state changed by ACPI to D0
uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
uhci_hcd 0000:00:1d.0: setting latency timer to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.0: irq 16, io base 0x00001800
usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: UHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.29-rc3 uhci_hcd
usb usb2: SerialNumber: 0000:00:1d.0
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
uhci_hcd 0000:00:1d.1: setting latency timer to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.1: irq 17, io base 0x00001820
usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb3: Product: UHCI Host Controller
usb usb3: Manufacturer: Linux 2.6.29-rc3 uhci_hcd
usb usb3: SerialNumber: 0000:00:1d.1
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
uhci_hcd 0000:00:1d.2: power state changed by ACPI to D0
uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
uhci_hcd 0000:00:1d.2: setting latency timer to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.2: irq 18, io base 0x00001840
usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb4: Product: UHCI Host Controller
usb usb4: Manufacturer: Linux 2.6.29-rc3 uhci_hcd
usb usb4: SerialNumber: 0000:00:1d.2
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
uhci_hcd 0000:00:1d.3: PCI INT D -> GSI 19 (level, low) -> IRQ 19
uhci_hcd 0000:00:1d.3: setting latency timer to 64
uhci_hcd 0000:00:1d.3: UHCI Host Controller
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
uhci_hcd 0000:00:1d.3: irq 19, io base 0x00001860
usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb5: Product: UHCI Host Controller
usb usb5: Manufacturer: Linux 2.6.29-rc3 uhci_hcd
usb usb5: SerialNumber: 0000:00:1d.3
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
rtc_cmos 00:07: RTC can wake from S4
rtc_cmos 00:07: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@redhat.com
input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input4
cpuidle: using governor ladder
cpuidle: using governor menu
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
nf_conntrack.acct=1 kernel paramater, acct=1 nf_conntrack module option or
sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP cubic registered
NET: Registered protocol family 17
Using IPI No-Shortcut mode
registered taskstats version 1
  Magic number: 9:874:233
Freeing unused kernel memory: 1672k freed
Write protecting the kernel read-only data: 1392k
Synaptics Touchpad, model: 1, fw: 6.2, id: 0x81a0b1, caps: 0xa04793/0x300000
serio: Synaptics pass-through port at isa0060/serio1/input0
input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input5
psmouse serio2: ID: 10 00 64<6>kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
SELinux:  Disabled at runtime.
SELinux:  Unregistering netfilter hooks
type=1404 audit(1233324900.977:2): selinux=0 auid=4294967295 ses=4294967295
udevd version 127 started
IBM TrackPoint firmware: 0x0e, buttons: 3/3
input: TPPS/2 IBM TrackPoint as /devices/platform/i8042/serio1/serio2/input/input6
cfg80211: Using static regulatory domain info
cfg80211: Regulatory domain: US
	(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
	(2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
	(5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
	(5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
	(5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
	(5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
	(5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
cfg80211: Calling CRDA for country: US
iTCO_vendor_support: vendor-support=0
iTCO_wdt: Intel TCO WatchDog Timer Driver v1.04
iTCO_wdt: Found a ICH7-M or ICH7-U TCO device (Version=2, TCOBASE=0x1060)
iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
acpi device:08: registered as cooling_device2
input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/device:06/device:07/input/input7
ACPI: Video Device [VID1] (multi-head: yes  rom: no  post: no)
yenta_cardbus 0000:15:00.0: CardBus bridge found [17aa:2012]
yenta_cardbus 0000:15:00.0: Using INTVAL to route CSC interrupts to PCI
yenta_cardbus 0000:15:00.0: Routing CardBus interrupts to PCI
yenta_cardbus 0000:15:00.0: TI: mfunc 0x01d01002, devctl 0x64
input: PC Speaker as /devices/platform/pcspkr/input/input8
yenta_cardbus 0000:15:00.0: ISA IRQ mask 0x0cf8, PCI irq 16
yenta_cardbus 0000:15:00.0: Socket status: 30000007
yenta_cardbus 0000:15:00.0: pcmcia: parent PCI bridge I/O window: 0xa000 - 0xdfff
pcmcia_socket pcmcia_socket0: cs: IO port probe 0xa000-0xdfff: clean.
yenta_cardbus 0000:15:00.0: pcmcia: parent PCI bridge Memory window: 0xe4300000 - 0xe7ffffff
yenta_cardbus 0000:15:00.0: pcmcia: parent PCI bridge Memory window: 0xe0000000 - 0xe3ffffff
i801_smbus 0000:00:1f.3: PCI INT A -> GSI 23 (level, low) -> IRQ 23
ath5k 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
ath5k 0000:03:00.0: setting latency timer to 64
ath5k 0000:03:00.0: registered as 'phy0'
wmaster0 (ath5k): not using net_device_ops yet
phy0: Selected rate control algorithm 'minstrel'
NET: Registered protocol family 23
pcmcia_socket pcmcia_socket0: cs: IO port probe 0x100-0x3af: clean.
pcmcia_socket pcmcia_socket0: cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7
pcmcia_socket pcmcia_socket0: cs: IO port probe 0x820-0x8ff: clean.
pcmcia_socket pcmcia_socket0: cs: IO port probe 0xc00-0xcf7: clean.
pcmcia_socket pcmcia_socket0: cs: IO port probe 0xa00-0xaff: clean.
wlan0 (ath5k): not using net_device_ops yet
Registered led device: ath5k-phy0::rx
Registered led device: ath5k-phy0::tx
ath5k phy0: Atheros AR5414 chip found (MAC: 0xa3, PHY: 0x61)
thinkpad_acpi: ThinkPad ACPI Extras v0.22
thinkpad_acpi: http://ibm-acpi.sf.net/
thinkpad_acpi: ThinkPad BIOS 79ETC9WW (2.09 ), EC 79HT50WW-1.07
thinkpad_acpi: Lenovo ThinkPad T60p, model 2007CS3
thinkpad_acpi: radio switch found; radios are enabled
thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the ACPI video driver
thinkpad_acpi: Disabling thinkpad-acpi brightness events by default...
Registered led device: tpacpi::thinklight
Registered led device: tpacpi::power
Registered led device: tpacpi:orange:batt
Registered led device: tpacpi:green:batt
Registered led device: tpacpi::dock_active
Registered led device: tpacpi::bay_active
Registered led device: tpacpi::dock_batt
Registered led device: tpacpi::unknown_led
Registered led device: tpacpi::standby
thinkpad_acpi: Standard ACPI backlight interface available, not loading native one.
input: ThinkPad Extra Buttons as /devices/virtual/input/input9
nsc-ircc 00:0a: activated
nsc-ircc, chip->init
nsc-ircc, Found chip at base=0x164e
nsc-ircc, driver loaded (Dag Brattli)
irda0 (): not using net_device_ops yet
IrDA: Registered device irda0
nsc-ircc, Using dongle: IBM31T1100 or Temic TFDS6000/TFDS6500
HDA Intel 0000:00:1b.0: PCI INT B -> GSI 17 (level, low) -> IRQ 17
hda_intel: probe_mask set to 0x1 for device 17aa:2010
HDA Intel 0000:00:1b.0: setting latency timer to 64
device-mapper: multipath: version 1.0.5 loaded
EXT3 FS on sda5, internal journal
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda6, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
swap_cgroup: uses 2432 bytes of vmalloc for pointer array space and 2490368 bytes to hold mem_cgroup pointers on swap
swap_cgroup can be disabled by noswapaccount boot option.
Adding 2490032k swap on /dev/sda7.  Priority:-1 extents:1 across:2490032k 
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
ip6_tables: (C) 2000-2006 Netfilter Core Team
Bluetooth: Core ver 2.14
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP ver 2.11
Bluetooth: L2CAP socket layer initialized
Bluetooth: SCO (Voice Link) ver 0.6
Bluetooth: SCO socket layer initialized
Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Bluetooth: BNEP filters: protocol multicast
Bridge firewalling registered
e1000e 0000:02:00.0: irq 29 for MSI/MSI-X
e1000e 0000:02:00.0: irq 29 for MSI/MSI-X
ADDRCONF(NETDEV_UP): eth0: link is not ready
ADDRCONF(NETDEV_UP): wlan0: link is not ready
virbr0: starting userspace STP failed, starting kernel STP
pci 0000:01:00.0: power state changed by ACPI to D0
pci 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[drm] Initialized drm 1.1.0 20060810
pci 0000:01:00.0: setting latency timer to 64
[drm] Initialized radeon 1.29.0 20080528 on minor 0
wlan0: authenticate with AP 00:1d:af:ee:30:85
------------[ cut here ]------------
WARNING: at net/mac80211/rx.c:2236 __ieee80211_rx+0x96/0x571 [mac80211]()
Hardware name: 2007CS3
RATE=255, BAND=8
Modules linked in: radeon drm ipt_MASQUERADE iptable_nat nf_nat bridge stp bnep sco l2cap bluetooth ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand acpi_cpufreq dm_multipath kvm_intel kvm uinput snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss nsc_ircc thinkpad_acpi arc4 snd_mixer_oss snd_pcm irda ecb ath5k rfkill mac80211 i2c_i801 hwmon pcspkr snd_timer joydev yenta_socket i2c_core video iTCO_wdt snd rsrc_nonstatic iTCO_vendor_support output cfg80211 soundcore crc_ccitt snd_page_alloc [last unloaded: scsi_wait_scan]
Pid: 2634, comm: X Not tainted 2.6.29-rc3 #18
Call Trace:
 [<c0430636>] warn_slowpath+0x76/0xad
 [<c04508d7>] ? __lock_acquire+0xb36/0xb45
 [<f7dd0205>] __ieee80211_rx+0x96/0x571 [mac80211]
 [<f7e37976>] ath5k_tasklet_rx+0x4fb/0x53d [ath5k]
 [<c06fa5c3>] ? _spin_unlock_irq+0x27/0x34
 [<c0434f91>] tasklet_action+0x85/0xf0
 [<c043567c>] __do_softirq+0x9d/0x155
 [<c04355df>] ? __do_softirq+0x0/0x155
 <IRQ>  [<c0470740>] ? handle_fasteoi_irq+0x0/0xb6
 [<c0435316>] ? irq_exit+0x49/0x7c
 [<c0405523>] ? do_IRQ+0xf5/0x10b
 [<c040422c>] ? common_interrupt+0x2c/0x34
---[ end trace edd3e5e4c9204228 ]---
wlan0: authenticate with AP 00:1d:af:ee:30:85
------------[ cut here ]------------
WARNING: at net/mac80211/rx.c:2236 __ieee80211_rx+0x96/0x571 [mac80211]()
Hardware name: 2007CS3
RATE=255, BAND=8
Modules linked in: radeon drm ipt_MASQUERADE iptable_nat nf_nat bridge stp bnep sco l2cap bluetooth ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand acpi_cpufreq dm_multipath kvm_intel kvm uinput snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss nsc_ircc thinkpad_acpi arc4 snd_mixer_oss snd_pcm irda ecb ath5k rfkill mac80211 i2c_i801 hwmon pcspkr snd_timer joydev yenta_socket i2c_core video iTCO_wdt snd rsrc_nonstatic iTCO_vendor_support output cfg80211 soundcore crc_ccitt snd_page_alloc [last unloaded: scsi_wait_scan]
Pid: 2634, comm: X Tainted: G        W  2.6.29-rc3 #18
Call Trace:
 [<c0430636>] warn_slowpath+0x76/0xad
 [<c0450900>] ? lock_acquire+0x1a/0x97
 [<c044f63b>] ? trace_hardirqs_on_caller+0x18/0x154
 [<f7dd0205>] __ieee80211_rx+0x96/0x571 [mac80211]
 [<f7e37976>] ath5k_tasklet_rx+0x4fb/0x53d [ath5k]
 [<c0434f91>] tasklet_action+0x85/0xf0
 [<c043567c>] __do_softirq+0x9d/0x155
 [<c04355df>] ? __do_softirq+0x0/0x155
 <IRQ>  [<c0470740>] ? handle_fasteoi_irq+0x0/0xb6
 [<c0435316>] ? irq_exit+0x49/0x7c
 [<c0405523>] ? do_IRQ+0xf5/0x10b
 [<c040422c>] ? common_interrupt+0x2c/0x34
---[ end trace edd3e5e4c9204229 ]---
wlan0: authenticate with AP 00:1d:af:ee:30:85
------------[ cut here ]------------
WARNING: at net/mac80211/rx.c:2236 __ieee80211_rx+0x96/0x571 [mac80211]()
Hardware name: 2007CS3
RATE=255, BAND=8
Modules linked in: radeon drm ipt_MASQUERADE iptable_nat nf_nat bridge stp bnep sco l2cap bluetooth ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand acpi_cpufreq dm_multipath kvm_intel kvm uinput snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss nsc_ircc thinkpad_acpi arc4 snd_mixer_oss snd_pcm irda ecb ath5k rfkill mac80211 i2c_i801 hwmon pcspkr snd_timer joydev yenta_socket i2c_core video iTCO_wdt snd rsrc_nonstatic iTCO_vendor_support output cfg80211 soundcore crc_ccitt snd_page_alloc [last unloaded: scsi_wait_scan]
Pid: 0, comm: swapper Tainted: G        W  2.6.29-rc3 #18
Call Trace:
 [<c0430636>] warn_slowpath+0x76/0xad
 [<c044f63b>] ? trace_hardirqs_on_caller+0x18/0x154
 [<f7dd0205>] __ieee80211_rx+0x96/0x571 [mac80211]
 [<f7e37976>] ath5k_tasklet_rx+0x4fb/0x53d [ath5k]
 [<c0434f91>] tasklet_action+0x85/0xf0
 [<c043567c>] __do_softirq+0x9d/0x155
 [<c04355df>] ? __do_softirq+0x0/0x155
 <IRQ>  [<c0470740>] ? handle_fasteoi_irq+0x0/0xb6
 [<c0435316>] ? irq_exit+0x49/0x7c
 [<c0405523>] ? do_IRQ+0xf5/0x10b
 [<c040422c>] ? common_interrupt+0x2c/0x34
 [<c044f782>] ? trace_hardirqs_on+0xb/0xd
 [<c058ef9f>] ? acpi_idle_enter_bm+0x267/0x2b8
 [<c044f782>] ? trace_hardirqs_on+0xb/0xd
 [<c044007b>] ? change_pid+0xa3/0xa4
 [<c058efa1>] ? acpi_idle_enter_bm+0x269/0x2b8
 [<c0667865>] ? cpuidle_idle_call+0x65/0x98
 [<c0402c87>] ? cpu_idle+0x84/0xa5
 [<c06f5664>] ? start_secondary+0x1c9/0x1d1
---[ end trace edd3e5e4c920422a ]---
Clocksource tsc unstable (delta = -149671973 ns)
[drm] Setting GART location based on new memory map
[drm] Loading R500 Microcode
[drm] Num pipes: 1
[drm] writeback test succeeded in 5 usecs
wlan0: authentication with AP 00:1d:af:ee:30:85 timed out
fuse init (API version 7.11)
virbr0: no IPv6 routers present

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/1] ath5k: fix hw rate index condition
  2009-01-07 15:22     ` Dhaval Giani
@ 2009-01-07 15:30       ` Jiri Slaby
  2009-02-02  7:57         ` Dhaval Giani
  0 siblings, 1 reply; 32+ messages in thread
From: Jiri Slaby @ 2009-01-07 15:30 UTC (permalink / raw)
  To: Dhaval Giani
  Cc: linville, davem, linux-wireless, ath5k-devel, Nick Kossifidis,
	Luis R. Rodriguez, Bob Copeland, linux-kernel

On 01/07/2009 04:22 PM, Dhaval Giani wrote:
> I will get back to you in about a day or two.

No problem. Thanks.

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/1] ath5k: fix hw rate index condition
  2009-01-07 14:36   ` Jiri Slaby
@ 2009-01-07 15:22     ` Dhaval Giani
  2009-01-07 15:30       ` Jiri Slaby
  2009-03-15 21:27     ` Stefan Lippers-Hollmann
  1 sibling, 1 reply; 32+ messages in thread
From: Dhaval Giani @ 2009-01-07 15:22 UTC (permalink / raw)
  To: Jiri Slaby
  Cc: linville, davem, linux-wireless, ath5k-devel, Nick Kossifidis,
	Luis R. Rodriguez, Bob Copeland, linux-kernel

On Wed, Jan 07, 2009 at 03:36:05PM +0100, Jiri Slaby wrote:
> On 01/07/2009 02:51 PM, Jiri Slaby wrote:
> > Dhaval Giani wrote:
> >> I see this on current git. Not sure how to reproduce it, has happened on
> >> two random occasions. At both times, I was not connected to a wireless
> >> network, but to wired networks.
> >>
> >> ------------[ cut here ]------------
> >> WARNING: at net/mac80211/rx.c:2234 __ieee80211_rx+0x7f/0x559
> >> ...
> >> Call Trace:
> >>  [<f80d4192>] __ieee80211_rx+0x7f/0x559 [mac80211]
> >>  [<f80a19f4>] ath5k_tasklet_rx+0x4f7/0x53b [ath5k]
> >> ...
> > 
> > Hmm, maybe ath5k is culprit. Could you apply the attached patch and
> > use the kernel till the problem appears again?
> 
> I don't think this will print anything, the rate won't be 32, it's rather
> too high. Could you apply also the appended debug one?
> 

I will apply both the patches and try it out again. As I mentioned
earlier, I am not sure how to reproduce the WARN_ON. I will get back to
you in about a day or two.

> ---
>  net/mac80211/rx.c |    6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> index 7175ae8..5e17e57 100644
> --- a/net/mac80211/rx.c
> +++ b/net/mac80211/rx.c
> @@ -2230,8 +2230,10 @@ void __ieee80211_rx(struct ieee80211_hw *hw, struct sk_buff *skb,
>  		 * MCS aware. */
>  		rate = &sband->bitrates[sband->n_bitrates - 1];
>  	} else {
> -		if (WARN_ON(status->rate_idx < 0 ||
> -			    status->rate_idx >= sband->n_bitrates))
> +		if (WARN(status->rate_idx < 0 ||
> +			    status->rate_idx >= sband->n_bitrates,
> +			    "RATE=%u, BAND=%x\n", status->rate_idx,
> +			    sband->n_bitrates))
>  			return;
>  		rate = &sband->bitrates[status->rate_idx];
>  	}
> -- 
> 1.6.0.6

-- 
regards,
Dhaval

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/1] ath5k: fix hw rate index condition
  2009-01-07 13:51 ` [PATCH 1/1] ath5k: fix hw rate index condition Jiri Slaby
@ 2009-01-07 14:36   ` Jiri Slaby
  2009-01-07 15:22     ` Dhaval Giani
  2009-03-15 21:27     ` Stefan Lippers-Hollmann
  0 siblings, 2 replies; 32+ messages in thread
From: Jiri Slaby @ 2009-01-07 14:36 UTC (permalink / raw)
  To: Dhaval Giani
  Cc: linville, davem, linux-wireless, ath5k-devel, Nick Kossifidis,
	Luis R. Rodriguez, Bob Copeland, linux-kernel, Jiri Slaby

On 01/07/2009 02:51 PM, Jiri Slaby wrote:
> Dhaval Giani wrote:
>> I see this on current git. Not sure how to reproduce it, has happened on
>> two random occasions. At both times, I was not connected to a wireless
>> network, but to wired networks.
>>
>> ------------[ cut here ]------------
>> WARNING: at net/mac80211/rx.c:2234 __ieee80211_rx+0x7f/0x559
>> ...
>> Call Trace:
>>  [<f80d4192>] __ieee80211_rx+0x7f/0x559 [mac80211]
>>  [<f80a19f4>] ath5k_tasklet_rx+0x4f7/0x53b [ath5k]
>> ...
> 
> Hmm, maybe ath5k is culprit. Could you apply the attached patch and
> use the kernel till the problem appears again?

I don't think this will print anything, the rate won't be 32, it's rather
too high. Could you apply also the appended debug one?

---
 net/mac80211/rx.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 7175ae8..5e17e57 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2230,8 +2230,10 @@ void __ieee80211_rx(struct ieee80211_hw *hw, struct sk_buff *skb,
 		 * MCS aware. */
 		rate = &sband->bitrates[sband->n_bitrates - 1];
 	} else {
-		if (WARN_ON(status->rate_idx < 0 ||
-			    status->rate_idx >= sband->n_bitrates))
+		if (WARN(status->rate_idx < 0 ||
+			    status->rate_idx >= sband->n_bitrates,
+			    "RATE=%u, BAND=%x\n", status->rate_idx,
+			    sband->n_bitrates))
 			return;
 		rate = &sband->bitrates[status->rate_idx];
 	}
-- 
1.6.0.6


^ permalink raw reply related	[flat|nested] 32+ messages in thread

* [PATCH 1/1] ath5k: fix hw rate index condition
  2009-01-06 17:07 WARNING: at net/mac80211/rx.c:2234 __ieee80211_rx+0x7f/0x559 [mac80211]() Dhaval Giani
@ 2009-01-07 13:51 ` Jiri Slaby
  2009-01-07 14:36   ` Jiri Slaby
  0 siblings, 1 reply; 32+ messages in thread
From: Jiri Slaby @ 2009-01-07 13:51 UTC (permalink / raw)
  To: Dhaval Giani
  Cc: linville, davem, linux-wireless, ath5k-devel, linux-kernel,
	Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez, Bob Copeland

Dhaval Giani wrote:
> I see this on current git. Not sure how to reproduce it, has happened on
> two random occasions. At both times, I was not connected to a wireless
> network, but to wired networks.
> 
> ------------[ cut here ]------------
> WARNING: at net/mac80211/rx.c:2234 __ieee80211_rx+0x7f/0x559
> ...
> Call Trace:
>  [<f80d4192>] __ieee80211_rx+0x7f/0x559 [mac80211]
>  [<f80a19f4>] ath5k_tasklet_rx+0x4f7/0x53b [ath5k]
> ...

Hmm, maybe ath5k is culprit. Could you apply the attached patch and
use the kernel till the problem appears again?

--

Make sure we print out a warning when the index is out of bounds,
i.e. even on hw_rix == AR5K_MAX_RATES.

Also change to WARN and print text with the reported hw_rix.

Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Nick Kossifidis <mickflemm@gmail.com>
Cc: Luis R. Rodriguez <lrodriguez@atheros.com>
Cc: Bob Copeland <me@bobcopeland.com>
---
 drivers/net/wireless/ath5k/base.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/net/wireless/ath5k/base.c b/drivers/net/wireless/ath5k/base.c
index 4af2607..0e65e25 100644
--- a/drivers/net/wireless/ath5k/base.c
+++ b/drivers/net/wireless/ath5k/base.c
@@ -1088,7 +1088,8 @@ ath5k_mode_setup(struct ath5k_softc *sc)
 static inline int
 ath5k_hw_to_driver_rix(struct ath5k_softc *sc, int hw_rix)
 {
-	WARN_ON(hw_rix < 0 || hw_rix > AR5K_MAX_RATES);
+	WARN(hw_rix < 0 || hw_rix >= AR5K_MAX_RATES,
+			"hw_rix out of bounds: %x\n", hw_rix);
 	return sc->rate_idx[sc->curband->band][hw_rix];
 }
 
-- 
1.6.0.6


^ permalink raw reply related	[flat|nested] 32+ messages in thread

end of thread, other threads:[~2009-03-31 12:24 UTC | newest]

Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-02-26 22:44 [PATCH 1/1] ath5k: fix hw rate index condition Jiri Slaby
2009-02-26 23:15 ` Bob Copeland
2009-02-26 23:19   ` Jiri Slaby
2009-02-26 23:28     ` [ath5k-devel] " Bob Copeland
2009-02-26 23:32       ` Jiri Slaby
2009-02-27  2:27         ` Bob Copeland
2009-02-27  2:39           ` Luis R. Rodriguez
2009-02-27  3:06             ` Bob Copeland
2009-02-27  3:15               ` Luis R. Rodriguez
2009-03-01  5:21               ` Pavel Roskin
2009-03-03  3:46                 ` Bob Copeland
2009-03-03  4:31                   ` Nick Kossifidis
2009-03-03 13:02                     ` Bob Copeland
2009-03-01  5:07           ` Pavel Roskin
2009-03-01 14:36             ` Bob Copeland
  -- strict thread matches above, loose matches on Subject: below --
2009-01-06 17:07 WARNING: at net/mac80211/rx.c:2234 __ieee80211_rx+0x7f/0x559 [mac80211]() Dhaval Giani
2009-01-07 13:51 ` [PATCH 1/1] ath5k: fix hw rate index condition Jiri Slaby
2009-01-07 14:36   ` Jiri Slaby
2009-01-07 15:22     ` Dhaval Giani
2009-01-07 15:30       ` Jiri Slaby
2009-02-02  7:57         ` Dhaval Giani
2009-02-15 13:47           ` Bob Copeland
2009-02-28 23:08             ` Jiri Slaby
2009-03-30  8:59               ` Dhaval Giani
2009-03-30 16:58                 ` Bob Copeland
2009-03-30 17:59                   ` Dhaval Giani
2009-03-30 18:13                     ` Bob Copeland
2009-03-31  3:51                       ` Dhaval Giani
2009-03-31 12:23                         ` Bob Copeland
2009-03-15 21:27     ` Stefan Lippers-Hollmann
2009-03-15 21:35       ` Michael Buesch
2009-03-23  0:45       ` Stefan Lippers-Hollmann
2009-03-23  2:31         ` Bob Copeland

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).