2011-02-10 01:05:57

by Ben Greear

[permalink] [raw]
Subject: [PATCH 1/2] ath9k: Fix txq memory address printing in debugfs.

From: Ben Greear <[email protected]>

No use printing addresses of pointers, just print the
pointers themselves.

Signed-off-by: Ben Greear <[email protected]>
---
: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



2011-02-10 04:49:41

by Ben Greear

[permalink] [raw]
Subject: Re: [PATCH 2/2] mac80211: Set up tx-queue-mapping in subif_start_xmit.

On 02/09/2011 05:15 PM, Felix Fietkau wrote:
> On 2011-02-10 2:05 AM, [email protected] wrote:
>> From: Ben Greear<[email protected]>
>>
>> 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<[email protected]>
>> ---
>>
>> 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 <[email protected]>
Candela Technologies Inc http://www.candelatech.com

2011-02-10 01:15:24

by Felix Fietkau

[permalink] [raw]
Subject: Re: [PATCH 2/2] mac80211: Set up tx-queue-mapping in subif_start_xmit.

On 2011-02-10 2:05 AM, [email protected] wrote:
> From: Ben Greear <[email protected]>
>
> 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 <[email protected]>
> ---
>
> 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

2011-02-10 01:06:14

by Ben Greear

[permalink] [raw]
Subject: [PATCH 2/2] mac80211: Set up tx-queue-mapping in subif_start_xmit.

From: Ben Greear <[email protected]>

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 <[email protected]>
---

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