ath9k and pktgen generate WARNings.

DISCUSSION Ben Greear 4 participants 11 messages Feb 9, 2011 – Feb 10, 2011

Share & tools

Ben Greear

author

2011-02-09 23:00 UTC #0 lore raw

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

Signature · 2 lines

Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com

Ben Greear

author

2011-02-09 23:36 UTC #1 lore raw

Quoted 3 lines · 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.

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

Signature · 2 lines

Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com

Helmut Schaa

2011-02-10 08:33 UTC #2 lore raw

In reply to Ben Greear

Hi Ben,

Am Donnerstag, 10. Februar 2011 schrieb Ben Greear:

Quoted 56 lines

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);
	}

Quoted 1 line

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

Ben Greear

author

2011-02-10 17:19 UTC #3 lore raw

Quoted 59 lines · Helmut Schaa

Hi Ben,

Am Donnerstag, 10. Februar 2011 schrieb Ben Greear:

Quoted 56 lines

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

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);
	}

Quoted 7 lines

Quoted 1 line
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

Signature · 2 lines

Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com

Helmut Schaa

2011-02-10 17:56 UTC #4 lore raw

Am Donnerstag, 10. Februar 2011 schrieb Ben Greear:

Quoted 68 lines · Helmut Schaa

Quoted 57 lines
Am Donnerstag, 10. Februar 2011 schrieb Ben Greear:
Quoted 56 lines
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);
	}
Quoted 7 lines
Quoted 1 line
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.

Quoted 7 lines

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

Ben Greear

author

2011-02-10 18:00 UTC #5 lore raw

Quoted 74 lines · Helmut Schaa

Am Donnerstag, 10. Februar 2011 schrieb Ben Greear:
Quoted 73 lines · Helmut Schaa
Quoted 57 lines
Am Donnerstag, 10. Februar 2011 schrieb Ben Greear:
Quoted 56 lines
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);
	}
Quoted 7 lines
Quoted 1 line
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).

Quoted 4 lines

Quoted 2 lines
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

Quoted 2 lines

Helmut

Signature · 2 lines

Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com

David Miller

2011-02-10 19:00 UTC #10 lore raw

In reply to Helmut Schaa

From: Helmut Schaa <[email protected]>
Date: Thu, 10 Feb 2011 18:54:41 +0100

Quoted 1 line

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.

Felix Fietkau

2011-02-10 19:23 UTC #6 lore raw

In reply to Ben Greear

Quoted 80 lines · Ben Greear

Quoted 74 lines · Helmut Schaa
Am Donnerstag, 10. Februar 2011 schrieb Ben Greear:
Quoted 73 lines · Helmut Schaa
Quoted 57 lines
Am Donnerstag, 10. Februar 2011 schrieb Ben Greear:
Quoted 56 lines
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);
	}
Quoted 7 lines
Quoted 1 line
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).
Quoted 4 lines
Quoted 2 lines
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?

Quoted 7 lines

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

Ben Greear

author

2011-02-10 19:43 UTC #7 lore raw

Quoted 86 lines · Felix Fietkau

Quoted 85 lines · Ben Greear
Quoted 74 lines · Helmut Schaa
Am Donnerstag, 10. Februar 2011 schrieb Ben Greear:
Quoted 73 lines · Helmut Schaa
Quoted 57 lines
Am Donnerstag, 10. Februar 2011 schrieb Ben Greear:
Quoted 56 lines
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);
	}
Quoted 7 lines
Quoted 1 line
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).
Quoted 4 lines
Quoted 2 lines
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).

Quoted 5 lines

Quoted 2 lines
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

Signature · 2 lines

Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com

Felix Fietkau

2011-02-10 20:01 UTC #8 lore raw

Quoted 93 lines · Ben Greear

Quoted 86 lines · Felix Fietkau
Quoted 85 lines · Ben Greear
Quoted 74 lines · Helmut Schaa
Am Donnerstag, 10. Februar 2011 schrieb Ben Greear:
Quoted 73 lines · Helmut Schaa
Quoted 57 lines
Am Donnerstag, 10. Februar 2011 schrieb Ben Greear:
Quoted 56 lines
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);
	}
Quoted 7 lines
Quoted 1 line
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).
Quoted 4 lines
Quoted 2 lines
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).
Quoted 5 lines
Quoted 2 lines
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.

Quoted 5 lines

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

Helmut Schaa

2011-02-10 22:12 UTC #9 lore raw

In reply to Felix Fietkau

Am Donnerstag, 10. Februar 2011 schrieb Felix Fietkau:

Quoted 86 lines · Ben Greear

Quoted 85 lines · Helmut Schaa
Quoted 74 lines
Am Donnerstag, 10. Februar 2011 schrieb Ben Greear:
Quoted 73 lines · Helmut Schaa
Quoted 57 lines
Am Donnerstag, 10. Februar 2011 schrieb Ben Greear:
Quoted 56 lines
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);
	}
Quoted 7 lines
Quoted 1 line
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).
Quoted 4 lines
Quoted 2 lines
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).

Quoted 5 lines

Quoted 2 lines
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