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(-)
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
Quoting Bob Copeland <[email protected]>:
> On Mon, Nov 3, 2008 at 8:35 AM, Pavel Roskin <[email protected]> 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
On Mon, Nov 3, 2008 at 8:35 AM, Pavel Roskin <[email protected]> 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 %% http://www.bobcopeland.com
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
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(-)
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
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 %% http://www.bobcopeland.com
On Sun, Nov 2, 2008 at 11:08 AM, Bob Copeland <[email protected]> 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
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 %% http://www.bobcopeland.com
(Trimmed CC list)
Luis R. Rodriguez <[email protected]> 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
On Sun, Nov 2, 2008 at 1:52 PM, Bob Copeland <[email protected]> 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