[PATCH] ath5k: fix detection of jumbo frames - Kernel

This is a discussion on [PATCH] ath5k: fix detection of jumbo frames - Kernel ; 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 ...

+ Reply to Thread
Results 1 to 8 of 8

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

  1. [PATCH] 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:
    [] warn_on_slowpath+0x41/0x5b
    [] ? sched_debug_show+0x31e/0x9c6
    [] ? vprintk+0x369/0x389
    [] ? _spin_unlock_irqrestore+0x54/0x58
    [] ? try_to_wake_up+0x14f/0x15a
    [] __ieee80211_rx+0x4d/0x57e [mac80211]
    [] ath5k_tasklet_rx+0x5a1/0x5e4 [ath5k]
    [] ? clockevents_program_event+0xd4/0xe3
    [] tasklet_action+0x94/0xfd
    [] __do_softirq+0x8c/0x13e
    [] do_softirq+0x39/0x55
    [] irq_exit+0x46/0x85
    [] do_IRQ+0x9a/0xb2
    [] common_interrupt+0x28/0x30
    [] ? acpi_idle_enter_bm+0x2ad/0x31b [processor]
    [] cpuidle_idle_call+0x65/0x9a
    [] cpu_idle+0x76/0xa6
    [] rest_init+0x62/0x64

    Signed-off-by: Bob Copeland
    ---
    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


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    On Sun, Nov 2, 2008 at 11:08 AM, Bob Copeland 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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    On Mon, Nov 3, 2008 at 8:35 AM, Pavel Roskin 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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    Quoting Bob Copeland :

    > On Mon, Nov 3, 2008 at 8:35 AM, Pavel Roskin 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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. [PATCH] ath5k: correct handling of rx status fields

    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:
    [] warn_on_slowpath+0x41/0x5b
    [] ? sched_debug_show+0x31e/0x9c6
    [] ? vprintk+0x369/0x389
    [] ? _spin_unlock_irqrestore+0x54/0x58
    [] ? try_to_wake_up+0x14f/0x15a
    [] __ieee80211_rx+0x4d/0x57e [mac80211]
    [] ath5k_tasklet_rx+0x5a1/0x5e4 [ath5k]
    [] ? clockevents_program_event+0xd4/0xe3
    [] tasklet_action+0x94/0xfd
    [] __do_softirq+0x8c/0x13e
    [] do_softirq+0x39/0x55
    [] irq_exit+0x46/0x85
    [] do_IRQ+0x9a/0xb2
    [] common_interrupt+0x28/0x30
    [] ? acpi_idle_enter_bm+0x2ad/0x31b [processor]
    [] cpuidle_idle_call+0x65/0x9a
    [] cpu_idle+0x76/0xa6
    [] rest_init+0x62/0x64

    Signed-off-by: Bob Copeland
    ---

    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


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread