* Re: [.32-rc3] scheduler: iwlagn consistently high in "waiting for CPU"
From: Peter Zijlstra @ 2009-10-09 8:06 UTC (permalink / raw)
To: Sedat Dilek
Cc: Mike Galbraith, Frans Pop, Arjan van de Ven,
Linux Kernel Mailing List, Ingo Molnar, linux-wireless
In-Reply-To: <2d0a357f0910090055v7a454ca5rb895fecbb9747ecd@mail.gmail.com>
On Fri, 2009-10-09 at 09:55 +0200, Sedat Dilek wrote:
>
> will you (re)send this patch as a new one with correct subject line to LKML?
> Otherwise, it might disapper in this long thread.
No need, I've got it.
^ permalink raw reply
* Re: [.32-rc3] scheduler: iwlagn consistently high in "waiting for CPU"
From: Sedat Dilek @ 2009-10-09 7:55 UTC (permalink / raw)
To: Mike Galbraith
Cc: Frans Pop, Arjan van de Ven, Linux Kernel Mailing List,
Ingo Molnar, Peter Zijlstra, linux-wireless
In-Reply-To: <1255070103.7639.30.camel@marge.simson.net>
Hi Mike,
will you (re)send this patch as a new one with correct subject line to LKML?
Otherwise, it might disapper in this long thread.
Kind Regards,
- Sedat -
On Fri, Oct 9, 2009 at 8:35 AM, Mike Galbraith <efault@gmx.de> wrote:
> On Thu, 2009-10-08 at 22:59 +0200, Frans Pop wrote:
>> On Thursday 08 October 2009, Mike Galbraith wrote:
>> > I still see very high latencies coming out of idle (last noted was >
>> > 300ms, NO_HZ) with this patch,
>> >
>> > Like this:
>> >
>> > Cause Maximum Percentage
>> > Scheduler: waiting for cpu 604.2 msec 49.0 %
>>
>> I'm not seeing anything even remotely like that.
>
> Instrumenting, I saw (stale) clock deltas of >900ms coming out of idle,
> delta being the difference between rq->clock when we hit update_curr()
> and discover that this queue was idle, and what the clock will be an
> instant or two later when somebody winds the clock.
>
> I've been watching latencytop for a while now to make sure latency is
> really dead. I see no twitching, so...
>
> sched: update the clock of runqueue select_task_rq() selected.
>
> In try_to_wake_up(), we update the runqueue clock, but select_task_rq()
> may select a different runqueue than the one we updated, leaving the new
> runqueue's clock stale for a bit.
>
> This patch cures occasional huge latencies reported by latencytop when
> coming out of idle on a mostly idle NO_HZ box.
>
> Signed-off-by: Mike Galbraith <efault@gmx.de>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> LKML-Reference: <new-submission>
>
> ---
> kernel/sched.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> Index: linux-2.6/kernel/sched.c
> ===================================================================
> --- linux-2.6.orig/kernel/sched.c
> +++ linux-2.6/kernel/sched.c
> @@ -2311,7 +2311,7 @@ static int try_to_wake_up(struct task_st
> {
> int cpu, orig_cpu, this_cpu, success = 0;
> unsigned long flags;
> - struct rq *rq;
> + struct rq *rq, *orig_rq;
>
> if (!sched_feat(SYNC_WAKEUPS))
> wake_flags &= ~WF_SYNC;
> @@ -2319,7 +2319,7 @@ static int try_to_wake_up(struct task_st
> this_cpu = get_cpu();
>
> smp_wmb();
> - rq = task_rq_lock(p, &flags);
> + rq = orig_rq = task_rq_lock(p, &flags);
> update_rq_clock(rq);
> if (!(p->state & state))
> goto out;
> @@ -2350,6 +2350,10 @@ static int try_to_wake_up(struct task_st
> set_task_cpu(p, cpu);
>
> rq = task_rq_lock(p, &flags);
> +
> + if (rq != orig_rq)
> + update_rq_clock(rq);
> +
> WARN_ON(p->state != TASK_WAKING);
> cpu = task_cpu(p);
>
>
>
> --
> 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
>
^ permalink raw reply
* Re: [PATCH] libertas: remove double assignment of dev->netdev_ops
From: Holger Schurig @ 2009-10-09 7:22 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless
In-Reply-To: <1255034769-18882-1-git-send-email-lrodriguez@atheros.com>
On Thursday 08 October 2009 22:46:09 Luis R. Rodriguez wrote:
> - dev->netdev_ops = &lbs_netdev_ops;
Acked-by: Holger Schurig <hs4233@mail.mn-solutions.de>
--
http://www.holgerschurig.de
^ permalink raw reply
* [PATCH] libertas: depend on CONFIG_CFG80211
From: Holger Schurig @ 2009-10-09 7:10 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: John W Linville, Dan Williams, linux-wireless
Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
---
Fixes bug noted by Stephen Rothwell:
> On Wed, 7 Oct 2009 17:35:17 +1100 Stephen Rothwell wrote:
>
> > Hi all,
> >
> > Changes since 20091006:
>
>
> drivers/built-in.o: In function `lbs_cfg_free':
> (.text+0x3479e0): undefined reference to `wiphy_unregister'
> drivers/built-in.o: In function `lbs_cfg_free':
> (.text+0x3479e7): undefined reference to `wiphy_free'
> drivers/built-in.o: In function `lbs_cfg_register':
> (.text+0x347a52): undefined reference to `wiphy_register'
> drivers/built-in.o: In function `lbs_cfg_alloc':
> (.text+0x347acf): undefined reference to `wiphy_new'
Index: linux-wl/drivers/net/wireless/libertas/Kconfig
===================================================================
--- linux-wl.orig/drivers/net/wireless/libertas/Kconfig 2009-10-09 08:00:03.000000000 +0200
+++ linux-wl/drivers/net/wireless/libertas/Kconfig 2009-10-09 08:00:27.000000000 +0200
@@ -1,6 +1,6 @@
config LIBERTAS
tristate "Marvell 8xxx Libertas WLAN driver support"
- depends on WLAN_80211
+ depends on WLAN_80211 && CFG80211
select WIRELESS_EXT
select WEXT_SPY
select LIB80211
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [.32-rc3] scheduler: iwlagn consistently high in "waiting for CPU"
From: Peter Zijlstra @ 2009-10-09 7:13 UTC (permalink / raw)
To: Mike Galbraith
Cc: Frans Pop, Arjan van de Ven, Linux Kernel Mailing List,
Ingo Molnar, linux-wireless
In-Reply-To: <1255070103.7639.30.camel@marge.simson.net>
On Fri, 2009-10-09 at 08:35 +0200, Mike Galbraith wrote:
>
> sched: update the clock of runqueue select_task_rq() selected.
>
> In try_to_wake_up(), we update the runqueue clock, but select_task_rq()
> may select a different runqueue than the one we updated, leaving the new
> runqueue's clock stale for a bit.
>
> This patch cures occasional huge latencies reported by latencytop when
> coming out of idle on a mostly idle NO_HZ box.
>
> Signed-off-by: Mike Galbraith <efault@gmx.de>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Awesome catch Mike, seems I goofed up in my recent ttwu changes.
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
>
> ---
> kernel/sched.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> Index: linux-2.6/kernel/sched.c
> ===================================================================
> --- linux-2.6.orig/kernel/sched.c
> +++ linux-2.6/kernel/sched.c
> @@ -2311,7 +2311,7 @@ static int try_to_wake_up(struct task_st
> {
> int cpu, orig_cpu, this_cpu, success = 0;
> unsigned long flags;
> - struct rq *rq;
> + struct rq *rq, *orig_rq;
>
> if (!sched_feat(SYNC_WAKEUPS))
> wake_flags &= ~WF_SYNC;
> @@ -2319,7 +2319,7 @@ static int try_to_wake_up(struct task_st
> this_cpu = get_cpu();
>
> smp_wmb();
> - rq = task_rq_lock(p, &flags);
> + rq = orig_rq = task_rq_lock(p, &flags);
> update_rq_clock(rq);
> if (!(p->state & state))
> goto out;
> @@ -2350,6 +2350,10 @@ static int try_to_wake_up(struct task_st
> set_task_cpu(p, cpu);
>
> rq = task_rq_lock(p, &flags);
> +
> + if (rq != orig_rq)
> + update_rq_clock(rq);
> +
> WARN_ON(p->state != TASK_WAKING);
> cpu = task_cpu(p);
>
>
>
>
^ permalink raw reply
* Re: [.32-rc3] scheduler: iwlagn consistently high in "waiting for CPU"
From: Mike Galbraith @ 2009-10-09 6:35 UTC (permalink / raw)
To: Frans Pop
Cc: Arjan van de Ven, Linux Kernel Mailing List, Ingo Molnar,
Peter Zijlstra, linux-wireless
In-Reply-To: <200910082259.35204.elendil@planet.nl>
On Thu, 2009-10-08 at 22:59 +0200, Frans Pop wrote:
> On Thursday 08 October 2009, Mike Galbraith wrote:
> > I still see very high latencies coming out of idle (last noted was >
> > 300ms, NO_HZ) with this patch,
> >
> > Like this:
> >
> > Cause Maximum Percentage
> > Scheduler: waiting for cpu 604.2 msec 49.0 %
>
> I'm not seeing anything even remotely like that.
Instrumenting, I saw (stale) clock deltas of >900ms coming out of idle,
delta being the difference between rq->clock when we hit update_curr()
and discover that this queue was idle, and what the clock will be an
instant or two later when somebody winds the clock.
I've been watching latencytop for a while now to make sure latency is
really dead. I see no twitching, so...
sched: update the clock of runqueue select_task_rq() selected.
In try_to_wake_up(), we update the runqueue clock, but select_task_rq()
may select a different runqueue than the one we updated, leaving the new
runqueue's clock stale for a bit.
This patch cures occasional huge latencies reported by latencytop when
coming out of idle on a mostly idle NO_HZ box.
Signed-off-by: Mike Galbraith <efault@gmx.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
---
kernel/sched.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
Index: linux-2.6/kernel/sched.c
===================================================================
--- linux-2.6.orig/kernel/sched.c
+++ linux-2.6/kernel/sched.c
@@ -2311,7 +2311,7 @@ static int try_to_wake_up(struct task_st
{
int cpu, orig_cpu, this_cpu, success = 0;
unsigned long flags;
- struct rq *rq;
+ struct rq *rq, *orig_rq;
if (!sched_feat(SYNC_WAKEUPS))
wake_flags &= ~WF_SYNC;
@@ -2319,7 +2319,7 @@ static int try_to_wake_up(struct task_st
this_cpu = get_cpu();
smp_wmb();
- rq = task_rq_lock(p, &flags);
+ rq = orig_rq = task_rq_lock(p, &flags);
update_rq_clock(rq);
if (!(p->state & state))
goto out;
@@ -2350,6 +2350,10 @@ static int try_to_wake_up(struct task_st
set_task_cpu(p, cpu);
rq = task_rq_lock(p, &flags);
+
+ if (rq != orig_rq)
+ update_rq_clock(rq);
+
WARN_ON(p->state != TASK_WAKING);
cpu = task_cpu(p);
^ permalink raw reply
* [PATCH] ath9k: Fix TX hang poll routine
From: Sujith @ 2009-10-09 4:21 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
When TX is hung, the chip is reset. Ensure that
the chip is awake by using the PS wrappers.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/xmit.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index a8620b1..2a4efcb 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2079,7 +2079,9 @@ static void ath_tx_complete_poll_work(struct work_struct *work)
if (needreset) {
ath_print(ath9k_hw_common(sc->sc_ah), ATH_DBG_RESET,
"tx hung, resetting the chip\n");
+ ath9k_ps_wakeup(sc);
ath_reset(sc, false);
+ ath9k_ps_restore(sc);
}
ieee80211_queue_delayed_work(sc->hw, &sc->tx_complete_work,
--
1.6.4.4
^ permalink raw reply related
* Re: [.32-rc3] scheduler: iwlagn consistently high in "waiting for CPU"
From: Markus Trippelsdorf @ 2009-10-09 3:51 UTC (permalink / raw)
To: Mike Galbraith
Cc: Frans Pop, Arjan van de Ven, Linux Kernel Mailing List,
Ingo Molnar, Peter Zijlstra, linux-wireless
In-Reply-To: <1255059318.7236.13.camel@marge.simson.net>
On Fri, Oct 09, 2009 at 05:35:18AM +0200, Mike Galbraith wrote:
> On Thu, 2009-10-08 at 22:34 +0200, Markus Trippelsdorf wrote:
> > On Thu, Oct 08, 2009 at 08:23:37PM +0200, Mike Galbraith wrote:
> > > On Thu, 2009-10-08 at 16:55 +0200, Frans Pop wrote:
> > > > On Thursday 08 October 2009, Arjan van de Ven wrote:
> > > > > From: Arjan van de Ven <arjan@linux.intel.com>
> > > > > Date: Thu, 24 Sep 2009 13:24:16 +0200
> > > > > Subject: [PATCH] x86, timers: check for pending timers after (device)
> > > > > interrupts
> > > > >
> > > > > Now that range timers and deferred timers are common, I found a
> > > > > problem with these using the "perf timechart" tool.
> > > > >
> > > > > It turns out that on x86, these two 'opportunistic' timers only
> > > > > get checked when another "real" timer happens.
> > > > > These opportunistic timers have the objective to save power by
> > > > > hitchhiking on other wakeups, as to avoid CPU wakeups by themselves
> > > > > as much as possible.
> > > >
> > > > This patch makes quite a difference for me. iwlagn and phy0 now
> > > > consistently show at ~10 ms or lower.
> > > >
> > > > I do still get occasional high latencies, but those are for things like
> > > > "[rpc_wait_bit_killable]" or "Writing a page to disk", where I guess you'd
> > > > expect them. Those high latencies are mostly only listed for "Global" and
> > > > don't translate to individual processes.
> > >
> > > I still see very high latencies coming out of idle (last noted was >
> > > 300ms, NO_HZ) with this patch, and wonder if the hunk below makes any
> > > difference whatsoever for you. Here, it definitely does. (shouldn't)
> >
> > I'm also seeing these strange, very high latencies here. Your patch
> > didn't help unfortunately.
> >
> > This is from an otherwise idle NO_NZ system:
> >
> > # ./perf sched latency
> >
> > -----------------------------------------------------------------------------------------
> > Task | Runtime ms | Switches | Average delay ms | Maximum delay ms |
> > -----------------------------------------------------------------------------------------
> > ksoftirqd/0:4 | 2.216 ms | 170 | avg: 24.235 ms | max: 808.356 ms |
> > ksoftirqd/1:6 | 2.611 ms | 205 | avg: 4.334 ms | max: 165.553 ms |
> > migration/2:7 | 0.000 ms | 1 | avg: 3.060 ms | max: 3.060 ms |
> >
> > With latencytop the ksoftirqd latency is over 1 sec frequently. (Could be
> > ondemand CPUfreq governor related?)
>
> That's a separate issue, which Arjan was nice enough to fix for me. He
> even wrote the changelog, and used my mouse to do so ;-)
>
>
> Repeatable. Apply patchlet, and the numbers below become repeatable.
>
> perf_counter tools: make perf sched pass -F 0 to record
>
> Commit 42e59d7d19dc4b4 introduced a sample frequency framework..
> .. however it unfortunately changed how perf events get recorded,
> and caused sched to miss events.
>
> This patch causes the sched code to use -F 0 to not use the
> new framework when recording sched data.
Yes, your're right. With this patch applied perf sched latency is back
to normal.
--
Markus
^ permalink raw reply
* Re: [.32-rc3] scheduler: iwlagn consistently high in "waiting for CPU"
From: Mike Galbraith @ 2009-10-09 3:35 UTC (permalink / raw)
To: Markus Trippelsdorf
Cc: Frans Pop, Arjan van de Ven, Linux Kernel Mailing List,
Ingo Molnar, Peter Zijlstra, linux-wireless
In-Reply-To: <20091008203426.GA1946@phenom2.trippelsdorf.de>
On Thu, 2009-10-08 at 22:34 +0200, Markus Trippelsdorf wrote:
> On Thu, Oct 08, 2009 at 08:23:37PM +0200, Mike Galbraith wrote:
> > On Thu, 2009-10-08 at 16:55 +0200, Frans Pop wrote:
> > > On Thursday 08 October 2009, Arjan van de Ven wrote:
> > > > From: Arjan van de Ven <arjan@linux.intel.com>
> > > > Date: Thu, 24 Sep 2009 13:24:16 +0200
> > > > Subject: [PATCH] x86, timers: check for pending timers after (device)
> > > > interrupts
> > > >
> > > > Now that range timers and deferred timers are common, I found a
> > > > problem with these using the "perf timechart" tool.
> > > >
> > > > It turns out that on x86, these two 'opportunistic' timers only
> > > > get checked when another "real" timer happens.
> > > > These opportunistic timers have the objective to save power by
> > > > hitchhiking on other wakeups, as to avoid CPU wakeups by themselves
> > > > as much as possible.
> > >
> > > This patch makes quite a difference for me. iwlagn and phy0 now
> > > consistently show at ~10 ms or lower.
> > >
> > > I do still get occasional high latencies, but those are for things like
> > > "[rpc_wait_bit_killable]" or "Writing a page to disk", where I guess you'd
> > > expect them. Those high latencies are mostly only listed for "Global" and
> > > don't translate to individual processes.
> >
> > I still see very high latencies coming out of idle (last noted was >
> > 300ms, NO_HZ) with this patch, and wonder if the hunk below makes any
> > difference whatsoever for you. Here, it definitely does. (shouldn't)
>
> I'm also seeing these strange, very high latencies here. Your patch
> didn't help unfortunately.
>
> This is from an otherwise idle NO_NZ system:
>
> # ./perf sched latency
>
> -----------------------------------------------------------------------------------------
> Task | Runtime ms | Switches | Average delay ms | Maximum delay ms |
> -----------------------------------------------------------------------------------------
> ksoftirqd/0:4 | 2.216 ms | 170 | avg: 24.235 ms | max: 808.356 ms |
> ksoftirqd/1:6 | 2.611 ms | 205 | avg: 4.334 ms | max: 165.553 ms |
> migration/2:7 | 0.000 ms | 1 | avg: 3.060 ms | max: 3.060 ms |
>
> With latencytop the ksoftirqd latency is over 1 sec frequently. (Could be
> ondemand CPUfreq governor related?)
That's a separate issue, which Arjan was nice enough to fix for me. He
even wrote the changelog, and used my mouse to do so ;-)
Watch.
Virgin tip pulled this morning, perf sched record sleep 1 on idle box.
-----------------------------------------------------------------------------------------
Task | Runtime ms | Switches | Average delay ms | Maximum delay ms |
-----------------------------------------------------------------------------------------
kicker:5845 | 0.000 ms | 1 | avg: 999.406 ms | max: 999.406 ms |
rt2870TimerQHan:4952 | 0.008 ms | 3 | avg: 0.087 ms | max: 0.131 ms |
Xorg:4913 | 0.099 ms | 2 | avg: 0.027 ms | max: 0.044 ms |
kondemand/3:3106 | 0.014 ms | 2 | avg: 0.013 ms | max: 0.018 ms |
perf:7229 | 3.986 ms | 1 | avg: 0.017 ms | max: 0.017 ms |
events/3:14 | 0.038 ms | 1 | avg: 0.017 ms | max: 0.017 ms |
kondemand/2:3105 | 0.017 ms | 1 | avg: 0.008 ms | max: 0.008 ms |
kondemand/1:3104 | 0.041 ms | 1 | avg: 0.007 ms | max: 0.007 ms |
konsole:5855 | 0.362 ms | 3 | avg: 0.004 ms | max: 0.006 ms |
kondemand/0:3103 | 0.000 ms | 1 | avg: 0.000 ms | max: 0.000 ms |
-----------------------------------------------------------------------------------------
TOTAL: | 4.565 ms | 16 |
---------------------------------------------------
INFO: 40.741% state machine bugs (11 out of 27)
INFO: 51.852% context switch bugs (14 out of 27)
Repeatable. Apply patchlet, and the numbers below become repeatable.
perf_counter tools: make perf sched pass -F 0 to record
Commit 42e59d7d19dc4b4 introduced a sample frequency framework..
.. however it unfortunately changed how perf events get recorded,
and caused sched to miss events.
This patch causes the sched code to use -F 0 to not use the
new framework when recording sched data.
Signed-off-by: Mike Galbraith <efault@gmx.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Arjan The Wise <arjan@linux.intel.com>
LKML-Reference: <new-submission>
---
tools/perf/builtin-sched.c | 1 +
1 file changed, 1 insertion(+)
Index: linux-2.6/tools/perf/builtin-sched.c
===================================================================
--- linux-2.6.orig/tools/perf/builtin-sched.c
+++ linux-2.6/tools/perf/builtin-sched.c
@@ -1902,6 +1902,7 @@ static const char *record_args[] = {
"-f",
"-m", "1024",
"-c", "1",
+ "-F", "0",
"-e", "sched:sched_switch:r",
"-e", "sched:sched_stat_wait:r",
"-e", "sched:sched_stat_sleep:r",
-----------------------------------------------------------------------------------------
Task | Runtime ms | Switches | Average delay ms | Maximum delay ms |
-----------------------------------------------------------------------------------------
Xorg:4913 | 2.296 ms | 43 | avg: 0.075 ms | max: 0.686 ms |
kicker:5845 | 3.106 ms | 28 | avg: 0.017 ms | max: 0.307 ms |
perf:7419 | 147.147 ms | 16 | avg: 0.028 ms | max: 0.261 ms |
klipper:6404 | 0.035 ms | 1 | avg: 0.256 ms | max: 0.256 ms |
kondemand/3:3106 | 0.139 ms | 18 | avg: 0.039 ms | max: 0.192 ms |
rt2870TimerQHan:4952 | 0.726 ms | 107 | avg: 0.010 ms | max: 0.165 ms |
konsole:5856 | 0.180 ms | 2 | avg: 0.050 ms | max: 0.094 ms |
kded:5831 | 0.044 ms | 1 | avg: 0.055 ms | max: 0.055 ms |
events/3:14 | 0.066 ms | 3 | avg: 0.018 ms | max: 0.031 ms |
kondemand/2:3105 | 0.015 ms | 2 | avg: 0.020 ms | max: 0.029 ms |
ksoftirqd/3:10 | 0.326 ms | 3 | avg: 0.018 ms | max: 0.027 ms |
kondemand/1:3104 | 0.142 ms | 24 | avg: 0.008 ms | max: 0.023 ms |
rt2870MlmeThrea:4950 | 0.095 ms | 13 | avg: 0.012 ms | max: 0.022 ms |
kondemand/0:3103 | 0.259 ms | 36 | avg: 0.013 ms | max: 0.020 ms |
kwin:5841 | 0.038 ms | 1 | avg: 0.018 ms | max: 0.018 ms |
sync_supers:92 | 0.008 ms | 1 | avg: 0.018 ms | max: 0.018 ms |
events/0:11 | 0.005 ms | 1 | avg: 0.015 ms | max: 0.015 ms |
konsole:5855 | 0.709 ms | 10 | avg: 0.007 ms | max: 0.013 ms |
events/2:13 | 0.009 ms | 1 | avg: 0.011 ms | max: 0.011 ms |
events/1:12 | 0.006 ms | 1 | avg: 0.010 ms | max: 0.010 ms |
mysqld:5030 | 0.185 ms | 1 | avg: 0.009 ms | max: 0.009 ms |
hald-addon-inpu:3191 | 0.006 ms | 1 | avg: 0.006 ms | max: 0.006 ms |
mono:6472 | 0.144 ms | 11 | avg: 0.005 ms | max: 0.006 ms |
ntpd:6020 | 0.030 ms | 1 | avg: 0.005 ms | max: 0.005 ms |
gpg-agent:5783 | 0.047 ms | 1 | avg: 0.005 ms | max: 0.005 ms |
sleep:7420 | 0.973 ms | 2 | avg: 0.003 ms | max: 0.005 ms |
httpd2-prefork:6416 | 0.013 ms | 1 | avg: 0.005 ms | max: 0.005 ms |
mysqld:5031 | 0.172 ms | 1 | avg: 0.005 ms | max: 0.005 ms |
kwrapper:5838 | 0.010 ms | 1 | avg: 0.005 ms | max: 0.005 ms |
-----------------------------------------------------------------------------------------
TOTAL: | 156.930 ms | 332 |
---------------------------------------------------
^ permalink raw reply
* Re: [.32-rc3] scheduler: iwlagn consistently high in "waiting for CPU"
From: Mike Galbraith @ 2009-10-09 3:04 UTC (permalink / raw)
To: Frans Pop
Cc: Arjan van de Ven, Linux Kernel Mailing List, Ingo Molnar,
Peter Zijlstra, linux-wireless
In-Reply-To: <200910082259.35204.elendil@planet.nl>
On Thu, 2009-10-08 at 22:59 +0200, Frans Pop wrote:
> On Thursday 08 October 2009, Mike Galbraith wrote:
> > I still see very high latencies coming out of idle (last noted was >
> > 300ms, NO_HZ) with this patch,
> >
> > Like this:
> >
> > Cause Maximum Percentage
> > Scheduler: waiting for cpu 604.2 msec 49.0 %
>
> I'm not seeing anything even remotely like that.
>
> I've tried quieting the system down as much as possible, but that made
> no difference. I do have NO_HZ set; will send my full config privately.
>
> If you'd still like me to try your patch I will, but I'm not sure if
> that has much value.
No, if you watch for a bit with box mostly idle, and don't see > 100ms
hits occasionally, testing patchlet is likely a waste of time. To get
one like the above, I have to hold my tongue just right ;-) they're not
common.
-Mike
^ permalink raw reply
* [PATCH] libertas: Check return status of command functions
From: Bing Zhao @ 2009-10-09 2:38 UTC (permalink / raw)
To: libertas-dev; +Cc: linux-wireless, Bing Zhao, Amitkumar Karwar
From: Amitkumar Karwar <akarwar@marvell.com>
Return status of lbs_prepare_and_send_command and lbs_cmd_with_response
functions is not checked at some places. Those checks are added.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/libertas/debugfs.c | 27 ++++++++++++++++++---------
drivers/net/wireless/libertas/main.c | 2 ++
drivers/net/wireless/libertas/scan.c | 11 +++++++----
drivers/net/wireless/libertas/wext.c | 10 +++++++---
4 files changed, 34 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/libertas/debugfs.c b/drivers/net/wireless/libertas/debugfs.c
index 893a55c..587b0cb 100644
--- a/drivers/net/wireless/libertas/debugfs.c
+++ b/drivers/net/wireless/libertas/debugfs.c
@@ -451,10 +451,12 @@ static ssize_t lbs_rdmac_read(struct file *file, char __user *userbuf,
CMD_MAC_REG_ACCESS, 0,
CMD_OPTION_WAITFORRSP, 0, &offval);
mdelay(10);
- pos += snprintf(buf+pos, len-pos, "MAC[0x%x] = 0x%08x\n",
+ if (!ret) {
+ pos += snprintf(buf+pos, len-pos, "MAC[0x%x] = 0x%08x\n",
priv->mac_offset, priv->offsetvalue.value);
- ret = simple_read_from_buffer(userbuf, count, ppos, buf, pos);
+ ret = simple_read_from_buffer(userbuf, count, ppos, buf, pos);
+ }
free_page(addr);
return ret;
}
@@ -514,7 +516,8 @@ static ssize_t lbs_wrmac_write(struct file *file,
CMD_OPTION_WAITFORRSP, 0, &offval);
mdelay(10);
- res = count;
+ if (!res)
+ res = count;
out_unlock:
free_page(addr);
return res;
@@ -539,10 +542,12 @@ static ssize_t lbs_rdbbp_read(struct file *file, char __user *userbuf,
CMD_BBP_REG_ACCESS, 0,
CMD_OPTION_WAITFORRSP, 0, &offval);
mdelay(10);
- pos += snprintf(buf+pos, len-pos, "BBP[0x%x] = 0x%08x\n",
+ if (!ret) {
+ pos += snprintf(buf+pos, len-pos, "BBP[0x%x] = 0x%08x\n",
priv->bbp_offset, priv->offsetvalue.value);
- ret = simple_read_from_buffer(userbuf, count, ppos, buf, pos);
+ ret = simple_read_from_buffer(userbuf, count, ppos, buf, pos);
+ }
free_page(addr);
return ret;
@@ -603,7 +608,8 @@ static ssize_t lbs_wrbbp_write(struct file *file,
CMD_OPTION_WAITFORRSP, 0, &offval);
mdelay(10);
- res = count;
+ if (!res)
+ res = count;
out_unlock:
free_page(addr);
return res;
@@ -628,10 +634,12 @@ static ssize_t lbs_rdrf_read(struct file *file, char __user *userbuf,
CMD_RF_REG_ACCESS, 0,
CMD_OPTION_WAITFORRSP, 0, &offval);
mdelay(10);
- pos += snprintf(buf+pos, len-pos, "RF[0x%x] = 0x%08x\n",
+ if (!ret) {
+ pos += snprintf(buf+pos, len-pos, "RF[0x%x] = 0x%08x\n",
priv->rf_offset, priv->offsetvalue.value);
- ret = simple_read_from_buffer(userbuf, count, ppos, buf, pos);
+ ret = simple_read_from_buffer(userbuf, count, ppos, buf, pos);
+ }
free_page(addr);
return ret;
@@ -692,7 +700,8 @@ static ssize_t lbs_wrrf_write(struct file *file,
CMD_OPTION_WAITFORRSP, 0, &offval);
mdelay(10);
- res = count;
+ if (!res)
+ res = count;
out_unlock:
free_page(addr);
return res;
diff --git a/drivers/net/wireless/libertas/main.c b/drivers/net/wireless/libertas/main.c
index 3b14fcc..bce752c 100644
--- a/drivers/net/wireless/libertas/main.c
+++ b/drivers/net/wireless/libertas/main.c
@@ -1087,6 +1087,8 @@ static void auto_deepsleep_timer_fn(unsigned long data)
ret = lbs_prepare_and_send_command(priv,
CMD_802_11_DEEP_SLEEP, 0,
0, 0, NULL);
+ if (ret)
+ lbs_pr_err("Enter Deep Sleep command failed\n");
}
}
mod_timer(&priv->auto_deepsleep_timer , jiffies +
diff --git a/drivers/net/wireless/libertas/scan.c b/drivers/net/wireless/libertas/scan.c
index 6c95af3..d8fc2b8 100644
--- a/drivers/net/wireless/libertas/scan.c
+++ b/drivers/net/wireless/libertas/scan.c
@@ -1022,9 +1022,12 @@ int lbs_get_scan(struct net_device *dev, struct iw_request_info *info,
return -EAGAIN;
/* Update RSSI if current BSS is a locally created ad-hoc BSS */
- if ((priv->mode == IW_MODE_ADHOC) && priv->adhoccreate)
- lbs_prepare_and_send_command(priv, CMD_802_11_RSSI, 0,
- CMD_OPTION_WAITFORRSP, 0, NULL);
+ if ((priv->mode == IW_MODE_ADHOC) && priv->adhoccreate) {
+ err = lbs_prepare_and_send_command(priv, CMD_802_11_RSSI, 0,
+ CMD_OPTION_WAITFORRSP, 0, NULL);
+ if (err)
+ goto out;
+ }
mutex_lock(&priv->lock);
list_for_each_entry_safe (iter_bss, safe, &priv->network_list, list) {
@@ -1058,7 +1061,7 @@ int lbs_get_scan(struct net_device *dev, struct iw_request_info *info,
dwrq->length = (ev - extra);
dwrq->flags = 0;
-
+out:
lbs_deb_leave_args(LBS_DEB_WEXT, "ret %d", err);
return err;
}
diff --git a/drivers/net/wireless/libertas/wext.c b/drivers/net/wireless/libertas/wext.c
index 69dd19b..4594841 100644
--- a/drivers/net/wireless/libertas/wext.c
+++ b/drivers/net/wireless/libertas/wext.c
@@ -832,7 +832,7 @@ static struct iw_statistics *lbs_get_wireless_stats(struct net_device *dev)
u32 rssi_qual;
u32 tx_qual;
u32 quality = 0;
- int stats_valid = 0;
+ int ret, stats_valid = 0;
u8 rssi;
u32 tx_retries;
struct cmd_ds_802_11_get_log log;
@@ -881,7 +881,9 @@ static struct iw_statistics *lbs_get_wireless_stats(struct net_device *dev)
memset(&log, 0, sizeof(log));
log.hdr.size = cpu_to_le16(sizeof(log));
- lbs_cmd_with_response(priv, CMD_802_11_GET_LOG, &log);
+ ret = lbs_cmd_with_response(priv, CMD_802_11_GET_LOG, &log);
+ if (ret)
+ goto out;
tx_retries = le32_to_cpu(log.retry);
@@ -909,8 +911,10 @@ static struct iw_statistics *lbs_get_wireless_stats(struct net_device *dev)
stats_valid = 1;
/* update stats asynchronously for future calls */
- lbs_prepare_and_send_command(priv, CMD_802_11_RSSI, 0,
+ ret = lbs_prepare_and_send_command(priv, CMD_802_11_RSSI, 0,
0, 0, NULL);
+ if (ret)
+ lbs_pr_err("RSSI command failed\n");
out:
if (!stats_valid) {
priv->wstats.miss.beacon = 0;
--
1.5.4.3
^ permalink raw reply related
* Re: pull request: wireless-2.6 2009-10-08
From: David Miller @ 2009-10-09 1:01 UTC (permalink / raw)
To: mb; +Cc: linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <200910090108.08838.mb@bu3sch.de>
From: Michael Buesch <mb@bu3sch.de>
Date: Fri, 9 Oct 2009 01:08:06 +0200
> I was planning to do a better solution, but I didn't have the time, yet.
The change is harmless while we're twiddling our thumbs waiting
for you to implement the fix "properly."
Not having the fix in is a developer burdon because people turn
on the DMA API debugger and are going to keep reporting it's
complaints here and elsewhere.
Get over your Napoleon complex, and let reasonable working fixes
get into the tree even if you don't find them optimal. You can
always improve them later, "when you get around to it."
People put fixes in without my ACK in my areas of expertiece all
the time. I got over it a long time ago, it's OK, and not worth
stressing out over.
Thanks.
^ permalink raw reply
* Re: pull request: wireless-2.6 2009-10-08
From: David Miller @ 2009-10-09 0:55 UTC (permalink / raw)
To: mb; +Cc: linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <200910090116.46513.mb@bu3sch.de>
From: Michael Buesch <mb@bu3sch.de>
Date: Fri, 9 Oct 2009 01:16:44 +0200
> And there's no reason to rush this fix into mainline.
I think it's worthwhile because people turn the DMA API debugger on
and it's going to spit out warnings that "don't matter" until you guys
fix this.
I looked at the patch you guys are so up in arms about, and frankly it
looks perfectly fine to me.
If you want to implement the fix "perfectly", and "to your standards",
then fine. But do it in net-next-2.6 as a follow-on patch to this
one.
I'm not undoing John's pull request just for this. :-)
^ permalink raw reply
* Re: pull request: wireless-2.6 2009-10-08
From: David Miller @ 2009-10-09 0:52 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20091008223454.GB2798@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 8 Oct 2009 18:34:54 -0400
> Here is another batch of fixes intended for 2.6.32. Most of them are
> short, self-contained and more-or-less obvious. Most of them have been
> baking in -next for several days.
>
> The b43 patch from Albert Herranz looks big, but most of it is moving a
> structure definition within a header file. It also changes some DMA
> buffers from stack to heap allocation.
>
> Please let me know if there are problems!
Pulled, thanks a lot John!
^ permalink raw reply
* Re: NULL pointer deref at wext ioctl (Re: [PATCH] compat-2.6: adding ethtool.h to compat-2.6.31.h)
From: Luis R. Rodriguez @ 2009-10-09 0:14 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: Johannes Berg, John W. Linville, linux-wireless
In-Reply-To: <3ace41890910081622k7c86453dm72e5584f4adbb763@mail.gmail.com>
On Thu, Oct 8, 2009 at 7:22 PM, Hin-Tak Leung <hintak.leung@gmail.com> wrote:
> On Thu, Oct 8, 2009 at 2:43 PM, Luis R. Rodriguez
> <lrodriguez@atheros.com> wrote:
>> On Thu, Oct 8, 2009 at 7:50 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
>>> On Thu, 2009-10-08 at 11:51 +0200, Johannes Berg wrote:
>>>
>>>> Ok, that's odd. Is it possible that somehow cfg80211 is picking up an
>>>> #ifdef'ed copy of "struct iw_handler_def", and thus the struct it is
>>>> defining is simply too small?
>>>
>>> That is apparently what is happening since compat-wireless ships
>>> iw_handler.h. This is wrong, as wext functionality is built into the
>>> kernel image so you can't use a newer header file with it.
>>
>> Dah, thanks for looking into this! This must've been there this way
>> for ages and we hadn't noticed until now. This is now fixed, and a new
>> tarball pushed out. I'll fix on the stable stuff as well, although I
>> doubt the header has changed much except now.
>>
>> Luis
>>
>
> Thanks everybody! Works alright now, after 'compat-2.6: stop shipping
> bleeding edge iw_handler.h' .
>
> There are some harmless warnings from using the old header, but
> otherwise it is working as it should:
> CC [M] /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.o
> /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c: In
> function ‘__cfg80211_connect_result’:
> /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c:370:
> warning: passing argument 4 of ‘wireless_send_event’ discards
> qualifiers from pointer target type
> include/net/iw_handler.h:443: note: expected ‘char *’ but argument is
> of type ‘const u8 *’
> /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c:376:
> warning: passing argument 4 of ‘wireless_send_event’ discards
> qualifiers from pointer target type
> include/net/iw_handler.h:443: note: expected ‘char *’ but argument is
> of type ‘const u8 *’
> /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c: In
> function ‘__cfg80211_roamed’:
> /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c:520:
> warning: passing argument 4 of ‘wireless_send_event’ discards
> qualifiers from pointer target type
> include/net/iw_handler.h:443: note: expected ‘char *’ but argument is
> of type ‘const u8 *’
> /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c:527:
> warning: passing argument 4 of ‘wireless_send_event’ discards
> qualifiers from pointer target type
> include/net/iw_handler.h:443: note: expected ‘char *’ but argument is
> of type ‘const u8 *’
The last argument to wireless_send_event() was changed to be const on
2.6.32, cant think of a way to avoid this warning.
Luis
^ permalink raw reply
* Re: NULL pointer deref at wext ioctl (Re: [PATCH] compat-2.6: adding ethtool.h to compat-2.6.31.h)
From: Hin-Tak Leung @ 2009-10-08 23:22 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Johannes Berg, John W. Linville, linux-wireless
In-Reply-To: <43e72e890910080643h282c4bf1xf972f15f13eae755@mail.gmail.com>
On Thu, Oct 8, 2009 at 2:43 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Thu, Oct 8, 2009 at 7:50 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
>> On Thu, 2009-10-08 at 11:51 +0200, Johannes Berg wrote:
>>
>>> Ok, that's odd. Is it possible that somehow cfg80211 is picking up an
>>> #ifdef'ed copy of "struct iw_handler_def", and thus the struct it is
>>> defining is simply too small?
>>
>> That is apparently what is happening since compat-wireless ships
>> iw_handler.h. This is wrong, as wext functionality is built into the
>> kernel image so you can't use a newer header file with it.
>
> Dah, thanks for looking into this! This must've been there this way
> for ages and we hadn't noticed until now. This is now fixed, and a new
> tarball pushed out. I'll fix on the stable stuff as well, although I
> doubt the header has changed much except now.
>
> Luis
>
Thanks everybody! Works alright now, after 'compat-2.6: stop shipping
bleeding edge iw_handler.h' .
There are some harmless warnings from using the old header, but
otherwise it is working as it should:
CC [M] /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.o
/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c: In
function ‘__cfg80211_connect_result’:
/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c:370:
warning: passing argument 4 of ‘wireless_send_event’ discards
qualifiers from pointer target type
include/net/iw_handler.h:443: note: expected ‘char *’ but argument is
of type ‘const u8 *’
/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c:376:
warning: passing argument 4 of ‘wireless_send_event’ discards
qualifiers from pointer target type
include/net/iw_handler.h:443: note: expected ‘char *’ but argument is
of type ‘const u8 *’
/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c: In
function ‘__cfg80211_roamed’:
/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c:520:
warning: passing argument 4 of ‘wireless_send_event’ discards
qualifiers from pointer target type
include/net/iw_handler.h:443: note: expected ‘char *’ but argument is
of type ‘const u8 *’
/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c:527:
warning: passing argument 4 of ‘wireless_send_event’ discards
qualifiers from pointer target type
include/net/iw_handler.h:443: note: expected ‘char *’ but argument is
of type ‘const u8 *’
Hin-Tak
^ permalink raw reply
* Re: pull request: wireless-2.6 2009-10-08
From: Michael Buesch @ 2009-10-08 23:16 UTC (permalink / raw)
To: John W. Linville; +Cc: davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <200910090108.08838.mb@bu3sch.de>
On Friday 09 October 2009 01:08:06 Michael Buesch wrote:
> On Friday 09 October 2009 00:34:54 John W. Linville wrote:
> > Albert Herranz (1):
> > b43: do not stack-allocate pio rx/tx header and tail buffers
>
> Come on, this is _not_ funny anymore. I did _not_ ack this patch, because I do _not_ like it.
> I was planning to do a better solution, but I didn't have the time, yet.
> Can you _please_ either:
> - Wait for my ack before you apply random b43 patches
> or
> - Remove me from MAINTAINERS
>
And there's no reason to rush this fix into mainline. We currently do not even
have a supported device which would require this fix. The Wii, which uses the SDIO bus,
does not require this fix. So the only supported device (as of now) does not need the fix
to work properly.
So it can as well go into the next merge window.
--
Greetings, Michael.
^ permalink raw reply
* Re: pull request: wireless-2.6 2009-10-08
From: Michael Buesch @ 2009-10-08 23:08 UTC (permalink / raw)
To: John W. Linville; +Cc: davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <20091008223454.GB2798@tuxdriver.com>
On Friday 09 October 2009 00:34:54 John W. Linville wrote:
> Albert Herranz (1):
> b43: do not stack-allocate pio rx/tx header and tail buffers
Come on, this is _not_ funny anymore. I did _not_ ack this patch, because I do _not_ like it.
I was planning to do a better solution, but I didn't have the time, yet.
Can you _please_ either:
- Wait for my ack before you apply random b43 patches
or
- Remove me from MAINTAINERS
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH] b43: Fix locking problem when stopping rfkill polling
From: John W. Linville @ 2009-10-08 22:31 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Greg Kroah-Hartman
In-Reply-To: <4ACE4A48.9070901@lwfinger.net>
On Thu, Oct 08, 2009 at 03:23:36PM -0500, Larry Finger wrote:
> On 10/07/2009 02:01 PM, John W. Linville wrote:
>> OK, but why do we start polling under the lock but stop polling without
>> the lock? Should we start polling without holding the lock too?
>
> I see that this patch was committed. I hope that you will be sending it
> upstream for 2.6.32. The correct version has been sent to stable for
> inclusion in 2.6.31, but as usual, a mainline commit ID will be needed.
I've folded this into "b43: Fix PPC crash in rfkill polling on unload"
for sending upstream.
Thanks!
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* pull request: wireless-2.6 2009-10-08
From: John W. Linville @ 2009-10-08 22:34 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here is another batch of fixes intended for 2.6.32. Most of them are
short, self-contained and more-or-less obvious. Most of them have been
baking in -next for several days.
The b43 patch from Albert Herranz looks big, but most of it is moving a
structure definition within a header file. It also changes some DMA
buffers from stack to heap allocation.
Please let me know if there are problems!
Thanks,
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/
---
The following changes since commit a4d63a943735efa30270ce70716d43323fd40f02:
Thomas Chou (1):
ethoc: limit the number of buffers to 128
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Albert Herranz (1):
b43: do not stack-allocate pio rx/tx header and tail buffers
Bjorn Helgaas (1):
iwlwifi: use %pM for formatted MAC addresses
Jay Sternberg (1):
iwlwifi: incorrect method used for finding valid OTP blocks
Johannes Berg (2):
mac80211: fix vlan and optimise RX
cfg80211: fix netns error unwinding bug
Larry Finger (1):
b43: Fix PPC crash in rfkill polling on unload
Michael Buesch (2):
b43: Don't use struct wldev after detach.
b43: Protect sanity check against physical device removal
Reinette Chatre (2):
iwlwifi: fix compile warning
iwlagn: fix compile warning in iwl5000_gain_computation
Roel Kluin (2):
mac80211: fix ADM8211_SYNCTL_RFtype define
mac80211: use kfree_skb() to free struct sk_buff pointers
Wey-Yi Guy (1):
iwlwifi: fix EEPROM enhance tx power offset
drivers/net/wireless/adm8211.h | 2 +-
drivers/net/wireless/b43/b43.h | 168 +++++++++++++++------------
drivers/net/wireless/b43/leds.c | 4 +-
drivers/net/wireless/b43/leds.h | 4 +-
drivers/net/wireless/b43/main.c | 7 +-
drivers/net/wireless/b43/pio.c | 78 ++++++------
drivers/net/wireless/b43/xmit.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-3945-rs.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-3945.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-5000.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-commands.h | 2 +-
drivers/net/wireless/iwlwifi/iwl-eeprom.c | 23 ++--
drivers/net/wireless/iwlwifi/iwl-eeprom.h | 20 ++--
drivers/net/wireless/iwlwifi/iwl-rx.c | 2 +-
net/mac80211/rx.c | 10 ++-
net/mac80211/sta_info.c | 2 +
net/mac80211/tx.c | 3 +-
net/mac80211/util.c | 4 +-
net/wireless/nl80211.c | 3 +-
19 files changed, 184 insertions(+), 156 deletions(-)
diff --git a/drivers/net/wireless/adm8211.h b/drivers/net/wireless/adm8211.h
index 4f6ab13..b07e4d3 100644
--- a/drivers/net/wireless/adm8211.h
+++ b/drivers/net/wireless/adm8211.h
@@ -266,7 +266,7 @@ do { \
#define ADM8211_SYNCTL_CS1 (1 << 28)
#define ADM8211_SYNCTL_CAL (1 << 27)
#define ADM8211_SYNCTL_SELCAL (1 << 26)
-#define ADM8211_SYNCTL_RFtype ((1 << 24) || (1 << 23) || (1 << 22))
+#define ADM8211_SYNCTL_RFtype ((1 << 24) | (1 << 23) | (1 << 22))
#define ADM8211_SYNCTL_RFMD (1 << 22)
#define ADM8211_SYNCTL_GENERAL (0x7 << 22)
/* SYNCTL 21:0 Data (Si4126: 18-bit data, 4-bit address) */
diff --git a/drivers/net/wireless/b43/b43.h b/drivers/net/wireless/b43/b43.h
index fa1549a..6607162 100644
--- a/drivers/net/wireless/b43/b43.h
+++ b/drivers/net/wireless/b43/b43.h
@@ -607,82 +607,7 @@ struct b43_qos_params {
struct ieee80211_tx_queue_params p;
};
-struct b43_wldev;
-
-/* Data structure for the WLAN parts (802.11 cores) of the b43 chip. */
-struct b43_wl {
- /* Pointer to the active wireless device on this chip */
- struct b43_wldev *current_dev;
- /* Pointer to the ieee80211 hardware data structure */
- struct ieee80211_hw *hw;
-
- /* Global driver mutex. Every operation must run with this mutex locked. */
- struct mutex mutex;
- /* Hard-IRQ spinlock. This lock protects things used in the hard-IRQ
- * handler, only. This basically is just the IRQ mask register. */
- spinlock_t hardirq_lock;
-
- /* The number of queues that were registered with the mac80211 subsystem
- * initially. This is a backup copy of hw->queues in case hw->queues has
- * to be dynamically lowered at runtime (Firmware does not support QoS).
- * hw->queues has to be restored to the original value before unregistering
- * from the mac80211 subsystem. */
- u16 mac80211_initially_registered_queues;
-
- /* We can only have one operating interface (802.11 core)
- * at a time. General information about this interface follows.
- */
-
- struct ieee80211_vif *vif;
- /* The MAC address of the operating interface. */
- u8 mac_addr[ETH_ALEN];
- /* Current BSSID */
- u8 bssid[ETH_ALEN];
- /* Interface type. (NL80211_IFTYPE_XXX) */
- int if_type;
- /* Is the card operating in AP, STA or IBSS mode? */
- bool operating;
- /* filter flags */
- unsigned int filter_flags;
- /* Stats about the wireless interface */
- struct ieee80211_low_level_stats ieee_stats;
-
-#ifdef CONFIG_B43_HWRNG
- struct hwrng rng;
- bool rng_initialized;
- char rng_name[30 + 1];
-#endif /* CONFIG_B43_HWRNG */
-
- /* List of all wireless devices on this chip */
- struct list_head devlist;
- u8 nr_devs;
-
- bool radiotap_enabled;
- bool radio_enabled;
-
- /* The beacon we are currently using (AP or IBSS mode). */
- struct sk_buff *current_beacon;
- bool beacon0_uploaded;
- bool beacon1_uploaded;
- bool beacon_templates_virgin; /* Never wrote the templates? */
- struct work_struct beacon_update_trigger;
-
- /* The current QOS parameters for the 4 queues. */
- struct b43_qos_params qos_params[4];
-
- /* Work for adjustment of the transmission power.
- * This is scheduled when we determine that the actual TX output
- * power doesn't match what we want. */
- struct work_struct txpower_adjust_work;
-
- /* Packet transmit work */
- struct work_struct tx_work;
- /* Queue of packets to be transmitted. */
- struct sk_buff_head tx_queue;
-
- /* The device LEDs. */
- struct b43_leds leds;
-};
+struct b43_wl;
/* The type of the firmware file. */
enum b43_firmware_file_type {
@@ -824,6 +749,97 @@ struct b43_wldev {
#endif
};
+/*
+ * Include goes here to avoid a dependency problem.
+ * A better fix would be to integrate xmit.h into b43.h.
+ */
+#include "xmit.h"
+
+/* Data structure for the WLAN parts (802.11 cores) of the b43 chip. */
+struct b43_wl {
+ /* Pointer to the active wireless device on this chip */
+ struct b43_wldev *current_dev;
+ /* Pointer to the ieee80211 hardware data structure */
+ struct ieee80211_hw *hw;
+
+ /* Global driver mutex. Every operation must run with this mutex locked. */
+ struct mutex mutex;
+ /* Hard-IRQ spinlock. This lock protects things used in the hard-IRQ
+ * handler, only. This basically is just the IRQ mask register. */
+ spinlock_t hardirq_lock;
+
+ /* The number of queues that were registered with the mac80211 subsystem
+ * initially. This is a backup copy of hw->queues in case hw->queues has
+ * to be dynamically lowered at runtime (Firmware does not support QoS).
+ * hw->queues has to be restored to the original value before unregistering
+ * from the mac80211 subsystem. */
+ u16 mac80211_initially_registered_queues;
+
+ /* We can only have one operating interface (802.11 core)
+ * at a time. General information about this interface follows.
+ */
+
+ struct ieee80211_vif *vif;
+ /* The MAC address of the operating interface. */
+ u8 mac_addr[ETH_ALEN];
+ /* Current BSSID */
+ u8 bssid[ETH_ALEN];
+ /* Interface type. (NL80211_IFTYPE_XXX) */
+ int if_type;
+ /* Is the card operating in AP, STA or IBSS mode? */
+ bool operating;
+ /* filter flags */
+ unsigned int filter_flags;
+ /* Stats about the wireless interface */
+ struct ieee80211_low_level_stats ieee_stats;
+
+#ifdef CONFIG_B43_HWRNG
+ struct hwrng rng;
+ bool rng_initialized;
+ char rng_name[30 + 1];
+#endif /* CONFIG_B43_HWRNG */
+
+ /* List of all wireless devices on this chip */
+ struct list_head devlist;
+ u8 nr_devs;
+
+ bool radiotap_enabled;
+ bool radio_enabled;
+
+ /* The beacon we are currently using (AP or IBSS mode). */
+ struct sk_buff *current_beacon;
+ bool beacon0_uploaded;
+ bool beacon1_uploaded;
+ bool beacon_templates_virgin; /* Never wrote the templates? */
+ struct work_struct beacon_update_trigger;
+
+ /* The current QOS parameters for the 4 queues. */
+ struct b43_qos_params qos_params[4];
+
+ /* Work for adjustment of the transmission power.
+ * This is scheduled when we determine that the actual TX output
+ * power doesn't match what we want. */
+ struct work_struct txpower_adjust_work;
+
+ /* Packet transmit work */
+ struct work_struct tx_work;
+ /* Queue of packets to be transmitted. */
+ struct sk_buff_head tx_queue;
+
+ /* The device LEDs. */
+ struct b43_leds leds;
+
+#ifdef CONFIG_B43_PIO
+ /*
+ * RX/TX header/tail buffers used by the frame transmit functions.
+ */
+ struct b43_rxhdr_fw4 rxhdr;
+ struct b43_txhdr txhdr;
+ u8 rx_tail[4];
+ u8 tx_tail[4];
+#endif /* CONFIG_B43_PIO */
+};
+
static inline struct b43_wl *hw_to_b43_wl(struct ieee80211_hw *hw)
{
return hw->priv;
diff --git a/drivers/net/wireless/b43/leds.c b/drivers/net/wireless/b43/leds.c
index fbe3d4f..1e8dba4 100644
--- a/drivers/net/wireless/b43/leds.c
+++ b/drivers/net/wireless/b43/leds.c
@@ -348,9 +348,9 @@ void b43_leds_register(struct b43_wldev *dev)
}
}
-void b43_leds_unregister(struct b43_wldev *dev)
+void b43_leds_unregister(struct b43_wl *wl)
{
- struct b43_leds *leds = &dev->wl->leds;
+ struct b43_leds *leds = &wl->leds;
b43_unregister_led(&leds->led_tx);
b43_unregister_led(&leds->led_rx);
diff --git a/drivers/net/wireless/b43/leds.h b/drivers/net/wireless/b43/leds.h
index 9592e4c..4c56187 100644
--- a/drivers/net/wireless/b43/leds.h
+++ b/drivers/net/wireless/b43/leds.h
@@ -60,7 +60,7 @@ enum b43_led_behaviour {
};
void b43_leds_register(struct b43_wldev *dev);
-void b43_leds_unregister(struct b43_wldev *dev);
+void b43_leds_unregister(struct b43_wl *wl);
void b43_leds_init(struct b43_wldev *dev);
void b43_leds_exit(struct b43_wldev *dev);
void b43_leds_stop(struct b43_wldev *dev);
@@ -76,7 +76,7 @@ struct b43_leds {
static inline void b43_leds_register(struct b43_wldev *dev)
{
}
-static inline void b43_leds_unregister(struct b43_wldev *dev)
+static inline void b43_leds_unregister(struct b43_wl *wl)
{
}
static inline void b43_leds_init(struct b43_wldev *dev)
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index 9b907a3..df6b26a 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -3874,6 +3874,7 @@ static struct b43_wldev * b43_wireless_core_stop(struct b43_wldev *dev)
{
struct b43_wl *wl = dev->wl;
struct b43_wldev *orig_dev;
+ u32 mask;
redo:
if (!dev || b43_status(dev) < B43_STAT_STARTED)
@@ -3920,7 +3921,8 @@ redo:
goto redo;
return dev;
}
- B43_WARN_ON(b43_read32(dev, B43_MMIO_GEN_IRQ_MASK));
+ mask = b43_read32(dev, B43_MMIO_GEN_IRQ_MASK);
+ B43_WARN_ON(mask != 0xFFFFFFFF && mask);
/* Drain the TX queue */
while (skb_queue_len(&wl->tx_queue))
@@ -4499,6 +4501,7 @@ static void b43_op_stop(struct ieee80211_hw *hw)
cancel_work_sync(&(wl->beacon_update_trigger));
+ wiphy_rfkill_stop_polling(hw->wiphy);
mutex_lock(&wl->mutex);
if (b43_status(dev) >= B43_STAT_STARTED) {
dev = b43_wireless_core_stop(dev);
@@ -4997,7 +5000,7 @@ static void b43_remove(struct ssb_device *dev)
if (list_empty(&wl->devlist)) {
b43_rng_exit(wl);
- b43_leds_unregister(wldev);
+ b43_leds_unregister(wl);
/* Last core on the chip unregistered.
* We can destroy common struct b43_wl.
*/
diff --git a/drivers/net/wireless/b43/pio.c b/drivers/net/wireless/b43/pio.c
index 9c13979..dbbf0d1 100644
--- a/drivers/net/wireless/b43/pio.c
+++ b/drivers/net/wireless/b43/pio.c
@@ -331,6 +331,7 @@ static u16 tx_write_2byte_queue(struct b43_pio_txqueue *q,
unsigned int data_len)
{
struct b43_wldev *dev = q->dev;
+ struct b43_wl *wl = dev->wl;
const u8 *data = _data;
ctl |= B43_PIO_TXCTL_WRITELO | B43_PIO_TXCTL_WRITEHI;
@@ -340,13 +341,12 @@ static u16 tx_write_2byte_queue(struct b43_pio_txqueue *q,
q->mmio_base + B43_PIO_TXDATA,
sizeof(u16));
if (data_len & 1) {
- u8 tail[2] = { 0, };
-
/* Write the last byte. */
ctl &= ~B43_PIO_TXCTL_WRITEHI;
b43_piotx_write16(q, B43_PIO_TXCTL, ctl);
- tail[0] = data[data_len - 1];
- ssb_block_write(dev->dev, tail, 2,
+ wl->tx_tail[0] = data[data_len - 1];
+ wl->tx_tail[1] = 0;
+ ssb_block_write(dev->dev, wl->tx_tail, 2,
q->mmio_base + B43_PIO_TXDATA,
sizeof(u16));
}
@@ -381,6 +381,7 @@ static u32 tx_write_4byte_queue(struct b43_pio_txqueue *q,
unsigned int data_len)
{
struct b43_wldev *dev = q->dev;
+ struct b43_wl *wl = dev->wl;
const u8 *data = _data;
ctl |= B43_PIO8_TXCTL_0_7 | B43_PIO8_TXCTL_8_15 |
@@ -391,29 +392,31 @@ static u32 tx_write_4byte_queue(struct b43_pio_txqueue *q,
q->mmio_base + B43_PIO8_TXDATA,
sizeof(u32));
if (data_len & 3) {
- u8 tail[4] = { 0, };
-
+ wl->tx_tail[3] = 0;
/* Write the last few bytes. */
ctl &= ~(B43_PIO8_TXCTL_8_15 | B43_PIO8_TXCTL_16_23 |
B43_PIO8_TXCTL_24_31);
switch (data_len & 3) {
case 3:
ctl |= B43_PIO8_TXCTL_16_23 | B43_PIO8_TXCTL_8_15;
- tail[0] = data[data_len - 3];
- tail[1] = data[data_len - 2];
- tail[2] = data[data_len - 1];
+ wl->tx_tail[0] = data[data_len - 3];
+ wl->tx_tail[1] = data[data_len - 2];
+ wl->tx_tail[2] = data[data_len - 1];
break;
case 2:
ctl |= B43_PIO8_TXCTL_8_15;
- tail[0] = data[data_len - 2];
- tail[1] = data[data_len - 1];
+ wl->tx_tail[0] = data[data_len - 2];
+ wl->tx_tail[1] = data[data_len - 1];
+ wl->tx_tail[2] = 0;
break;
case 1:
- tail[0] = data[data_len - 1];
+ wl->tx_tail[0] = data[data_len - 1];
+ wl->tx_tail[1] = 0;
+ wl->tx_tail[2] = 0;
break;
}
b43_piotx_write32(q, B43_PIO8_TXCTL, ctl);
- ssb_block_write(dev->dev, tail, 4,
+ ssb_block_write(dev->dev, wl->tx_tail, 4,
q->mmio_base + B43_PIO8_TXDATA,
sizeof(u32));
}
@@ -445,8 +448,9 @@ static void pio_tx_frame_4byte_queue(struct b43_pio_txpacket *pack,
static int pio_tx_frame(struct b43_pio_txqueue *q,
struct sk_buff *skb)
{
+ struct b43_wldev *dev = q->dev;
+ struct b43_wl *wl = dev->wl;
struct b43_pio_txpacket *pack;
- struct b43_txhdr txhdr;
u16 cookie;
int err;
unsigned int hdrlen;
@@ -457,8 +461,8 @@ static int pio_tx_frame(struct b43_pio_txqueue *q,
struct b43_pio_txpacket, list);
cookie = generate_cookie(q, pack);
- hdrlen = b43_txhdr_size(q->dev);
- err = b43_generate_txhdr(q->dev, (u8 *)&txhdr, skb,
+ hdrlen = b43_txhdr_size(dev);
+ err = b43_generate_txhdr(dev, (u8 *)&wl->txhdr, skb,
info, cookie);
if (err)
return err;
@@ -466,15 +470,15 @@ static int pio_tx_frame(struct b43_pio_txqueue *q,
if (info->flags & IEEE80211_TX_CTL_SEND_AFTER_DTIM) {
/* Tell the firmware about the cookie of the last
* mcast frame, so it can clear the more-data bit in it. */
- b43_shm_write16(q->dev, B43_SHM_SHARED,
+ b43_shm_write16(dev, B43_SHM_SHARED,
B43_SHM_SH_MCASTCOOKIE, cookie);
}
pack->skb = skb;
if (q->rev >= 8)
- pio_tx_frame_4byte_queue(pack, (const u8 *)&txhdr, hdrlen);
+ pio_tx_frame_4byte_queue(pack, (const u8 *)&wl->txhdr, hdrlen);
else
- pio_tx_frame_2byte_queue(pack, (const u8 *)&txhdr, hdrlen);
+ pio_tx_frame_2byte_queue(pack, (const u8 *)&wl->txhdr, hdrlen);
/* Remove it from the list of available packet slots.
* It will be put back when we receive the status report. */
@@ -614,14 +618,14 @@ void b43_pio_get_tx_stats(struct b43_wldev *dev,
static bool pio_rx_frame(struct b43_pio_rxqueue *q)
{
struct b43_wldev *dev = q->dev;
- struct b43_rxhdr_fw4 rxhdr;
+ struct b43_wl *wl = dev->wl;
u16 len;
u32 macstat;
unsigned int i, padding;
struct sk_buff *skb;
const char *err_msg = NULL;
- memset(&rxhdr, 0, sizeof(rxhdr));
+ memset(&wl->rxhdr, 0, sizeof(wl->rxhdr));
/* Check if we have data and wait for it to get ready. */
if (q->rev >= 8) {
@@ -659,16 +663,16 @@ data_ready:
/* Get the preamble (RX header) */
if (q->rev >= 8) {
- ssb_block_read(dev->dev, &rxhdr, sizeof(rxhdr),
+ ssb_block_read(dev->dev, &wl->rxhdr, sizeof(wl->rxhdr),
q->mmio_base + B43_PIO8_RXDATA,
sizeof(u32));
} else {
- ssb_block_read(dev->dev, &rxhdr, sizeof(rxhdr),
+ ssb_block_read(dev->dev, &wl->rxhdr, sizeof(wl->rxhdr),
q->mmio_base + B43_PIO_RXDATA,
sizeof(u16));
}
/* Sanity checks. */
- len = le16_to_cpu(rxhdr.frame_len);
+ len = le16_to_cpu(wl->rxhdr.frame_len);
if (unlikely(len > 0x700)) {
err_msg = "len > 0x700";
goto rx_error;
@@ -678,7 +682,7 @@ data_ready:
goto rx_error;
}
- macstat = le32_to_cpu(rxhdr.mac_status);
+ macstat = le32_to_cpu(wl->rxhdr.mac_status);
if (macstat & B43_RX_MAC_FCSERR) {
if (!(q->dev->wl->filter_flags & FIF_FCSFAIL)) {
/* Drop frames with failed FCS. */
@@ -703,24 +707,22 @@ data_ready:
q->mmio_base + B43_PIO8_RXDATA,
sizeof(u32));
if (len & 3) {
- u8 tail[4] = { 0, };
-
/* Read the last few bytes. */
- ssb_block_read(dev->dev, tail, 4,
+ ssb_block_read(dev->dev, wl->rx_tail, 4,
q->mmio_base + B43_PIO8_RXDATA,
sizeof(u32));
switch (len & 3) {
case 3:
- skb->data[len + padding - 3] = tail[0];
- skb->data[len + padding - 2] = tail[1];
- skb->data[len + padding - 1] = tail[2];
+ skb->data[len + padding - 3] = wl->rx_tail[0];
+ skb->data[len + padding - 2] = wl->rx_tail[1];
+ skb->data[len + padding - 1] = wl->rx_tail[2];
break;
case 2:
- skb->data[len + padding - 2] = tail[0];
- skb->data[len + padding - 1] = tail[1];
+ skb->data[len + padding - 2] = wl->rx_tail[0];
+ skb->data[len + padding - 1] = wl->rx_tail[1];
break;
case 1:
- skb->data[len + padding - 1] = tail[0];
+ skb->data[len + padding - 1] = wl->rx_tail[0];
break;
}
}
@@ -729,17 +731,15 @@ data_ready:
q->mmio_base + B43_PIO_RXDATA,
sizeof(u16));
if (len & 1) {
- u8 tail[2] = { 0, };
-
/* Read the last byte. */
- ssb_block_read(dev->dev, tail, 2,
+ ssb_block_read(dev->dev, wl->rx_tail, 2,
q->mmio_base + B43_PIO_RXDATA,
sizeof(u16));
- skb->data[len + padding - 1] = tail[0];
+ skb->data[len + padding - 1] = wl->rx_tail[0];
}
}
- b43_rx(q->dev, skb, &rxhdr);
+ b43_rx(q->dev, skb, &wl->rxhdr);
return 1;
diff --git a/drivers/net/wireless/b43/xmit.c b/drivers/net/wireless/b43/xmit.c
index ac9f600..892573b 100644
--- a/drivers/net/wireless/b43/xmit.c
+++ b/drivers/net/wireless/b43/xmit.c
@@ -27,7 +27,7 @@
*/
-#include "xmit.h"
+#include "b43.h"
#include "phy_common.h"
#include "dma.h"
#include "pio.h"
diff --git a/drivers/net/wireless/iwlwifi/iwl-3945-rs.c b/drivers/net/wireless/iwlwifi/iwl-3945-rs.c
index a16bd41..cbb0585 100644
--- a/drivers/net/wireless/iwlwifi/iwl-3945-rs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-3945-rs.c
@@ -702,7 +702,7 @@ static void rs_get_rate(void *priv_r, struct ieee80211_sta *sta,
u8 sta_id = iwl_find_station(priv, hdr->addr1);
if (sta_id == IWL_INVALID_STATION) {
- IWL_DEBUG_RATE(priv, "LQ: ADD station %pm\n",
+ IWL_DEBUG_RATE(priv, "LQ: ADD station %pM\n",
hdr->addr1);
sta_id = iwl_add_station(priv, hdr->addr1, false,
CMD_ASYNC, NULL);
diff --git a/drivers/net/wireless/iwlwifi/iwl-3945.c b/drivers/net/wireless/iwlwifi/iwl-3945.c
index e70c5b0..231c833 100644
--- a/drivers/net/wireless/iwlwifi/iwl-3945.c
+++ b/drivers/net/wireless/iwlwifi/iwl-3945.c
@@ -610,7 +610,7 @@ static void iwl3945_rx_reply_rx(struct iwl_priv *priv,
if (rx_status.band == IEEE80211_BAND_5GHZ)
rx_status.rate_idx -= IWL_FIRST_OFDM_RATE;
- rx_status.antenna = le16_to_cpu(rx_hdr->phy_flags &
+ rx_status.antenna = (le16_to_cpu(rx_hdr->phy_flags) &
RX_RES_PHY_FLAGS_ANTENNA_MSK) >> 4;
/* set the preamble flag if appropriate */
diff --git a/drivers/net/wireless/iwlwifi/iwl-5000.c b/drivers/net/wireless/iwlwifi/iwl-5000.c
index eb08f44..524e7e4 100644
--- a/drivers/net/wireless/iwlwifi/iwl-5000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-5000.c
@@ -317,7 +317,7 @@ static void iwl5000_gain_computation(struct iwl_priv *priv,
(s32)average_noise[i])) / 1500;
/* bound gain by 2 bits value max, 3rd bit is sign */
data->delta_gain_code[i] =
- min(abs(delta_g), CHAIN_NOISE_MAX_DELTA_GAIN_CODE);
+ min(abs(delta_g), (long) CHAIN_NOISE_MAX_DELTA_GAIN_CODE);
if (delta_g < 0)
/* set negative sign */
diff --git a/drivers/net/wireless/iwlwifi/iwl-commands.h b/drivers/net/wireless/iwlwifi/iwl-commands.h
index 2c5c88f..4afaf77 100644
--- a/drivers/net/wireless/iwlwifi/iwl-commands.h
+++ b/drivers/net/wireless/iwlwifi/iwl-commands.h
@@ -1154,7 +1154,7 @@ struct iwl_wep_cmd {
#define RX_RES_PHY_FLAGS_MOD_CCK_MSK cpu_to_le16(1 << 1)
#define RX_RES_PHY_FLAGS_SHORT_PREAMBLE_MSK cpu_to_le16(1 << 2)
#define RX_RES_PHY_FLAGS_NARROW_BAND_MSK cpu_to_le16(1 << 3)
-#define RX_RES_PHY_FLAGS_ANTENNA_MSK cpu_to_le16(0xf0)
+#define RX_RES_PHY_FLAGS_ANTENNA_MSK 0xf0
#define RX_RES_PHY_FLAGS_ANTENNA_POS 4
#define RX_RES_STATUS_SEC_TYPE_MSK (0x7 << 8)
diff --git a/drivers/net/wireless/iwlwifi/iwl-eeprom.c b/drivers/net/wireless/iwlwifi/iwl-eeprom.c
index 3d2b93a..e14c995 100644
--- a/drivers/net/wireless/iwlwifi/iwl-eeprom.c
+++ b/drivers/net/wireless/iwlwifi/iwl-eeprom.c
@@ -410,7 +410,6 @@ static int iwl_find_otp_image(struct iwl_priv *priv,
u16 *validblockaddr)
{
u16 next_link_addr = 0, link_value = 0, valid_addr;
- int ret = 0;
int usedblocks = 0;
/* set addressing mode to absolute to traverse the link list */
@@ -430,29 +429,29 @@ static int iwl_find_otp_image(struct iwl_priv *priv,
* check for more block on the link list
*/
valid_addr = next_link_addr;
- next_link_addr = link_value;
+ next_link_addr = link_value * sizeof(u16);
IWL_DEBUG_INFO(priv, "OTP blocks %d addr 0x%x\n",
usedblocks, next_link_addr);
if (iwl_read_otp_word(priv, next_link_addr, &link_value))
return -EINVAL;
if (!link_value) {
/*
- * reach the end of link list,
+ * reach the end of link list, return success and
* set address point to the starting address
* of the image
*/
- goto done;
+ *validblockaddr = valid_addr;
+ /* skip first 2 bytes (link list pointer) */
+ *validblockaddr += 2;
+ return 0;
}
/* more in the link list, continue */
usedblocks++;
- } while (usedblocks < priv->cfg->max_ll_items);
- /* OTP full, use last block */
- IWL_DEBUG_INFO(priv, "OTP is full, use last block\n");
-done:
- *validblockaddr = valid_addr;
- /* skip first 2 bytes (link list pointer) */
- *validblockaddr += 2;
- return ret;
+ } while (usedblocks <= priv->cfg->max_ll_items);
+
+ /* OTP has no valid blocks */
+ IWL_DEBUG_INFO(priv, "OTP has no valid blocks\n");
+ return -EINVAL;
}
/**
diff --git a/drivers/net/wireless/iwlwifi/iwl-eeprom.h b/drivers/net/wireless/iwlwifi/iwl-eeprom.h
index 6b68db7..80b9e45 100644
--- a/drivers/net/wireless/iwlwifi/iwl-eeprom.h
+++ b/drivers/net/wireless/iwlwifi/iwl-eeprom.h
@@ -220,35 +220,35 @@ struct iwl_eeprom_enhanced_txpwr {
* Section 10: 2.4 GHz 40MHz channels: 132, 44 (_above_)
*/
/* 2.4 GHz band: CCK */
-#define EEPROM_LB_CCK_20_COMMON ((0xAA)\
+#define EEPROM_LB_CCK_20_COMMON ((0xA8)\
| INDIRECT_ADDRESS | INDIRECT_REGULATORY) /* 8 bytes */
/* 2.4 GHz band: 20MHz-Legacy, 20MHz-HT, 40MHz-HT */
-#define EEPROM_LB_OFDM_COMMON ((0xB2)\
+#define EEPROM_LB_OFDM_COMMON ((0xB0)\
| INDIRECT_ADDRESS | INDIRECT_REGULATORY) /* 24 bytes */
/* 5.2 GHz band: 20MHz-Legacy, 20MHz-HT, 40MHz-HT */
-#define EEPROM_HB_OFDM_COMMON ((0xCA)\
+#define EEPROM_HB_OFDM_COMMON ((0xC8)\
| INDIRECT_ADDRESS | INDIRECT_REGULATORY) /* 24 bytes */
/* 2.4GHz band channels:
* 1Legacy, 1HT, 2Legacy, 2HT, 10Legacy, 10HT, 11Legacy, 11HT */
-#define EEPROM_LB_OFDM_20_BAND ((0xE2)\
+#define EEPROM_LB_OFDM_20_BAND ((0xE0)\
| INDIRECT_ADDRESS | INDIRECT_REGULATORY) /* 64 bytes */
/* 2.4 GHz band HT40 channels: (1,+1) (2,+1) (6,+1) (7,+1) (9,+1) */
-#define EEPROM_LB_OFDM_HT40_BAND ((0x122)\
+#define EEPROM_LB_OFDM_HT40_BAND ((0x120)\
| INDIRECT_ADDRESS | INDIRECT_REGULATORY) /* 40 bytes */
/* 5.2GHz band channels: 36Legacy, 36HT, 64Legacy, 64HT, 100Legacy, 100HT */
-#define EEPROM_HB_OFDM_20_BAND ((0x14A)\
+#define EEPROM_HB_OFDM_20_BAND ((0x148)\
| INDIRECT_ADDRESS | INDIRECT_REGULATORY) /* 48 bytes */
/* 5.2 GHz band HT40 channels: (36,+1) (60,+1) (100,+1) */
-#define EEPROM_HB_OFDM_HT40_BAND ((0x17A)\
+#define EEPROM_HB_OFDM_HT40_BAND ((0x178)\
| INDIRECT_ADDRESS | INDIRECT_REGULATORY) /* 24 bytes */
/* 2.4 GHz band, channnel 13: Legacy, HT */
-#define EEPROM_LB_OFDM_20_CHANNEL_13 ((0x192)\
+#define EEPROM_LB_OFDM_20_CHANNEL_13 ((0x190)\
| INDIRECT_ADDRESS | INDIRECT_REGULATORY) /* 16 bytes */
/* 5.2 GHz band, channnel 140: Legacy, HT */
-#define EEPROM_HB_OFDM_20_CHANNEL_140 ((0x1A2)\
+#define EEPROM_HB_OFDM_20_CHANNEL_140 ((0x1A0)\
| INDIRECT_ADDRESS | INDIRECT_REGULATORY) /* 16 bytes */
/* 5.2 GHz band, HT40 channnels (132,+1) (44,+1) */
-#define EEPROM_HB_OFDM_HT40_BAND_1 ((0x1B2)\
+#define EEPROM_HB_OFDM_HT40_BAND_1 ((0x1B0)\
| INDIRECT_ADDRESS | INDIRECT_REGULATORY) /* 16 bytes */
diff --git a/drivers/net/wireless/iwlwifi/iwl-rx.c b/drivers/net/wireless/iwlwifi/iwl-rx.c
index 8e1bb53..493626b 100644
--- a/drivers/net/wireless/iwlwifi/iwl-rx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-rx.c
@@ -1044,7 +1044,7 @@ void iwl_rx_reply_rx(struct iwl_priv *priv,
* as a bitmask.
*/
rx_status.antenna =
- le16_to_cpu(phy_res->phy_flags & RX_RES_PHY_FLAGS_ANTENNA_MSK)
+ (le16_to_cpu(phy_res->phy_flags) & RX_RES_PHY_FLAGS_ANTENNA_MSK)
>> RX_RES_PHY_FLAGS_ANTENNA_POS;
/* set the preamble flag if appropriate */
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index c01588f..865fbc0 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2164,11 +2164,17 @@ static void __ieee80211_rx_handle_packet(struct ieee80211_hw *hw,
skb = rx.skb;
- list_for_each_entry_rcu(sdata, &local->interfaces, list) {
+ if (rx.sdata && ieee80211_is_data(hdr->frame_control)) {
+ rx.flags |= IEEE80211_RX_RA_MATCH;
+ prepares = prepare_for_handlers(rx.sdata, &rx, hdr);
+ if (prepares)
+ prev = rx.sdata;
+ } else list_for_each_entry_rcu(sdata, &local->interfaces, list) {
if (!netif_running(sdata->dev))
continue;
- if (sdata->vif.type == NL80211_IFTYPE_MONITOR)
+ if (sdata->vif.type == NL80211_IFTYPE_MONITOR ||
+ sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
continue;
rx.flags |= IEEE80211_RX_RA_MATCH;
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index eec0014..594f231 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -361,6 +361,7 @@ int sta_info_insert(struct sta_info *sta)
u.ap);
drv_sta_notify(local, &sdata->vif, STA_NOTIFY_ADD, &sta->sta);
+ sdata = sta->sdata;
}
#ifdef CONFIG_MAC80211_VERBOSE_DEBUG
@@ -496,6 +497,7 @@ static void __sta_info_unlink(struct sta_info **sta)
drv_sta_notify(local, &sdata->vif, STA_NOTIFY_REMOVE,
&(*sta)->sta);
+ sdata = (*sta)->sdata;
}
if (ieee80211_vif_is_mesh(&sdata->vif)) {
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index fd40282..db4bda6 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1704,7 +1704,8 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
if (!is_multicast_ether_addr(hdr.addr1)) {
rcu_read_lock();
sta = sta_info_get(local, hdr.addr1);
- if (sta)
+ /* XXX: in the future, use sdata to look up the sta */
+ if (sta && sta->sdata == sdata)
sta_flags = get_sta_flags(sta);
rcu_read_unlock();
}
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index dd65643..aeb65b3 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -339,7 +339,7 @@ void ieee80211_add_pending_skb(struct ieee80211_local *local,
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
if (WARN_ON(!info->control.vif)) {
- kfree(skb);
+ kfree_skb(skb);
return;
}
@@ -367,7 +367,7 @@ int ieee80211_add_pending_skbs(struct ieee80211_local *local,
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
if (WARN_ON(!info->control.vif)) {
- kfree(skb);
+ kfree_skb(skb);
continue;
}
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index eddab09..ca3c92a 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -4029,7 +4029,7 @@ static int nl80211_wiphy_netns(struct sk_buff *skb, struct genl_info *info)
rdev = cfg80211_get_dev_from_info(info);
if (IS_ERR(rdev)) {
err = PTR_ERR(rdev);
- goto out;
+ goto out_rtnl;
}
net = get_net_ns_by_pid(pid);
@@ -4049,6 +4049,7 @@ static int nl80211_wiphy_netns(struct sk_buff *skb, struct genl_info *info)
put_net(net);
out:
cfg80211_unlock_rdev(rdev);
+ out_rtnl:
rtnl_unlock();
return err;
}
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* WARNING: at net/mac80211/agg-tx.c:145 ___ieee80211_stop_tx_ba_session+0x91/0xa0 [mac80211]
From: Thomas Backlund @ 2009-10-08 21:01 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: linux-wireless@vger.kernel.org
I hit this today:
kernel is a 2.6.31.3 based one built for x86_64
the wireless is connected to a WPA2 encrypted network
Wireless card is:
04:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 4965
AG or AGN [Kedron] Network Connection [8086:4229] (rev 61)
ucode is 228.61.2.24
> [ 108.478772] iwlagn 0000:04:00.0: iwl_tx_agg_start on ra = 00:24:01:38:cb:48 tid = 0
> [ 108.478979] iwlagn 0000:04:00.0: Microcode HW error detected. Restarting.
> [ 108.706591] Registered led device: iwl-phy0::radio
> [ 108.706607] Registered led device: iwl-phy0::assoc
> [ 108.706620] Registered led device: iwl-phy0::RX
> [ 108.706632] Registered led device: iwl-phy0::TX
> [ 109.479039] iwlagn 0000:04:00.0: Stopping AGG while state not IWL_AGG_ON
> [ 109.479045] iwlagn 0000:04:00.0: queue number out of range: 0, must be 7 to 14
> [ 109.479046] ------------[ cut here ]------------
> [ 109.479066] WARNING: at net/mac80211/agg-tx.c:145 ___ieee80211_stop_tx_ba_session+0x91/0xa0 [mac80211]()
> [ 109.479068] Hardware name: TravelMate 5720
> [ 109.479070] Modules linked in: cryptd aes_x86_64 aes_generic af_packet ipv6 binfmt_misc loop fuse dm_mirror dm_region_hash dm_log dm_mod cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table tifm_sd mmc_block tifm_7xx1 tifm_core nvram radeon ttm drm_kms_helper drm i2c_algo_bit btusb bluetooth arc4 ecb snd_hda_codec_realtek snd_hda_intel snd_hda_codec iwlagn pcmcia iwlcore mac80211 snd_hwdep snd_seq_dummy firewire_ohci snd_seq_oss firewire_core snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss cfg80211 snd_pcm crc_itu_t nsc_ircc uvcvideo videodev v4l1_compat v4l2_compat_ioctl32 iTCO_wdt yenta_socket rsrc_nonstatic acer_wmi irda tg3 rfkill ohci1394 ieee1394 snd_timer snd_mixer_oss libphy crc_ccitt snd i2c_i801 joydev serio_raw pcspkr sdhci_pci i2c_core iTCO_vendor_support soundcore evdev sdhci pcmcia_core mmc_core snd_page_alloc led_class rtc_cmos wmi battery container button ac video processor thermal sr_mod output sg ata_piix ahci libata sd_
mod scsi_mod crc_t10dif ext4 jbd2 crc16 uhci_hcd ohci_hcd ehci_hcd usbhid hid usbcore [last unloaded: scsi_wait_scan]
> [ 109.479141] Pid: 0, comm: swapper Not tainted 2.6.31.3-tmb-desktop-1mdv #1
> [ 109.479143] Call Trace:
> [ 109.479145] <IRQ> [<ffffffff81043a88>] warn_slowpath_common+0x78/0xb0
> [ 109.479154] [<ffffffff81043acf>] warn_slowpath_null+0xf/0x20
> [ 109.479161] [<ffffffffa0361081>] ___ieee80211_stop_tx_ba_session+0x91/0xa0 [mac80211]
> [ 109.479169] [<ffffffffa0361286>] sta_addba_resp_timer_expired+0x56/0x90 [mac80211]
> [ 109.479177] [<ffffffffa0361230>] ? sta_addba_resp_timer_expired+0x0/0x90 [mac80211]
> [ 109.479181] [<ffffffff8104e3fb>] run_timer_softirq+0x15b/0x250
> [ 109.479183] [<ffffffff810493bf>] __do_softirq+0xaf/0x140
> [ 109.479187] [<ffffffff8100fa2a>] ? timer_interrupt+0x1a/0x30
> [ 109.479190] [<ffffffff8100d06c>] call_softirq+0x1c/0x30
> [ 109.479192] [<ffffffff8100f075>] do_softirq+0x45/0x80
> [ 109.479194] [<ffffffff81049805>] irq_exit+0x95/0xa0
> [ 109.479196] [<ffffffff8100e600>] do_IRQ+0x70/0xe0
> [ 109.479199] [<ffffffff8100c8d3>] ret_from_intr+0x0/0xa
> [ 109.479201] <EOI> [<ffffffffa016cd25>] ? acpi_idle_enter_bm+0x26c/0x297 [processor]
> [ 109.479215] [<ffffffffa016cd1b>] ? acpi_idle_enter_bm+0x262/0x297 [processor]
> [ 109.479219] [<ffffffff812406eb>] ? cpuidle_idle_call+0x9b/0x100
> [ 109.479221] [<ffffffff8100aa32>] ? cpu_idle+0x62/0xd0
> [ 109.479225] [<ffffffff812db9a1>] ? rest_init+0x81/0x90
> [ 109.479229] [<ffffffff814c01af>] ? start_kernel+0x356/0x362
> [ 109.479232] [<ffffffff814bf808>] ? x86_64_start_reservations+0x125/0x129
> [ 109.479234] [<ffffffff814bf8ed>] ? x86_64_start_kernel+0xe1/0xe8
> [ 109.479236] ---[ end trace d34a38827329a2d4 ]---
--
Thomas
^ permalink raw reply
* Re: [.32-rc3] scheduler: iwlagn consistently high in "waiting for CPU"
From: Frans Pop @ 2009-10-08 20:59 UTC (permalink / raw)
To: Mike Galbraith
Cc: Arjan van de Ven, Linux Kernel Mailing List, Ingo Molnar,
Peter Zijlstra, linux-wireless
In-Reply-To: <1255026217.6643.12.camel@marge.simson.net>
On Thursday 08 October 2009, Mike Galbraith wrote:
> I still see very high latencies coming out of idle (last noted was >
> 300ms, NO_HZ) with this patch,
>
> Like this:
>
> Cause Maximum Percentage
> Scheduler: waiting for cpu 604.2 msec 49.0 %
I'm not seeing anything even remotely like that.
I've tried quieting the system down as much as possible, but that made
no difference. I do have NO_HZ set; will send my full config privately.
If you'd still like me to try your patch I will, but I'm not sure if
that has much value.
Cheers,
FJP
^ permalink raw reply
* [PATCH] libertas: remove double assignment of dev->netdev_ops
From: Luis R. Rodriguez @ 2009-10-08 20:46 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez, Holger Schurig
This came in through the patch titled:
libertas: first stab at cfg80211 support
I only noticed it because it breaks compat-wireless :)
Cc: Holger Schurig <hs4233@mail.mn-solutions.de>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/libertas/main.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/libertas/main.c b/drivers/net/wireless/libertas/main.c
index e6da1df..87bfd17 100644
--- a/drivers/net/wireless/libertas/main.c
+++ b/drivers/net/wireless/libertas/main.c
@@ -1276,7 +1276,6 @@ struct lbs_private *lbs_add_card(void *card, struct device *dmdev)
goto err_adapter;
}
- dev->netdev_ops = &lbs_netdev_ops;
dev->ieee80211_ptr = wdev;
dev->ml_priv = priv;
SET_NETDEV_DEV(dev, dmdev);
--
1.6.0.4
^ permalink raw reply related
* Re: [.32-rc3] scheduler: iwlagn consistently high in "waiting for CPU"
From: Markus Trippelsdorf @ 2009-10-08 20:34 UTC (permalink / raw)
To: Mike Galbraith
Cc: Frans Pop, Arjan van de Ven, Linux Kernel Mailing List,
Ingo Molnar, Peter Zijlstra, linux-wireless
In-Reply-To: <1255026217.6643.12.camel@marge.simson.net>
On Thu, Oct 08, 2009 at 08:23:37PM +0200, Mike Galbraith wrote:
> On Thu, 2009-10-08 at 16:55 +0200, Frans Pop wrote:
> > On Thursday 08 October 2009, Arjan van de Ven wrote:
> > > From: Arjan van de Ven <arjan@linux.intel.com>
> > > Date: Thu, 24 Sep 2009 13:24:16 +0200
> > > Subject: [PATCH] x86, timers: check for pending timers after (device)
> > > interrupts
> > >
> > > Now that range timers and deferred timers are common, I found a
> > > problem with these using the "perf timechart" tool.
> > >
> > > It turns out that on x86, these two 'opportunistic' timers only
> > > get checked when another "real" timer happens.
> > > These opportunistic timers have the objective to save power by
> > > hitchhiking on other wakeups, as to avoid CPU wakeups by themselves
> > > as much as possible.
> >
> > This patch makes quite a difference for me. iwlagn and phy0 now
> > consistently show at ~10 ms or lower.
> >
> > I do still get occasional high latencies, but those are for things like
> > "[rpc_wait_bit_killable]" or "Writing a page to disk", where I guess you'd
> > expect them. Those high latencies are mostly only listed for "Global" and
> > don't translate to individual processes.
>
> I still see very high latencies coming out of idle (last noted was >
> 300ms, NO_HZ) with this patch, and wonder if the hunk below makes any
> difference whatsoever for you. Here, it definitely does. (shouldn't)
I'm also seeing these strange, very high latencies here. Your patch
didn't help unfortunately.
This is from an otherwise idle NO_NZ system:
# ./perf sched latency
-----------------------------------------------------------------------------------------
Task | Runtime ms | Switches | Average delay ms | Maximum delay ms |
-----------------------------------------------------------------------------------------
ksoftirqd/0:4 | 2.216 ms | 170 | avg: 24.235 ms | max: 808.356 ms |
ksoftirqd/1:6 | 2.611 ms | 205 | avg: 4.334 ms | max: 165.553 ms |
migration/2:7 | 0.000 ms | 1 | avg: 3.060 ms | max: 3.060 ms |
With latencytop the ksoftirqd latency is over 1 sec frequently. (Could be
ondemand CPUfreq governor related?)
--
Markus
^ permalink raw reply
* Re: [PATCH] b43: Fix locking problem when stopping rfkill polling
From: Larry Finger @ 2009-10-08 20:23 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, Greg Kroah-Hartman
In-Reply-To: <20091007190106.GB22394@tuxdriver.com>
On 10/07/2009 02:01 PM, John W. Linville wrote:
> OK, but why do we start polling under the lock but stop polling without
> the lock? Should we start polling without holding the lock too?
I see that this patch was committed. I hope that you will be sending
it upstream for 2.6.32. The correct version has been sent to stable
for inclusion in 2.6.31, but as usual, a mainline commit ID will be
needed.
Larry
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox