On 02/09/2011 05:15 PM, Felix Fietkau wrote:
On 2011-02-10 2:05 AM, greearb@xxxxxxxxxxxxxxx wrote:
From: Ben Greear<greearb@xxxxxxxxxxxxxxx>
Otherwise, ath9k gets confused about which queue to use
and spews a warning like this when driving traffic with
pktgen.
WARNING: at drivers/net/wireless/ath/ath9k/xmit.c:1748 ath_tx_start+0x4a2/0x662 [ath9k]()
Hardware name: To Be Filled By O.E.M.
Modules linked in: ath5k arc4 ath9k mac80211 ath9k_common ath9k_hw ath cfg80211 nfs lockd bluetooth cryptd aes_i586 aes_generic veth 8021q garp stp l]
Pid: 1729, comm: kpktgend_0 Tainted: G W 2.6.38-rc4-wl+ #21
Call Trace:
[<c043091b>] ? warn_slowpath_common+0x65/0x7a
[<fabe784e>] ? ath_tx_start+0x4a2/0x662 [ath9k]
[<c043093f>] ? warn_slowpath_null+0xf/0x13
[<fabe784e>] ? ath_tx_start+0x4a2/0x662 [ath9k]
[<fabe14d0>] ? ath9k_tx+0x14f/0x183 [ath9k]
[<fab9026d>] ? __ieee80211_tx+0x10c/0x18c [mac80211]
[<fab90397>] ? ieee80211_tx+0xaa/0x188 [mac80211]
[<fab905f3>] ? ieee80211_xmit+0x17e/0x186 [mac80211]
[<fab8ecc0>] ? ieee80211_skb_resize+0x8e/0xd2 [mac80211]
[<fab9148b>] ? ieee80211_subif_start_xmit+0x643/0x65c [mac80211]
[<c0440000>] ? rescuer_thread+0x25/0x1c8
[<f92cd354>] ? pktgen_thread_worker+0x114c/0x1b44 [pktgen]
[<fab90e48>] ? ieee80211_subif_start_xmit+0x0/0x65c [mac80211]
[<c042d612>] ? default_wake_function+0xb/0xd
[<c04254c7>] ? __wake_up_common+0x34/0x5c
[<c0443a29>] ? autoremove_wake_function+0x0/0x2f
[<f92cc208>] ? pktgen_thread_worker+0x0/0x1b44 [pktgen]
[<c044371a>] ? kthread+0x62/0x67
[<c04436b8>] ? kthread+0x0/0x67
[<c04035f6>] ? kernel_thread_helper+0x6/0x10
Signed-off-by: Ben Greear<greearb@xxxxxxxxxxxxxxx>
---
NOTE: This needs review by someone who actually understands this code.
:100644 100644 17ef4f4... 95eb4fa... M net/mac80211/tx.c
net/mac80211/tx.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 17ef4f4..95eb4fa 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2028,6 +2028,8 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
} else
memcpy(skb_push(skb, hdrlen),&hdr, hdrlen);
+ skb_set_queue_mapping(skb, ieee80211_select_queue(sdata, skb));
I think this is wrong - it's up to the network stack to set up the queue
mapping. The bug you're looking for is probably in pktgen - I think
there was a similar issue in the bridge code at some point, which was
also fixed.
Pktgen has a feature that allows it to set the queue-map. The problem
is that wifi, and particular ath9k, has some preconceptions about what
skb priority should match to what queue, it seems.
I think that mac80211 should do whatever needed to fix up any skb
handed to it.
An alternative is to hack on ath9k to make it handle that case,
but even if we got that to work somehow, other drivers may have
similar issues.
Or, fix thing somehow so that if pktgen says queue-map is 0, then
the wifi code just accepts that and doesn't try to use queue 2
instead.
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
