[PATCH] ath5k: drop warning on jumbo frames

[PATCH] ath5k: drop warning on jumbo frames

[Luis R. Rodriguez]

Jumbo frames are not supported, and if they are seen it is likely
a bogus frame so just silently discard them instead of warning on
them all time. Also, instead of dropping them immediately though
move the check *after* we check for all sort of frame errors. This
should enable us to discard these frames if the hardware picks
other bogus items first. Lets see if we still get those jumbo
counters increasing still with this.

Jumbo frames would happen if we tell hardware we can support
a small 802.11 chunks of DMA'd frame, hardware would split RX'd
frames into parts and we'd have to reconstruct them in software.
This is done with USB due to the bulk size but with ath5k we
already provide a good limit to hardware and this should not be
happening.

This is reported quite often and if it fills the logs then this
needs to be addressed and to avoid spurious reports.

Cc: stable@kernel.org
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 drivers/net/wireless/ath/ath5k/base.c |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 3cf35c4..9c27623 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -1932,12 +1932,6 @@ ath5k_tasklet_rx(unsigned long data)
 
 		sc->stats.rx_all_count++;
 
-		if (unlikely(rs.rs_more)) {
-			ATH5K_WARN(sc, "unsupported jumbo\n");
-			sc->stats.rxerr_jumbo++;
-			goto next;
-		}
-
 		if (unlikely(rs.rs_status)) {
 			if (rs.rs_status & AR5K_RXERR_CRC)
 				sc->stats.rxerr_crc++;
@@ -1977,6 +1971,12 @@ ath5k_tasklet_rx(unsigned long data)
 					sc->opmode != NL80211_IFTYPE_MONITOR)
 				goto next;
 		}
+
+		if (unlikely(rs.rs_more)) {
+			sc->stats.rxerr_jumbo++;
+			goto next;
+
+		}
 accept:
 		next_skb = ath5k_rx_skb_alloc(sc, &next_skb_addr);
 
-- 
1.6.3.3

Re: [stable] [PATCH] ath5k: drop warning on jumbo frames

[Greg KH]

On Mon, May 10, 2010 at 03:26:27PM -0400, Luis R. Rodriguez wrote:
> Jumbo frames are not supported, and if they are seen it is likely
> a bogus frame so just silently discard them instead of warning on
> them all time. Also, instead of dropping them immediately though
> move the check *after* we check for all sort of frame errors. This
> should enable us to discard these frames if the hardware picks
> other bogus items first. Lets see if we still get those jumbo
> counters increasing still with this.
> 
> Jumbo frames would happen if we tell hardware we can support
> a small 802.11 chunks of DMA'd frame, hardware would split RX'd
> frames into parts and we'd have to reconstruct them in software.
> This is done with USB due to the bulk size but with ath5k we
> already provide a good limit to hardware and this should not be
> happening.
> 
> This is reported quite often and if it fills the logs then this
> needs to be addressed and to avoid spurious reports.
> 
> Cc: stable@kernel.org
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
>  drivers/net/wireless/ath/ath5k/base.c |   12 ++++++------

This is now upstream, but doesn't seem to apply to any of the .32, .33,
or .34 trees.  If you want it there, please send me a backported version
of it.

thanks,

greg k-h

Re: [stable] [PATCH] ath5k: drop warning on jumbo frames

[Luis R. Rodriguez]

On Thu, Jun 03, 2010 at 03:09:47PM -0700, Greg KH wrote:
> On Mon, May 10, 2010 at 03:26:27PM -0400, Luis R. Rodriguez wrote:
> > Jumbo frames are not supported, and if they are seen it is likely
> > a bogus frame so just silently discard them instead of warning on
> > them all time. Also, instead of dropping them immediately though
> > move the check *after* we check for all sort of frame errors. This
> > should enable us to discard these frames if the hardware picks
> > other bogus items first. Lets see if we still get those jumbo
> > counters increasing still with this.
> > 
> > Jumbo frames would happen if we tell hardware we can support
> > a small 802.11 chunks of DMA'd frame, hardware would split RX'd
> > frames into parts and we'd have to reconstruct them in software.
> > This is done with USB due to the bulk size but with ath5k we
> > already provide a good limit to hardware and this should not be
> > happening.
> > 
> > This is reported quite often and if it fills the logs then this
> > needs to be addressed and to avoid spurious reports.
> > 
> > Cc: stable@kernel.org
> > Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> > ---
> >  drivers/net/wireless/ath/ath5k/base.c |   12 ++++++------
> 
> This is now upstream, but doesn't seem to apply to any of the .32, .33,
> or .34 trees.  If you want it there, please send me a backported version
> of it.

Thanks Greg. I cannot address this right now so I've stashed it here:

http://wireless.kernel.org/en/developers/stable-pending

If anyone has free time please feel free to address the backport and
any other listed above (just one more).

  Luis