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
On Sat, Jan 23, 2010 at 10:32 AM, Bob Copeland <[email protected]> wrote:
> On Sat, Jan 23, 2010 at 8:40 AM, Jonathan Nieder <[email protected]> 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
On Sat, Jan 23, 2010 at 8:40 AM, Jonathan Nieder <[email protected]> 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 %% http://www.bobcopeland.com
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 <[email protected]> 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 [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
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 <[email protected]>
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 <[email protected]>
Signed-off-by: Jonathan Nieder <[email protected]>
---
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;
}
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