ath5k phy0: unsupported jumbo

ath5k phy0: unsupported jumbo

[Jonathan Nieder]

Hi,

Every now and then, I get a few messages like the following:

[11316.285087] ath5k phy0: unsupported jumbo
[14256.975594] ath5k phy0: unsupported jumbo
[26376.342970] ath5k phy0: unsupported jumbo

drivers/net/wireless/ath/ath5k/base.c tells me this is unlikely (or at
least the slow path), and that it means that after calling the
sc->ah->ah_proc_rx_desc(sc->ah, ds, &rs) callback, rs.rs_more was
nonzero.

What I still don’t know:

 - So, what happened?
 - Does this indicate some subtle misconfiguration?
 - Is this a hardware bug?
 - Is this a driver bug?

The network generally works great, so there is no cause for me to
worry, but still it would give me some peace of mind to know.

In turn, I would gladly write a Documentation/networking/ath5k.txt or
a comment near drivers/net/wireless/ath/ath5k/base.c:1817 for others
to refer to.

Thoughts?
Jonathan

$ uname -r
2.6.33-rc4-next-20100121-04118-gbaa1751

Re: ath5k phy0: unsupported jumbo

[Kacper]

Hi,

I also have this problem with that message appearing in my console. As
far as I know it has to do with that Jumbo frame processing  is broken
in the ath5k driver. It's listen under the ath5k todo tasks at
<http://linuxwireless.org/en/users/Drivers/ath5k>.

On Sat, Jan 23, 2010 at 11:51 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi,
>
> Every now and then, I get a few messages like the following:
>
> [11316.285087] ath5k phy0: unsupported jumbo
> [14256.975594] ath5k phy0: unsupported jumbo
> [26376.342970] ath5k phy0: unsupported jumbo
>
> drivers/net/wireless/ath/ath5k/base.c tells me this is unlikely (or at
> least the slow path), and that it means that after calling the
> sc->ah->ah_proc_rx_desc(sc->ah, ds, &rs) callback, rs.rs_more was
> nonzero.
>
> What I still don’t know:
>
>  - So, what happened?
>  - Does this indicate some subtle misconfiguration?
>  - Is this a hardware bug?
>  - Is this a driver bug?
>
> The network generally works great, so there is no cause for me to
> worry, but still it would give me some peace of mind to know.
>
> In turn, I would gladly write a Documentation/networking/ath5k.txt or
> a comment near drivers/net/wireless/ath/ath5k/base.c:1817 for others
> to refer to.
>
> Thoughts?
> Jonathan
>
> $ uname -r
> 2.6.33-rc4-next-20100121-04118-gbaa1751
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: ath5k phy0: unsupported jumbo

[Jonathan Nieder]

Kacper wrote:

> It's listen under the ath5k todo tasks at
> <http://linuxwireless.org/en/users/Drivers/ath5k>.

Thanks for the pointer.  Looks like Bob Copeland investigated this last
year. [1]  Looking at messages from around that time, I find some words
of explanation: [2]

| I think the jumbo flag is supposed to indicate the packet is larger
| than the buffer size.  However, we have a buffer size of 2500 so that
| shouldn't happen for standard frames.  I did check into whether there
| was a corruption issue, like skb_tailroom was smaller than a full 
| packet because of an skb reuse bug or something like that.  But no, 
| all were > 2500 bytes (incl roundup for cache line).  That's when 
| I did the unmap and a hexdump and saw they have no 802.11 headers or
| anything of the sort.  Felix suggested we just drop the warning.

So it looks like we receive some strange packets that haven’t been
explained yet.  It might be worth looking at a few --- sounds kind of
interesting.

Am I understanding correctly?  This is a hardware bug or undocumented
hardware feature then, right?

It might be nice to add some user-oriented explanation too, but for
now, how about this comment?

Thanks,
Jonathan

[1] http://linuxwireless.org/en/users/Drivers/ath5k?action=diff&rev1=36&rev2=37
[2] http://thread.gmane.org/gmane.linux.kernel.wireless.general/27439/focus=27476

-- %< --
From: Jonathan Nieder <jrnieder@gmail.com>
Subject: ath5k: Add a comment describing the unsupported jumbo phenomenon

Every now and then, the ath5k driver warns:

ath5k phy0: unsupported jumbo

Add some notes for the curious sysadmin to find when grepping for
an explanation.

Cc: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
 drivers/net/wireless/ath/ath5k/base.c |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 5577bcc..9fffe6c 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -1814,6 +1814,19 @@ ath5k_tasklet_rx(unsigned long data)
 		}
 
 		if (unlikely(rs.rs_more)) {
+			/*
+			 * The jumbo flag is supposed to indicate the packet
+			 * is larger than the buffer size.  However, we have a
+			 * buffer size of 2500 so that shouldn't happen for
+			 * standard frames.
+			 *
+			 * The relevant frames really are all > 2500 bytes
+			 * (including roundup for cache line).  unmap and
+			 * hexdump reveals that they have no 802.11 headers or
+			 * anything of the sort.
+			 *
+			 * XXX just drop the warning?
+			 */
 			ATH5K_WARN(sc, "unsupported jumbo\n");
 			goto next;
 		}

Re: ath5k phy0: unsupported jumbo

[Bob Copeland]

On Sat, Jan 23, 2010 at 8:40 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> So it looks like we receive some strange packets that haven’t been
> explained yet.  It might be worth looking at a few --- sounds kind of
> interesting.
>
> Am I understanding correctly?  This is a hardware bug or undocumented
> hardware feature then, right?
>
> It might be nice to add some user-oriented explanation too, but for
> now, how about this comment?
>

That's ok with me.  I'd also be fine with removing the log spam.  I think
ultimately it represents some kind of driver issue, I'm just not sure what,
exactly, yet.  I recently added more debugging to a kernel on a system of
mine that produces it more often -- I'll see what it turns up.

-- 
Bob Copeland %% www.bobcopeland.com

Re: ath5k phy0: unsupported jumbo

[Luis R. Rodriguez]

On Sat, Jan 23, 2010 at 10:32 AM, Bob Copeland <me@bobcopeland.com> wrote:
> On Sat, Jan 23, 2010 at 8:40 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> So it looks like we receive some strange packets that haven’t been
>> explained yet.  It might be worth looking at a few --- sounds kind of
>> interesting.
>>
>> Am I understanding correctly?  This is a hardware bug or undocumented
>> hardware feature then, right?
>>
>> It might be nice to add some user-oriented explanation too, but for
>> now, how about this comment?
>>
>
> That's ok with me.  I'd also be fine with removing the log spam.  I think
> ultimately it represents some kind of driver issue, I'm just not sure what,
> exactly, yet.  I recently added more debugging to a kernel on a system of
> mine that produces it more often -- I'll see what it turns up.

Jumbo frames are frames which the hardware receives for which it does
not have enough DMA leg room for, and so needs to split it out into
multiple descriptors. It should be OK to just drop them if ath5k is
setting the max RX dma size to the max 802.11 frame, as they could be
bogus frames or 11n AMSDU frames which ath5k obviously would not
support.

  Luis

Re: ath5k phy0: unsupported jumbo

[Vladimir Linevich]

I've found that this bug is a result of poor hardware ASPM support.
It is a hardware bug that is worked around in windows driver by
disabling PCIE ASPM L0S.
There's a solution - turn ASPM L0S off for this device.
---
1. Download enable-aspm
kernel org/pub/linux/kernel/people/mcgrof/aspm/enable-aspm

2. Get your root complex:
$ lspci -tv 
0000:00 
... 
+-1c.2-[0000:03]----00.0 Atheros Communications Inc. AR5001 Wireless Network 
Adapter 
...

00:1c.2 
3. Get your endpoint: 
$ lspci 
... 
03:00.0 Ethernet controller: Atheros Communications Inc. AR5001 Wireless Network 
Adapter (rev 01) 
...
= 03:00.0 

4. Now you neet to edit your enable-aspm

# You just need to modify these three values: 

ROOT_COMPLEX="00:1c.2" 
ENDPOINT="03:00.0" 

ASPM_SETTING=2 

5. Now executing: 
vo-one@acerone:~$ sudo bash enable-aspm 
[sudo] password for vo-one: 
Root complex: 
00:1c.2 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 3 (rev 
02) 
0x50 : 0x43 --> 0x42 ... [SUCCESS]] 
L1 only 

Endpoint: 
03:00.0 Ethernet controller: Atheros Communications Inc. AR5001 Wireless Network 
Adapter (rev 01) 
0x70 : 0x4B --> 0x4A ... [SUCCESS]] 
L1 only 

6. Making the script executed at system startup:
sudo chmod +x enable-aspm
sudo cp enable-aspm /usr/bin
sudo cat "enable-aspm" > /etc/rc.conf

hope that helps