On 02/10/2011 09:54 AM, Helmut Schaa wrote:
Am Donnerstag, 10. Februar 2011 schrieb Ben Greear:
On 02/10/2011 12:31 AM, Helmut Schaa wrote:
Am Donnerstag, 10. Februar 2011 schrieb Ben Greear:
I see this warning when I generate traffic with a hacked version
of pktgen. This works with various other interfaces w/out problems,
so I think it's probably an ath9k and/or mac80211 bug.
WARNING: at /home/greearb/git/linux.wireless-testing-ct/drivers/net/wireless/ath/ath9k/xmit.c:1735 ath_tx_start+0x43c/0x607 [ath9k]()
Hardware name: To Be Filled By O.E.M.
Modules linked in: bridge nfs lockd bluetooth cryptd aes_i586 aes_generic veth 8021q garp stp llc fuse macvlan pktgen coretemp hwmon fscache nfs_acl auth_rpcgss
sunrpc ipv6 uinput arc4 ecb snd_hda_codec_realtek ath9k snd_hda_intel snd_hda_codec mac80211 snd_hwdep snd_seq snd_seq_device ath9k_common ath9k_hw snd_pcm ath
cfg80211 microcode snd_timer iTCO_wdt snd iTCO_vendor_support i2c_i801 serio_raw pcspkr soundcore r8169 snd_page_alloc mii i915 drm_kms_helper drm i2c_algo_bit
video [last unloaded: lockd]
Pid: 1729, comm: kpktgend_0 Tainted: G W 2.6.38-rc4-wl+ #21
Call Trace:
[<c043091b>] ? warn_slowpath_common+0x65/0x7a
[<f8ded7e8>] ? ath_tx_start+0x43c/0x607 [ath9k]
[<c043093f>] ? warn_slowpath_null+0xf/0x13
[<f8ded7e8>] ? ath_tx_start+0x43c/0x607 [ath9k]
[<f8de74d0>] ? ath9k_tx+0x14f/0x183 [ath9k]
[<f8d1326d>] ? __ieee80211_tx+0x10c/0x18c [mac80211]
[<f8d13397>] ? ieee80211_tx+0xaa/0x188 [mac80211]
[<f8d135f3>] ? ieee80211_xmit+0x17e/0x186 [mac80211]
[<f8d11cc0>] ? ieee80211_skb_resize+0x8e/0xd2 [mac80211]
[<f8d1448b>] ? ieee80211_subif_start_xmit+0x643/0x65c [mac80211]
[<c0440000>] ? rescuer_thread+0x25/0x1c8
[<f92cd354>] ? pktgen_thread_worker+0x114c/0x1b44 [pktgen]
[<f8d13e48>] ? 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
/* FIXME: tx power */
static void ath_tx_start_dma(struct ath_softc *sc, struct ath_buf *bf,
struct ath_tx_control *txctl)
{
struct sk_buff *skb = bf->bf_mpdu;
struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb);
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
struct list_head bf_head;
struct ath_atx_tid *tid = NULL;
u8 tidno;
spin_lock_bh(&txctl->txq->axq_lock);
if (ieee80211_is_data_qos(hdr->frame_control)&& txctl->an) {
tidno = ieee80211_get_qos_ctl(hdr)[0]&
IEEE80211_QOS_CTL_TID_MASK;
tid = ATH_AN_2_TID(txctl->an, tidno);
WARN_ON(tid->ac->txq != txctl->txq);
}
Anyone have any ideas on this one?
pktgen seems to directly inject frames via the xmit callback and hence
mac80211's select_queue callback isn't used for proper queue assignment.
However, you should be able to specify the queue manuelly with
"cur_queue_map".
Yes, but I don't think I should have to know this detail.
Once you send pkts with queue-map of 0 to ath9k, it spews
kernel warnings and then you have to rmmod the NIC before
it will start working again (because it's queues are
messed up probably).
I'm not sure my patch is the correct way to fix it, but
we need to do _something_ in mac80211 and/or ath9k I think.
Why not make pktgen use the select_queue callback instead?
It's a test tool and should be able to force queue selection
if it wants to. I'd rather not have special case code to
know if underlying interface is wifi (and thus need special
queue selection).
I'd rather carry that hack to mac80211 I posted instead,
if it comes to that.
Thanks,
Ben
Helmut
--
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
