* [PATCH 1/2] ath9k: Fix txq memory address printing in debugfs.
@ 2011-02-10 1:05 greearb
2011-02-10 1:05 ` [PATCH 2/2] mac80211: Set up tx-queue-mapping in subif_start_xmit greearb
0 siblings, 1 reply; 5+ messages in thread
From: greearb @ 2011-02-10 1:05 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear
From: Ben Greear <greearb@candelatech.com>
No use printing addresses of pointers, just print the
pointers themselves.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 e803b5c... 2cb42f9... M drivers/net/wireless/ath/ath9k/debug.c
drivers/net/wireless/ath/ath9k/debug.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index e803b5c..2cb42f9 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -549,10 +549,10 @@ static ssize_t read_file_xmit(struct file *file, char __user *user_buf,
PR("hw-tx-proc-desc: ", txprocdesc);
len += snprintf(buf + len, size - len,
"%s%11p%11p%10p%10p\n", "txq-memory-address:",
- &(sc->tx.txq_map[WME_AC_BE]),
- &(sc->tx.txq_map[WME_AC_BK]),
- &(sc->tx.txq_map[WME_AC_VI]),
- &(sc->tx.txq_map[WME_AC_VO]));
+ sc->tx.txq_map[WME_AC_BE],
+ sc->tx.txq_map[WME_AC_BK],
+ sc->tx.txq_map[WME_AC_VI],
+ sc->tx.txq_map[WME_AC_VO]);
if (len >= size)
goto done;
--
1.7.2.3
^ permalink raw reply related [flat|nested] 5+ messages in thread* [PATCH 2/2] mac80211: Set up tx-queue-mapping in subif_start_xmit.
2011-02-10 1:05 [PATCH 1/2] ath9k: Fix txq memory address printing in debugfs greearb
@ 2011-02-10 1:05 ` greearb
2011-02-10 1:15 ` Felix Fietkau
[not found] ` <23538c71c3504e4885f42f007d03016f@SINPRD0102HT006.apcprd01.prod.exchangelabs.com>
0 siblings, 2 replies; 5+ messages in thread
From: greearb @ 2011-02-10 1:05 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear
From: Ben Greear <greearb@candelatech.com>
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@candelatech.com>
---
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));
+
nh_pos += hdrlen;
h_pos += hdrlen;
--
1.7.2.3
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: [PATCH 2/2] mac80211: Set up tx-queue-mapping in subif_start_xmit.
2011-02-10 1:05 ` [PATCH 2/2] mac80211: Set up tx-queue-mapping in subif_start_xmit greearb
@ 2011-02-10 1:15 ` Felix Fietkau
2011-02-10 4:49 ` Ben Greear
[not found] ` <23538c71c3504e4885f42f007d03016f@SINPRD0102HT006.apcprd01.prod.exchangelabs.com>
1 sibling, 1 reply; 5+ messages in thread
From: Felix Fietkau @ 2011-02-10 1:15 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless
On 2011-02-10 2:05 AM, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> 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@candelatech.com>
> ---
>
> 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.
- Felix
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH 2/2] mac80211: Set up tx-queue-mapping in subif_start_xmit.
2011-02-10 1:15 ` Felix Fietkau
@ 2011-02-10 4:49 ` Ben Greear
0 siblings, 0 replies; 5+ messages in thread
From: Ben Greear @ 2011-02-10 4:49 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
On 02/09/2011 05:15 PM, Felix Fietkau wrote:
> On 2011-02-10 2:05 AM, greearb@candelatech.com wrote:
>> From: Ben Greear<greearb@candelatech.com>
>>
>> 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@candelatech.com>
>> ---
>>
>> 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@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <23538c71c3504e4885f42f007d03016f@SINPRD0102HT006.apcprd01.prod.exchangelabs.com>]
* RE: [PATCH 2/2] mac80211: Set up tx-queue-mapping in subif_start_xmit.
[not found] ` <23538c71c3504e4885f42f007d03016f@SINPRD0102HT006.apcprd01.prod.exchangelabs.com>
@ 2011-02-10 12:02 ` Sushil DUTT
0 siblings, 0 replies; 5+ messages in thread
From: Sushil DUTT @ 2011-02-10 12:02 UTC (permalink / raw)
To: 'Felix Fietkau', greearb@candelatech.com
Cc: linux-wireless@vger.kernel.org
Hi Felix,
I can also see some mismatch in ath9k hardware queue and mac80211 queue definition.
I am not very much expert on openwrt as I just started working with openwrt couple of months back but I can trace that data is sent to ath9k hw queue(q= skb_get_queue_mapping()) which is equal to mac80211 queue. Now problem is that mac80211 & ath9k queue priorities are reverse e.g. mac80211_q=0(AC_VO) is highest priority and ath9k hardware queue_0 is init as AC_BE(i.e. lowest priority).
Your help is appreciated.
Kind Regards,
Sushil
-----Original Message-----
From: linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-owner@vger.kernel.org] On Behalf Of Felix Fietkau
Sent: Thursday, 10 February 2011 9:15 AM
To: greearb@candelatech.com
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH 2/2] mac80211: Set up tx-queue-mapping in subif_start_xmit.
On 2011-02-10 2:05 AM, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> 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@candelatech.com>
> ---
>
> 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.
- Felix
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
This e-mail is confidential. If you are not the intended recipient you must not disclose or use the information contained within. If you have received it in error please return it to the sender via reply e-mail and delete any record of it from your system. The information contained within is not the opinion of Edith Cowan University in general and the University accepts no liability for the accuracy of the information provided.
CRICOS IPC 00279B
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-02-10 12:08 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-02-10 1:05 [PATCH 1/2] ath9k: Fix txq memory address printing in debugfs greearb
2011-02-10 1:05 ` [PATCH 2/2] mac80211: Set up tx-queue-mapping in subif_start_xmit greearb
2011-02-10 1:15 ` Felix Fietkau
2011-02-10 4:49 ` Ben Greear
[not found] ` <23538c71c3504e4885f42f007d03016f@SINPRD0102HT006.apcprd01.prod.exchangelabs.com>
2011-02-10 12:02 ` Sushil DUTT
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox