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?
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On 2011-02-10 8:43 PM, Ben Greear wrote:
> On 02/10/2011 11:23 AM, Felix Fietkau wrote:
>> 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.
>
> I'd by happy to test one..but I get seriously confused in this code.
>
> I *think* that maybe this would entail modifying the qos field a few lines
> above my hack..but I'm not sure, and not sure to what value it should
> be set.
No, you should not modify the QoS header. Modify skb->priority before
the 802.11 header is generated.
- Felix
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
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?
Helmut
On 02/10/2011 11:23 AM, Felix Fietkau wrote:
> 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.
I'd by happy to test one..but I get seriously confused in this code.
I *think* that maybe this would entail modifying the qos field a few lines
above my hack..but I'm not sure, and not sure to what value it should
be set.
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On 02/10/2011 12:31 AM, Helmut Schaa wrote:
> Hi Ben,
>
> 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.
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
From: Helmut Schaa <[email protected]>
Date: Thu, 10 Feb 2011 18:54:41 +0100
> Why not make pktgen use the select_queue callback instead?
Because the whole point of what pktgen is doing is to allow the
testing of explicit iteration through the available network queues.
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.
- Felix
On 02/09/2011 03:00 PM, Ben Greear wrote:
> 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.
This stuff hurts my head..but maybe this will help:
tidno: 0 tid->ac->txq: f050dc5c txctl->txq: f050db4c
tid->ac->txq: mac80211_qnum: 2 axq_qnum: 2
txctl->txq: mac80211_qnum: 0 axq_qnum: 0
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
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 <[email protected]>
Candela Technologies Inc http://www.candelatech.com
Hi Ben,
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".
Helmut