Am Donnerstag, 10. Februar 2011 schrieb Felix Fietkau: > On 2011-02-10 7:00 PM, Ben Greear wrote: > > 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. > How about adding a patch that makes mac80211 detect a mismatch between > skb->priority and the queue mapping and then adjust the skb priority > based on that. Sounds reasonable to me. But please also add a WARN_ON_ONCE in that case as otherwise we wouldn't detect broken queue selection under "normal" conditions anymore. Helmut -- 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