Bug 16098
Summary: | mesh-mode causes ath5k phy0: unsupported jumbo | ||
---|---|---|---|
Product: | Networking | Reporter: | Christian Mehlis (mehlis) |
Component: | Wireless | Assignee: | networking_wireless (networking_wireless) |
Status: | RESOLVED CODE_FIX | ||
Severity: | normal | CC: | linville, me, mehlis |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.34-generic | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
full massages
packets.pcap |
Description
Christian Mehlis
2010-06-01 20:37:22 UTC
Seems a bit odd that transmitting a beacon would result in receiving a jumbo frame...? hm, today i am not able to reproduce this. i will test it the next days and try to find the exacts steps to reproduce! my syslog from yesterday is full of phy0: unsupported jumbo.... ok i got it very fast: create mesh interface on host a with AR5001 now i have only the mesh dev up, nothing else. the log gets filled. i tested: host a (AR5001) host b/c (other) create mesh interface on host a with AR5001 create mesh interface on host b they join, but the massages on a only shows SOME beacons as jumbo?! i attach the massages with timestaps and the pcap captured by host c (passive) wireshark is 1.3.4 with mesh-patch Created attachment 26626 [details]
full massages
Created attachment 26627 [details]
packets.pcap
Still seems crazy that this would relate to beacon tx, but anyway... commit 9637e516d16a58b13f6098cfe899e22963132be3 Author: Luis R. Rodriguez <lrodriguez@atheros.com> Date: Mon May 10 15:26:27 2010 -0400 ath5k: drop warning on jumbo frames 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> Signed-off-by: John W. Linville <linville@tuxdriver.com> |