ath5k: fix detection of jumbo frames

PATCH In review Bob Copeland 4 participants 10 messages Nov 2, 2008 – Nov 4, 2008 Networking drivers (wireless)

Share & tools

Bob Copeland

author

2008-11-02 19:09 UTC #0 lore raw

PATCH 1/1 ath5k: fix detection of jumbo frames

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 <[email protected]>

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

drivers/net/wireless/ath5k/desc.c +8 -8

index dd13740..0f982fb 100644
@@ -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;

drivers/net/wireless/ath5k/desc.h +3 -0

index 56158c8..80630d9 100644
@@ -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

Signature · 1 line

1.5.4.2.182.gb3092

Luis R. Rodriguez

2008-11-02 21:00 UTC #1 lore raw

On Sun, Nov 2, 2008 at 11:08 AM, Bob Copeland <[email protected]> wrote:

Nice find.

Quoted 1 line

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.

Quoted 3 lines

, 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

Bob Copeland

author

2008-11-02 21:52 UTC #2 lore raw

Quoted 7 lines · Luis R. Rodriguez

Quoted 3 lines
, 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.

Signature · 1 line

Bob Copeland %% www.bobcopeland.com

Luis R. Rodriguez

2008-11-02 22:33 UTC #3 lore raw

Quoted 5 lines · Bob Copeland

Quoted 4 lines · Luis R. Rodriguez
Quoted 3 lines
, and, since
63266a653589e1a237527479f10212ea77ce7844 "ath5k: rates cleanup", we do not fall back to the basic rate, such packets would trigger the following WARN_ON:

Quoted 8 lines

Quoted 3 lines
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.

Quoted 9 lines

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:
(quoted diff) +0 -4
-       /* Something went wrong, fallback to basic rate for this band */
-       if ((mac80211_rix >= sc->curband->n_bitrates) ||
-               (mac80211_rix <= 0 ))
-               mac80211_rix = 1;

Quoted 5 lines

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

Bob Copeland

author

2008-11-03 02:45 UTC #4 lore raw

Quoted 6 lines · Luis R. Rodriguez

Quoted 4 lines
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.

Signature · 1 line

Bob Copeland %% www.bobcopeland.com

Kalle Valo

2008-11-03 07:29 UTC #5 lore raw

In reply to Luis R. Rodriguez

(Trimmed CC list)

Quoted 7 lines · Luis R. Rodriguez

Quoted 3 lines
, 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.

Signature · 1 line

Kalle Valo

Pavel Roskin

2008-11-03 13:35 UTC #6 lore raw

In reply to Bob Copeland

Quoted 7 lines · 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:

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

drivers/net/wireless/ath5k/desc.c static int ath5k_hw_proc_5210_rx_status(struct ath5k_hw *ah, · line 537

Quoted 8 lines

drivers/net/wireless/ath5k/desc.c +4 -4

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

Quoted 1 line

+#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.

Signature · 2 lines

Regards,
Pavel Roskin

Bob Copeland

author

2008-11-03 14:26 UTC #7 lore raw

Quoted 12 lines · Pavel Roskin

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

drivers/net/wireless/ath5k/desc.c static int ath5k_hw_proc_5210_rx_status(struct ath5k_hw *ah, · line 537

Quoted 8 lines

drivers/net/wireless/ath5k/desc.c +4 -4

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

Quoted 2 lines

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

Quoted 4 lines

Quoted 1 line
+#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.

Signature · 1 line

Bob Copeland %% www.bobcopeland.com

Pavel Roskin

2008-11-03 14:37 UTC #8 lore raw

Quoting Bob Copeland <[email protected]>:

Quoted 13 lines · Pavel Roskin

Quoted 12 lines

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

Quoted 8 lines

drivers/net/wireless/ath5k/desc.c +4 -4

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

Quoted 4 lines

Quoted 2 lines
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.

Quoted 6 lines

Quoted 4 lines
Quoted 1 line
+#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.

Signature · 2 lines

Regards,
Pavel Roskin

Bob Copeland

author

2008-11-04 03:14 UTC #9 lore raw

PATCH 1/1 ath5k: correct handling of rx status fields

In reply to 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 <[email protected]>

---

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

drivers/net/wireless/ath5k/desc.c +8 -8

index dd13740..5e362a7 100644
@@ -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;

Signature · 1 line

1.5.4.2.182.gb3092