Bug 16098 - mesh-mode causes ath5k phy0: unsupported jumbo
mesh-mode causes ath5k phy0: unsupported jumbo
Status: RESOLVED CODE_FIX
Product: Networking
Classification: Unclassified
Component: Wireless
All Linux
: P1 normal
Assigned To: networking_wireless@kernel-bugs.osdl.org
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-01 20:37 UTC by Christian Mehlis
Modified: 2010-06-22 18:55 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.34-generic
Tree: Mainline
Regression: No


Attachments
full massages (51.95 KB, application/x-bzip)
2010-06-02 21:21 UTC, Christian Mehlis
Details
packets.pcap (5.51 KB, application/x-bzip)
2010-06-02 21:22 UTC, Christian Mehlis
Details

Description Christian Mehlis 2010-06-01 20:37:22 UTC
if i enable mesh-mode-interface, beacons will send out.
every beacon triggers a ath5k phy0: unsupported jumbo

02:00.0 Ethernet controller: Atheros Communications Inc. AR5001 Wireless Network Adapter (rev 01)

02:00.0 0200: 168c:001c (rev 01)
	Subsystem: 144f:7131
	Flags: bus master, fast devsel, latency 0, IRQ 16
	Memory at f0100000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: [40] Power Management version 2
	Capabilities: [50] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
	Capabilities: [60] Express Legacy Endpoint, MSI 00
	Capabilities: [90] MSI-X: Enable- Mask- TabSize=1
	Capabilities: [100] Advanced Error Reporting <?>
	Capabilities: [140] Virtual Channel <?>
	Kernel driver in use: ath5k
	Kernel modules: ath5k
Comment 1 John W. Linville 2010-06-02 12:50:08 UTC
Seems a bit odd that transmitting a beacon would result in receiving a jumbo frame...?
Comment 2 Christian Mehlis 2010-06-02 20:48:45 UTC
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....
Comment 3 Christian Mehlis 2010-06-02 21:21:24 UTC
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
Comment 4 Christian Mehlis 2010-06-02 21:21:50 UTC
Created attachment 26626 [details]
full massages
Comment 5 Christian Mehlis 2010-06-02 21:22:28 UTC
Created attachment 26627 [details]
packets.pcap
Comment 6 John W. Linville 2010-06-22 18:55:09 UTC
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>

Note You need to log in before you can comment on or make changes to this bug.