[PATCH] ath5k: fix detection of jumbo frames

[PATCH] ath5k: fix detection of jumbo frames

[Bob Copeland]

Set ath5k_rs_status.rs_more using mask + shift.  rs_more is a
u8, but we were setting it with a bitwise AND of a 16 bit value.
As a consequence, jumbo frames would not be discarded as intended.
Then, because the hw rate value of such frames is zero, and, since
63266a653589e1a237527479f10212ea77ce7844 "ath5k: rates cleanup",
we do not fall back to the basic rate, such packets would trigger
the following WARN_ON:

------------[ cut here ]------------
WARNING: at net/mac80211/rx.c:2192 __ieee80211_rx+0x4d/0x57e [mac80211]()
Modules linked in: ath5k af_packet sha256_generic aes_i586 aes_generic cbc loop i915 drm binfmt_misc acpi_cpufreq fan container nls_utf8 hfsplus dm_crypt dm_mod kvm_intel kvm fuse sbp2 snd_hda_intel snd_pcm_oss snd_pcm snd_mixer_oss snd_seq_dummy snd_seq_oss arc4 joydev hid_apple ecb snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device usbhid appletouch mac80211 sky2 snd ehci_hcd ohci1394 bitrev crc32 sr_mod cdrom rtc sg uhci_hcd snd_page_alloc cfg80211 ieee1394 thermal ac battery processor button evdev unix [last unloaded: ath5k]
Pid: 0, comm: swapper Tainted: G        W  2.6.28-rc2-wl #14
Call Trace:
 [<c0123d1e>] warn_on_slowpath+0x41/0x5b
 [<c012005d>] ? sched_debug_show+0x31e/0x9c6
 [<c012489f>] ? vprintk+0x369/0x389
 [<c0309539>] ? _spin_unlock_irqrestore+0x54/0x58
 [<c011cd8f>] ? try_to_wake_up+0x14f/0x15a
 [<f81918cb>] __ieee80211_rx+0x4d/0x57e [mac80211]
 [<f828872a>] ath5k_tasklet_rx+0x5a1/0x5e4 [ath5k]
 [<c013b9cd>] ? clockevents_program_event+0xd4/0xe3
 [<c01283a9>] tasklet_action+0x94/0xfd
 [<c0127d19>] __do_softirq+0x8c/0x13e
 [<c0127e04>] do_softirq+0x39/0x55
 [<c0128082>] irq_exit+0x46/0x85
 [<c010576c>] do_IRQ+0x9a/0xb2
 [<c010461c>] common_interrupt+0x28/0x30
 [<f80e934a>] ? acpi_idle_enter_bm+0x2ad/0x31b [processor]
 [<c02976bf>] cpuidle_idle_call+0x65/0x9a
 [<c010262c>] cpu_idle+0x76/0xa6
 [<c02fb402>] rest_init+0x62/0x64

Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
Hi,

This patch should fix the warn_on_slowpath warnings reported by several
people and kernel bugzilla http://bugzilla.kernel.org/show_bug.cgi?id=11901.

 drivers/net/wireless/ath5k/desc.c |   16 ++++++++--------
 drivers/net/wireless/ath5k/desc.h |    3 +++
 2 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/ath5k/desc.c b/drivers/net/wireless/ath5k/desc.c
index dd13740..0f982fb 100644
--- a/drivers/net/wireless/ath5k/desc.c
+++ b/drivers/net/wireless/ath5k/desc.c
@@ -531,10 +531,10 @@ static int ath5k_hw_proc_5210_rx_status(struct ath5k_hw *ah,
 		AR5K_5210_RX_DESC_STATUS0_RECEIVE_SIGNAL);
 	rs->rs_rate = AR5K_REG_MS(rx_status->rx_status_0,
 		AR5K_5210_RX_DESC_STATUS0_RECEIVE_RATE);
-	rs->rs_antenna = rx_status->rx_status_0 &
-		AR5K_5210_RX_DESC_STATUS0_RECEIVE_ANTENNA;
-	rs->rs_more = rx_status->rx_status_0 &
-		AR5K_5210_RX_DESC_STATUS0_MORE;
+	rs->rs_antenna = AR5K_REG_MS(rx_status->rx_status_0,
+		AR5K_5210_RX_DESC_STATUS0_RECEIVE_ANTENNA);
+	rs->rs_more = AR5K_REG_MS(rx_status->rx_status_0,
+		AR5K_5210_RX_DESC_STATUS0_MORE);
 	/* TODO: this timestamp is 13 bit, later on we assume 15 bit */
 	rs->rs_tstamp = AR5K_REG_MS(rx_status->rx_status_1,
 		AR5K_5210_RX_DESC_STATUS1_RECEIVE_TIMESTAMP);
@@ -607,10 +607,10 @@ static int ath5k_hw_proc_5212_rx_status(struct ath5k_hw *ah,
 		AR5K_5212_RX_DESC_STATUS0_RECEIVE_SIGNAL);
 	rs->rs_rate = AR5K_REG_MS(rx_status->rx_status_0,
 		AR5K_5212_RX_DESC_STATUS0_RECEIVE_RATE);
-	rs->rs_antenna = rx_status->rx_status_0 &
-		AR5K_5212_RX_DESC_STATUS0_RECEIVE_ANTENNA;
-	rs->rs_more = rx_status->rx_status_0 &
-		AR5K_5212_RX_DESC_STATUS0_MORE;
+	rs->rs_antenna = AR5K_REG_MS(rx_status->rx_status_0,
+		AR5K_5212_RX_DESC_STATUS0_RECEIVE_ANTENNA);
+	rs->rs_more = AR5K_REG_MS(rx_status->rx_status_0,
+		AR5K_5212_RX_DESC_STATUS0_MORE);
 	rs->rs_tstamp = AR5K_REG_MS(rx_status->rx_status_1,
 		AR5K_5212_RX_DESC_STATUS1_RECEIVE_TIMESTAMP);
 	rs->rs_status = 0;
diff --git a/drivers/net/wireless/ath5k/desc.h b/drivers/net/wireless/ath5k/desc.h
index 56158c8..80630d9 100644
--- a/drivers/net/wireless/ath5k/desc.h
+++ b/drivers/net/wireless/ath5k/desc.h
@@ -49,6 +49,7 @@ struct ath5k_hw_rx_status {
 /* RX status word 0 fields/flags */
 #define AR5K_5210_RX_DESC_STATUS0_DATA_LEN		0x00000fff
 #define AR5K_5210_RX_DESC_STATUS0_MORE			0x00001000
+#define AR5K_5210_RX_DESC_STATUS0_MORE_S		12
 #define AR5K_5210_RX_DESC_STATUS0_RECEIVE_RATE		0x00078000
 #define AR5K_5210_RX_DESC_STATUS0_RECEIVE_RATE_S	15
 #define AR5K_5210_RX_DESC_STATUS0_RECEIVE_SIGNAL	0x07f80000
@@ -75,7 +76,9 @@ struct ath5k_hw_rx_status {
 /* RX status word 0 fields/flags */
 #define AR5K_5212_RX_DESC_STATUS0_DATA_LEN		0x00000fff
 #define AR5K_5212_RX_DESC_STATUS0_MORE			0x00001000
+#define AR5K_5212_RX_DESC_STATUS0_MORE_S		12
 #define AR5K_5212_RX_DESC_STATUS0_DECOMP_CRC_ERROR	0x00002000
+#define AR5K_5212_RX_DESC_STATUS0_DECOMP_CRC_ERROR_S	13
 #define AR5K_5212_RX_DESC_STATUS0_RECEIVE_RATE		0x000f8000
 #define AR5K_5212_RX_DESC_STATUS0_RECEIVE_RATE_S	15
 #define AR5K_5212_RX_DESC_STATUS0_RECEIVE_SIGNAL	0x0ff00000
-- 
1.5.4.2.182.gb3092

Re: [ath5k-devel] [PATCH] ath5k: fix detection of jumbo frames

[Luis R. Rodriguez]

On Sun, Nov 2, 2008 at 11:08 AM, Bob Copeland <me@bobcopeland.com> wrote:

Nice find.

> Then, because the hw rate value of such frames is zero

BTW I believe frames should not go out at hw rate value 0, I did some
test a while back on this rate and its not exactly reliable, you will
get very funky behavior on it. Are you seeing that rate being used on
legacy-hal? Last I asked about it too its not something people know
about as being desired effect. I could be wrong but it'd be
interesting to see where this is used correctly.

>, and, since
> 63266a653589e1a237527479f10212ea77ce7844 "ath5k: rates cleanup", we do not fall back to the basic rate, such packets would trigger
> the following WARN_ON:

So its slow because using rate 0 takes a while? If indeed you don't
see a valid use for this rate I'd say to completely disallow it and
use BUG_ON() on it.

  Luis

Re: [ath5k-devel] [PATCH] ath5k: fix detection of jumbo frames

[Bob Copeland]

On Sun, Nov 02, 2008 at 01:00:27PM -0800, Luis R. Rodriguez wrote:
> >, and, since
> > 63266a653589e1a237527479f10212ea77ce7844 "ath5k: rates cleanup", we do not fall back to the basic rate, such packets would trigger
> > the following WARN_ON:
> 
> So its slow because using rate 0 takes a while? If indeed you don't
> see a valid use for this rate I'd say to completely disallow it and
> use BUG_ON() on it.

Not sure I follow - these are incoming frames, which all had a status_0
of 0x1a40 (rs_more=0x1000 & length=0xa40).  So hw rate index was zero
on these for some reason, but in my testing the rate index of all other 
packets was something reasonable, e.g. 0x27.  

I looked over the rate tables compared to hal-legacy; I think what we
have now is correct, just the old ath5k code in hw_to_driver_rix would 
set rate=1 for any hw rate index that we didn't know about:

-       /* Something went wrong, fallback to basic rate for this band */
-       if ((mac80211_rix >= sc->curband->n_bitrates) ||
-               (mac80211_rix <= 0 ))
-               mac80211_rix = 1;

That's gone now, and that's why we didn't have the WARN_ON previously.

For TX-side, I think we don't use rate 0 already since Bruno's cleanup,
we should just use the hw_value fields in ath5k_rates which are all 
nonzero.

-- 
Bob Copeland %% www.bobcopeland.com

Re: [ath5k-devel] [PATCH] ath5k: fix detection of jumbo frames

[Luis R. Rodriguez]

On Sun, Nov 2, 2008 at 1:52 PM, Bob Copeland <me@bobcopeland.com> wrote:
> On Sun, Nov 02, 2008 at 01:00:27PM -0800, Luis R. Rodriguez wrote:
>> >, and, since
>> > 63266a653589e1a237527479f10212ea77ce7844 "ath5k: rates cleanup", we do not fall back to the basic rate, such packets would trigger
>> > the following WARN_ON:
>>
>> So its slow because using rate 0 takes a while? If indeed you don't
>> see a valid use for this rate I'd say to completely disallow it and
>> use BUG_ON() on it.
>
> Not sure I follow - these are incoming frames, which all had a status_0
> of 0x1a40 (rs_more=0x1000 & length=0xa40).  So hw rate index was zero
> on these for some reason, but in my testing the rate index of all other
> packets was something reasonable, e.g. 0x27.

Interesting -- I will have to check on what this means.

> I looked over the rate tables compared to hal-legacy; I think what we
> have now is correct, just the old ath5k code in hw_to_driver_rix would
> set rate=1 for any hw rate index that we didn't know about:
>
> -       /* Something went wrong, fallback to basic rate for this band */
> -       if ((mac80211_rix >= sc->curband->n_bitrates) ||
> -               (mac80211_rix <= 0 ))
> -               mac80211_rix = 1;
>
> That's gone now, and that's why we didn't have the WARN_ON previously.
>
> For TX-side, I think we don't use rate 0 already since Bruno's cleanup,
> we should just use the hw_value fields in ath5k_rates which are all
> nonzero.

Oh ok thanks.

  Luis

Re: [ath5k-devel] [PATCH] ath5k: fix detection of jumbo frames

[Bob Copeland]

On Sun, Nov 02, 2008 at 02:33:44PM -0800, Luis R. Rodriguez wrote:
> > Not sure I follow - these are incoming frames, which all had a status_0
> > of 0x1a40 (rs_more=0x1000 & length=0xa40).  So hw rate index was zero
> > on these for some reason, but in my testing the rate index of all other
> > packets was something reasonable, e.g. 0x27.
> 
> Interesting -- I will have to check on what this means.

Yup, it would be good to handle these properly.

-- 
Bob Copeland %% www.bobcopeland.com

Re: [ath5k-devel] [PATCH] ath5k: fix detection of jumbo frames

[Kalle Valo]

(Trimmed CC list)

Luis R. Rodriguez <lrodriguez@atheros.com> writes:

>>, and, since
>> 63266a653589e1a237527479f10212ea77ce7844 "ath5k: rates cleanup", we do not fall back to the basic rate, such packets would trigger
>> the following WARN_ON:
>
> So its slow because using rate 0 takes a while? If indeed you don't
> see a valid use for this rate I'd say to completely disallow it and
> use BUG_ON() on it.

Please, avoid BUG_ON() at all costs, only use it if the situation
might mean major data corruption or something similar. For users
BUG_ON() is a major grief because there are no visible indication what
has happened.

IMHO wireless drivers should not have BUG_ON() calls at all, WARN_ON()
is enough and much more usable for everyone.

-- 
Kalle Valo

Re: [PATCH] ath5k: fix detection of jumbo frames

[Pavel Roskin]

On Sun, 2008-11-02 at 14:08 -0500, Bob Copeland wrote:
> Set ath5k_rs_status.rs_more using mask + shift.  rs_more is a
> u8, but we were setting it with a bitwise AND of a 16 bit value.
> As a consequence, jumbo frames would not be discarded as intended.
> Then, because the hw rate value of such frames is zero, and, since
> 63266a653589e1a237527479f10212ea77ce7844 "ath5k: rates cleanup",
> we do not fall back to the basic rate, such packets would trigger
> the following WARN_ON:

Thanks for catching it!  Please mention rs_antenna in addition to
rs_more.

> -	rs->rs_antenna = rx_status->rx_status_0 &
> -		AR5K_5210_RX_DESC_STATUS0_RECEIVE_ANTENNA;
> -	rs->rs_more = rx_status->rx_status_0 &
> -		AR5K_5210_RX_DESC_STATUS0_MORE;
> +	rs->rs_antenna = AR5K_REG_MS(rx_status->rx_status_0,
> +		AR5K_5210_RX_DESC_STATUS0_RECEIVE_ANTENNA);
> +	rs->rs_more = AR5K_REG_MS(rx_status->rx_status_0,
> +		AR5K_5210_RX_DESC_STATUS0_MORE);

rs_more should be boolean.  It would be better to use "!!" to calculate
rs_rate.  No need to shift anything.  As for rs_antenna, it's fine with
me.

> +#define AR5K_5212_RX_DESC_STATUS0_DECOMP_CRC_ERROR_S	13

This doesn't belong to the patch.  It looks like it's another boolean
value, but it's not currently used.

-- 
Regards,
Pavel Roskin

Re: [ath5k-devel] [PATCH] ath5k: fix detection of jumbo frames

[Bob Copeland]

On Mon, Nov 3, 2008 at 8:35 AM, Pavel Roskin <proski@gnu.org> wrote:
> Thanks for catching it!  Please mention rs_antenna in addition to
> rs_more.
>
>> -     rs->rs_antenna = rx_status->rx_status_0 &
>> -             AR5K_5210_RX_DESC_STATUS0_RECEIVE_ANTENNA;
>> -     rs->rs_more = rx_status->rx_status_0 &
>> -             AR5K_5210_RX_DESC_STATUS0_MORE;
>> +     rs->rs_antenna = AR5K_REG_MS(rx_status->rx_status_0,
>> +             AR5K_5210_RX_DESC_STATUS0_RECEIVE_ANTENNA);
>> +     rs->rs_more = AR5K_REG_MS(rx_status->rx_status_0,
>> +             AR5K_5210_RX_DESC_STATUS0_MORE);
>
> rs_more should be boolean.  It would be better to use "!!" to calculate
> rs_rate.  No need to shift anything.  As for rs_antenna, it's fine with
   ^^^^^^
I assume you meant rs_more again:  rs_more = !!(rx_status_0 & ...)

>> +#define AR5K_5212_RX_DESC_STATUS0_DECOMP_CRC_ERROR_S 13
>
> This doesn't belong to the patch.  It looks like it's another boolean
> value, but it's not currently used.

ACK, all valid.  I'll respin.

-- 
Bob Copeland %% www.bobcopeland.com

Re: [ath5k-devel] [PATCH] ath5k: fix detection of jumbo frames

[Pavel Roskin]

Quoting Bob Copeland <me@bobcopeland.com>:

> On Mon, Nov 3, 2008 at 8:35 AM, Pavel Roskin <proski@gnu.org> wrote:
>> Thanks for catching it!  Please mention rs_antenna in addition to
>> rs_more.
>>
>>> -     rs->rs_antenna = rx_status->rx_status_0 &
>>> -             AR5K_5210_RX_DESC_STATUS0_RECEIVE_ANTENNA;
>>> -     rs->rs_more = rx_status->rx_status_0 &
>>> -             AR5K_5210_RX_DESC_STATUS0_MORE;
>>> +     rs->rs_antenna = AR5K_REG_MS(rx_status->rx_status_0,
>>> +             AR5K_5210_RX_DESC_STATUS0_RECEIVE_ANTENNA);
>>> +     rs->rs_more = AR5K_REG_MS(rx_status->rx_status_0,
>>> +             AR5K_5210_RX_DESC_STATUS0_MORE);
>>
>> rs_more should be boolean.  It would be better to use "!!" to calculate
>> rs_rate.  No need to shift anything.  As for rs_antenna, it's fine with
>    ^^^^^^
> I assume you meant rs_more again:  rs_more = !!(rx_status_0 & ...)

Yes, sorry.

>>> +#define AR5K_5212_RX_DESC_STATUS0_DECOMP_CRC_ERROR_S 13
>>
>> This doesn't belong to the patch.  It looks like it's another boolean
>> value, but it's not currently used.
>
> ACK, all valid.  I'll respin.

Please do.

-- 
Regards,
Pavel Roskin

[PATCH] ath5k: correct handling of rx status fields

[Bob Copeland]

ath5k_rx_status fields rs_antenna and rs_more are u8s, but we
were setting them with bitwise ANDs of 32-bit values.

As a consequence, jumbo frames would not be discarded as intended.
Then, because the hw rate value of such frames is zero, and, since
63266a653589e1a237527479f10212ea77ce7844 "ath5k: rates cleanup",
we do not fall back to the basic rate, such packets would trigger
the following WARN_ON:

------------[ cut here ]------------
WARNING: at net/mac80211/rx.c:2192 __ieee80211_rx+0x4d/0x57e [mac80211]()
Modules linked in: ath5k af_packet sha256_generic aes_i586 aes_generic cbc loop i915 drm binfmt_misc acpi_cpufreq fan container nls_utf8 hfsplus dm_crypt dm_mod kvm_intel kvm fuse sbp2 snd_hda_intel snd_pcm_oss snd_pcm snd_mixer_oss snd_seq_dummy snd_seq_oss arc4 joydev hid_apple ecb snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device usbhid appletouch mac80211 sky2 snd ehci_hcd ohci1394 bitrev crc32 sr_mod cdrom rtc sg uhci_hcd snd_page_alloc cfg80211 ieee1394 thermal ac battery processor button evdev unix [last unloaded: ath5k]
Pid: 0, comm: swapper Tainted: G        W  2.6.28-rc2-wl #14
Call Trace:
 [<c0123d1e>] warn_on_slowpath+0x41/0x5b
 [<c012005d>] ? sched_debug_show+0x31e/0x9c6
 [<c012489f>] ? vprintk+0x369/0x389
 [<c0309539>] ? _spin_unlock_irqrestore+0x54/0x58
 [<c011cd8f>] ? try_to_wake_up+0x14f/0x15a
 [<f81918cb>] __ieee80211_rx+0x4d/0x57e [mac80211]
 [<f828872a>] ath5k_tasklet_rx+0x5a1/0x5e4 [ath5k]
 [<c013b9cd>] ? clockevents_program_event+0xd4/0xe3
 [<c01283a9>] tasklet_action+0x94/0xfd
 [<c0127d19>] __do_softirq+0x8c/0x13e
 [<c0127e04>] do_softirq+0x39/0x55
 [<c0128082>] irq_exit+0x46/0x85
 [<c010576c>] do_IRQ+0x9a/0xb2
 [<c010461c>] common_interrupt+0x28/0x30
 [<f80e934a>] ? acpi_idle_enter_bm+0x2ad/0x31b [processor]
 [<c02976bf>] cpuidle_idle_call+0x65/0x9a
 [<c010262c>] cpu_idle+0x76/0xa6
 [<c02fb402>] rest_init+0x62/0x64

Signed-off-by: Bob Copeland <me@bobcopeland.com>
---

v2
  - different subject and patch description
  - use !! instead of mask + shift for rs_more
  - remove unneeded changes to desc.h

 drivers/net/wireless/ath5k/desc.c |   16 ++++++++--------
 1 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/ath5k/desc.c b/drivers/net/wireless/ath5k/desc.c
index dd13740..5e362a7 100644
--- a/drivers/net/wireless/ath5k/desc.c
+++ b/drivers/net/wireless/ath5k/desc.c
@@ -531,10 +531,10 @@ static int ath5k_hw_proc_5210_rx_status(struct ath5k_hw *ah,
 		AR5K_5210_RX_DESC_STATUS0_RECEIVE_SIGNAL);
 	rs->rs_rate = AR5K_REG_MS(rx_status->rx_status_0,
 		AR5K_5210_RX_DESC_STATUS0_RECEIVE_RATE);
-	rs->rs_antenna = rx_status->rx_status_0 &
-		AR5K_5210_RX_DESC_STATUS0_RECEIVE_ANTENNA;
-	rs->rs_more = rx_status->rx_status_0 &
-		AR5K_5210_RX_DESC_STATUS0_MORE;
+	rs->rs_antenna = AR5K_REG_MS(rx_status->rx_status_0,
+		AR5K_5210_RX_DESC_STATUS0_RECEIVE_ANTENNA);
+	rs->rs_more = !!(rx_status->rx_status_0 &
+		AR5K_5210_RX_DESC_STATUS0_MORE);
 	/* TODO: this timestamp is 13 bit, later on we assume 15 bit */
 	rs->rs_tstamp = AR5K_REG_MS(rx_status->rx_status_1,
 		AR5K_5210_RX_DESC_STATUS1_RECEIVE_TIMESTAMP);
@@ -607,10 +607,10 @@ static int ath5k_hw_proc_5212_rx_status(struct ath5k_hw *ah,
 		AR5K_5212_RX_DESC_STATUS0_RECEIVE_SIGNAL);
 	rs->rs_rate = AR5K_REG_MS(rx_status->rx_status_0,
 		AR5K_5212_RX_DESC_STATUS0_RECEIVE_RATE);
-	rs->rs_antenna = rx_status->rx_status_0 &
-		AR5K_5212_RX_DESC_STATUS0_RECEIVE_ANTENNA;
-	rs->rs_more = rx_status->rx_status_0 &
-		AR5K_5212_RX_DESC_STATUS0_MORE;
+	rs->rs_antenna = AR5K_REG_MS(rx_status->rx_status_0,
+		AR5K_5212_RX_DESC_STATUS0_RECEIVE_ANTENNA);
+	rs->rs_more = !!(rx_status->rx_status_0 &
+		AR5K_5212_RX_DESC_STATUS0_MORE);
 	rs->rs_tstamp = AR5K_REG_MS(rx_status->rx_status_1,
 		AR5K_5212_RX_DESC_STATUS1_RECEIVE_TIMESTAMP);
 	rs->rs_status = 0;
-- 
1.5.4.2.182.gb3092