* RE: [PATCHv2] mac80211: Fix circular locking dependency in ARP filter handling
From: juuso.oikarinen @ 2010-06-08 21:09 UTC (permalink / raw)
To: johannes; +Cc: linville, linux-wireless, reinette.chatre
In-Reply-To: <1276002863.3706.131.camel@jlt3.sipsolutions.net>
From: ext Johannes Berg [johannes@sipsolutions.net]
>
>On Tue, 2010-06-08 at 16:05 +0300, Juuso Oikarinen wrote:
>
>> + promisc = sdata->flags & IEEE80211_SDATA_PROMISC;
>> + if (promisc)
>> + bss_conf->arp_filter_enabled = 0;
>> + else
>> + bss_conf->arp_filter_enabled = sdata->arp_filter_state;
>
>bss_conf->arp_filter_enabled = !promisc && sdata->arp_filter_state;
>
>?
>
>Or if not, use false instead of 0 please.
>
Yes, sure I can change this.
My home WLAN is giving me a headache, so I can't seem to access my work machine just now, but I began to wonder if I managed to create the same locking problem in this patch I had before. To traverse the interface list we need to acquire a lock - either the mutex for the iflist (which seems not to be an option as we also need the mgd mutex - to be locked after the iflist mutex) or the rtnl lock, which I chose to acquire. I quess the filter reconfig work is in the same mac80211 workqueue as the rest of the stuff, so the rtnl lock problem is there again.
-Juuso
>johannes
^ permalink raw reply
* 2.6.35-rc2-git2: Reported regressions from 2.6.34
From: Rafael J. Wysocki @ 2010-06-08 22:06 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
[NOTES:
* This by no means is a complete list, but we only put e-mail reports that
are at least 1 week old into the Bugzilla.
* Quite a few of the already reported regressions may be related to the bug
fixed by 386f40c86d6c8d5b717ef20620af1a750d0dacb4 (Revert "tty: fix a little
bug in scrup, vt.c"), so reporters please retest with this commit applied.]
This message contains a list of some regressions from 2.6.34,
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved regressions from 2.6.34, please let us
know either and we'll add them to the list. Also, please let us know
if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply
to this message with CCs to the people involved in reporting and handling
the issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2010-06-09 15 13 10
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16163
Subject : [2.6.35-rc1 Regression] i915: Commit cfecde causes VGA to stay off
Submitter : David John <davidjon@xenontk.org>
Date : 2010-06-02 12:52 (7 days old)
Message-ID : <4C065423.3000202@xenontk.org>
References : http://marc.info/?l=linux-kernel&m=127548313828613&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16161
Subject : [2.6.35-rc1 regression] sysfs: cannot create duplicate filename ... XVR-600 related?
Submitter : Mikael Pettersson <mikpe@it.uu.se>
Date : 2010-06-01 19:57 (8 days old)
Message-ID : <19461.26166.427857.612983@pilspetsen.it.uu.se>
References : http://marc.info/?l=linux-kernel&m=127542227511925&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16160
Subject : 2.6.35 Radeon KMS power management regression?
Submitter : Nigel Cunningham <ncunningham@crca.org.au>
Date : 2010-06-01 6:23 (8 days old)
Message-ID : <4C04A767.8000209@crca.org.au>
References : http://marc.info/?l=linux-kernel&m=127537343722290&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16145
Subject : Unable to boot after "ACPI: Don't let acpi_pad needlessly mark TSC unstable"
Submitter : Tom Gundersen <teg@jklm.no>
Date : 2010-06-07 13:11 (2 days old)
Handled-By : Venkatesh Pallipadi <venki@google.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16129
Subject : BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2
Submitter : Jan Kreuzer <kontrollator@gmx.de>
Date : 2010-06-05 06:15 (4 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16122
Subject : 2.6.35-rc1: WARNING at fs/fs-writeback.c:1142 __mark_inode_dirty+0x103/0x170
Submitter : Larry Finger <Larry.Finger@lwfinger.net>
Date : 2010-06-04 13:18 (5 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16120
Subject : Oops: 0000 [#1] SMP, unable to handle kernel NULL pointer dereference at (null)
Submitter : Alex Zhavnerchik <alex.vizor@gmail.com>
Date : 2010-06-04 09:25 (5 days old)
Handled-By : Eric Dumazet <eric.dumazet@gmail.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16104
Subject : Radeon KMS does not start after merge of the new PM-Code
Submitter : Jan Kreuzer <kontrollator@gmx.de>
Date : 2010-06-02 07:47 (7 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16090
Subject : sysfs: cannot create duplicate filename
Submitter : Tobias <devnull@plzk.org>
Date : 2010-06-01 15:59 (8 days old)
Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16037
Subject : NULL Pointer dereference in __ir_input_register/budget_ci_attach
Submitter : Sean Finney <seanius@debian.org>
Date : 2010-05-23 19:52 (17 days old)
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16131
Subject : kernel BUG at fs/btrfs/extent-tree.c:4363 (btrfs_free_tree_block)
Submitter : Chow Loong Jin <hyperair@ubuntu.com>
Date : 2010-06-05 18:53 (4 days old)
Handled-By : Yan Zheng <zheng.yan@oracle.com>
Patch : https://patchwork.kernel.org/patch/103235/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16127
Subject : Boot freeze on HP Compaq nx6325 (RS482) with Radeon KMS
Submitter : Jure Repinc <jlp.bugs@gmail.com>
Date : 2010-06-04 21:14 (5 days old)
Handled-By : Dave Airlie <airlied@linux.ie>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=26677
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16092
Subject : Caught 64-bit read from uninitialized memory in memtype_rb_augment_cb
Submitter : Christian Casteyde <casteyde.christian@free.fr>
Date : 2010-06-01 18:08 (8 days old)
Handled-By : Venki <venki@google.com>
Patch : https://bugzilla.kernel.org/show_bug.cgi?id=16092#c2
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.34,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=16055
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
^ permalink raw reply
* USB device that supports master mode?
From: Robert Urban @ 2010-06-09 0:08 UTC (permalink / raw)
To: linux-wireless
Hello Wireless folks,
I'm looking for a USB device that supports master mode, preferably with a
connection for an external antenna.
Does anyone know of specific products that satisy these criteria?
thanks,
Rob Urban
^ permalink raw reply
* Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34
From: Linus Torvalds @ 2010-06-09 1:53 UTC (permalink / raw)
To: Rafael J. Wysocki, Carl Worth, Eric Anholt, Venkatesh Pallipadi,
Jens Axboe, Dave Airlie, Jesse Barnes, Ingo Molnar,
David Härdeman, Mauro Carvalho Chehab, Eric Dumazet
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
In-Reply-To: <Rlf_Qjov7bG.A.a8F.I8rDMB@chimera>
[ Added lots of cc's to direct specific people to look at the regressions
that may or may not be theirs... ]
On Wed, 9 Jun 2010, Rafael J. Wysocki wrote:
>
> * Quite a few of the already reported regressions may be related to the bug
> fixed by 386f40c86d6c8d5b717ef20620af1a750d0dacb4 (Revert "tty: fix a little
> bug in scrup, vt.c"), so reporters please retest with this commit applied.]
>From a quick look, most of them look unrelated to that unfortunate bug.
It's hard to tell for sure, of course (memory corruption can do pretty
much anything), but I'm not seeing the 07200720.. pattern at least.
And some of them do seem to be bisected to likely culprits and/or have
patches that are claimed to have fixed them.
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16163
> Subject : [2.6.35-rc1 Regression] i915: Commit cfecde causes VGA to stay off
> Submitter : David John <davidjon@xenontk.org>
> Date : 2010-06-02 12:52 (7 days old)
> Message-ID : <4C065423.3000202@xenontk.org>
> References : http://marc.info/?l=linux-kernel&m=127548313828613&w=2
That has a "reverting the commit fixes it", and a confirmation from Nick
Bowler.
Eric, Carl: should I just revert that commit? Or do you have a fix?
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16145
> Subject : Unable to boot after "ACPI: Don't let acpi_pad needlessly mark TSC unstable"
> Submitter : Tom Gundersen <teg@jklm.no>
> Date : 2010-06-07 13:11 (2 days old)
> Handled-By : Venkatesh Pallipadi <venki@google.com>
Hmm. This does seem to be a properly bisected commit, but at the same time
it looks from the bugzilla like it's just pure luck on that machine that
the acpi_pad driver happened to mark TSC unstable - so while the commit
bisected is the real one, it's not the "deeper reason" for the problem.
Venki, any updates?
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16129
> Subject : BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2
> Submitter : Jan Kreuzer <kontrollator@gmx.de>
> Date : 2010-06-05 06:15 (4 days old)
This seems to have been introduced by
commit 7cbaef9c83e58bbd4bdd534b09052b6c5ec457d5
Author: Ingo Molnar <mingo@elte.hu>
Date: Sat Nov 8 17:05:38 2008 +0100
sched: optimize sched_clock() a bit
sched_clock() uses cycles_2_ns() needlessly - which is an irq-disabling
variant of __cycles_2_ns().
Most of the time sched_clock() is called with irqs disabled already.
The few places that call it with irqs enabled need to be updated.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
and this seems to be one of those calling cases that need to be updated.
Ingo? The call trace is:
BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2-8/337
caller is native_sched_clock+0x3c/0x68
Pid: 337, comm: jbd2/sda2-8 Not tainted 2.6.35-rc1jan+ #4
Call Trace:
[<ffffffff812362c5>] debug_smp_processor_id+0xc9/0xe4
[<ffffffff8101059d>] native_sched_clock+0x3c/0x68
[<ffffffff8101043d>] sched_clock+0x9/0xd
[<ffffffff81212d7a>] blk_rq_init+0x97/0xa3
[<ffffffff81214d71>] get_request+0x1c4/0x2d0
[<ffffffff81214ea6>] get_request_wait+0x29/0x1a6
[<ffffffff81215537>] __make_request+0x338/0x45b
[<ffffffff812147c2>] generic_make_request+0x2bb/0x330
[<ffffffff81214909>] submit_bio+0xd2/0xef
[<ffffffff811413cb>] submit_bh+0xf4/0x116
[<ffffffff81144853>] block_write_full_page_endio+0x89/0x96
[<ffffffff81144875>] block_write_full_page+0x15/0x17
[<ffffffff8119b00a>] ext4_writepage+0x356/0x36b
[<ffffffff810e1f91>] __writepage+0x1a/0x39
[<ffffffff810e32a6>] write_cache_pages+0x20d/0x346
[<ffffffff810e3406>] generic_writepages+0x27/0x29
[<ffffffff811ca279>] journal_submit_data_buffers+0x110/0x17d
[<ffffffff811ca986>] jbd2_journal_commit_transaction+0x4cb/0x156d
[<ffffffff811d0cba>] kjournald2+0x147/0x37a
(from the bugzilla thing)
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16122
> Subject : 2.6.35-rc1: WARNING at fs/fs-writeback.c:1142 __mark_inode_dirty+0x103/0x170
> Submitter : Larry Finger <Larry.Finger@lwfinger.net>
> Date : 2010-06-04 13:18 (5 days old)
Jens?
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16120
> Subject : Oops: 0000 [#1] SMP, unable to handle kernel NULL pointer dereference at (null)
> Submitter : Alex Zhavnerchik <alex.vizor@gmail.com>
> Date : 2010-06-04 09:25 (5 days old)
> Handled-By : Eric Dumazet <eric.dumazet@gmail.com>
This one seems to have a patch in bugzilla.
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16104
> Subject : Radeon KMS does not start after merge of the new PM-Code
> Submitter : Jan Kreuzer <kontrollator@gmx.de>
> Date : 2010-06-02 07:47 (7 days old)
This one also has a patch in Bugzilla, I think Airlie is just waiting to
calm down his queue and already removed the dependency on the temperature
code. DaveA?
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16161
> Subject : [2.6.35-rc1 regression] sysfs: cannot create duplicate filename ... XVR-600 related?
> Submitter : Mikael Pettersson <mikpe@it.uu.se>
> Date : 2010-06-01 19:57 (8 days old)
> Message-ID : <19461.26166.427857.612983@pilspetsen.it.uu.se>
> References : http://marc.info/?l=linux-kernel&m=127542227511925&w=2
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16090
> Subject : sysfs: cannot create duplicate filename
> Submitter : Tobias <devnull@plzk.org>
> Date : 2010-06-01 15:59 (8 days old)
> Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org>
These two look related. Both are related to that "slot" thing in sysfs
PCI, but only one of them is marked as Jesse's. Jesse?
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16037
> Subject : NULL Pointer dereference in __ir_input_register/budget_ci_attach
> Submitter : Sean Finney <seanius@debian.org>
> Date : 2010-05-23 19:52 (17 days old)
Perhaps related to commit 13c24497086418010bf4f76378bcae241d7f59cd?
David Härdeman, Mauro Carvalho Chehab added to cc.
Linus
^ permalink raw reply
* Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34
From: Mauro Carvalho Chehab @ 2010-06-09 2:26 UTC (permalink / raw)
To: Linus Torvalds
Cc: Rafael J. Wysocki, Carl Worth, Eric Anholt, Venkatesh Pallipadi,
Jens Axboe, Dave Airlie, Jesse Barnes, Ingo Molnar,
David Härdeman, Eric Dumazet, Linux Kernel Mailing List,
Maciej Rutecki, Andrew Morton, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <alpine.LFD.2.00.1006081814240.4506@i5.linux-foundation.org>
Em 08-06-2010 22:53, Linus Torvalds escreveu:
>
>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16037
>> Subject : NULL Pointer dereference in __ir_input_register/budget_ci_attach
>> Submitter : Sean Finney <seanius@debian.org>
>> Date : 2010-05-23 19:52 (17 days old)
>
> Perhaps related to commit 13c24497086418010bf4f76378bcae241d7f59cd?
>
> David Härdeman, Mauro Carvalho Chehab added to cc.
This patch probably solves the issue:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=84b14f181a36eea6591779156ef356f8d198bbfd
The patch were already applied upstream. I've already asked the reporter to test it, via BZ.
Cheers,
Mauro
^ permalink raw reply
* Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34
From: Carl Worth @ 2010-06-09 2:38 UTC (permalink / raw)
To: Linus Torvalds, Rafael J. Wysocki, Eric Anholt,
Venkatesh Pallipadi, Jens Axboe, Dave Airlie, Jesse Barnes,
Ingo Molnar, David Härdeman, Mauro Carvalho Chehab,
Eric Dumazet
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
In-Reply-To: <alpine.LFD.2.00.1006081814240.4506@i5.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]
On Tue, 8 Jun 2010 18:53:55 -0700 (PDT), Linus Torvalds <torvalds@linux-foundation.org> wrote:
> And some of them do seem to be bisected to likely culprits and/or have
> patches that are claimed to have fixed them.
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16163
> > Subject : [2.6.35-rc1 Regression] i915: Commit cfecde causes VGA to stay off
> > Submitter : David John <davidjon@xenontk.org>
> > Date : 2010-06-02 12:52 (7 days old)
> > Message-ID : <4C065423.3000202@xenontk.org>
> > References : http://marc.info/?l=linux-kernel&m=127548313828613&w=2
>
> That has a "reverting the commit fixes it", and a confirmation from Nick
> Bowler.
>
> Eric, Carl: should I just revert that commit? Or do you have a fix?
I'm not aware of any real fix here. That commit isn't supposed to change
much, but it clearly unmasks some broken driver code.
So reverting it for now to hide the broken code from poor users does
seem a good plan to me, (unless Eric has any updates or alternate
suggestions).
-Carl
--
carl.d.worth@intel.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC 3/3] mac80211: Store basic rates for bss when joining ibss network
From: Teemu Paasikivi @ 2010-06-09 4:45 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1276001318.3706.130.camel@jlt3.sipsolutions.net>
On Tue, 2010-06-08 at 14:48 +0200, ext Johannes Berg wrote:
> On Tue, 2010-06-08 at 15:34 +0300, Teemu Paasikivi wrote:
> > When joinig a ibss network, basic rates for bss were not stored. When
> > network was self created, leaving and (re)joining same network has
> > caused basic rates to be left unset. With this patch stored values are
> > used.
>
> > bss = cfg80211_inform_bss_frame(local->hw.wiphy, local->hw.conf.channel,
> > mgmt, skb->len, 0, GFP_KERNEL);
> > +
> > + ibss = (struct ieee80211_bss *)(bss->priv);
>
> Watch out -- bss can be NULL here if memory allocation fails. It's just
> that put_bss(NULL) is valid.
>
That's correct. My fault, how could I miss that? Obviously easily.
> > + for (i = 0; i < sband->n_bitrates; i++) {
> > + u8 basic = 0x00;
> > + if (basic_rates & BIT(i))
> > + basic = 0x80;
> > +
> > + ibss->supp_rates[i] = supp_rates[i] | basic;
> > + }
> > +
> > + ibss->supp_rates_len = i;
> > +
> > cfg80211_put_bss(bss);
>
>
> However this kinda confuses me.
>
> We had a long-standing TODO item on our list at
> http://wireless.kernel.org/en/developers/todo-list
>
> "when leaving an IBSS and we were the only member, remove it from
> cfg80211's BSS list"
>
> Maybe that would help here too?
>
Yes, I think that would propably solve that issue where IBSS was
recreated and requested basic rates are changed.
> However I don't understand the scenario anyway. If you create an IBSS,
> you start beaconing and tell cfg80211 about it with a frame that
> includes the supported and basic rates. Then you leave, but the BSS
> stays around in cfg80211 for 15 seconds. If you re-join within those 15
> seconds, the scan results will pick up the old IBSS that no longer
> exists, and we "join" it rather than creating it.
>
> However -- joining it will take the basic rates from it. So wouldn't you
> get the old basic rates which is fine? What do you mean by "left unset"?
>
By "left unset" I mean that in the sniffer logs there's no rates marked
as basic rates in the beacons. No old ones or new ones.
> What happens if you join an IBSS that already exists?
>
It works, but I haven't captured what's in the air. That's one reason
why I sent these patches as RFC.
Teemu
^ permalink raw reply
* Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34
From: Ingo Molnar @ 2010-06-09 5:34 UTC (permalink / raw)
To: Linus Torvalds, Jens Axboe, Peter Zijlstra
Cc: Rafael J. Wysocki, Carl Worth, Eric Anholt, Venkatesh Pallipadi,
Jens Axboe, Dave Airlie, Jesse Barnes, David H?rdeman,
Mauro Carvalho Chehab, Eric Dumazet, Linux Kernel Mailing List,
Maciej Rutecki, Andrew Morton, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <alpine.LFD.2.00.1006081814240.4506@i5.linux-foundation.org>
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16129
> > Subject : BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2
> > Submitter : Jan Kreuzer <kontrollator@gmx.de>
> > Date : 2010-06-05 06:15 (4 days old)
>
> This seems to have been introduced by
>
> commit 7cbaef9c83e58bbd4bdd534b09052b6c5ec457d5
> Author: Ingo Molnar <mingo@elte.hu>
> Date: Sat Nov 8 17:05:38 2008 +0100
>
> sched: optimize sched_clock() a bit
>
> sched_clock() uses cycles_2_ns() needlessly - which is an irq-disabling
> variant of __cycles_2_ns().
>
> Most of the time sched_clock() is called with irqs disabled already.
> The few places that call it with irqs enabled need to be updated.
>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
>
> and this seems to be one of those calling cases that need to be updated.
That's a commit from 2008.
> Ingo? The call trace is:
>
> BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2-8/337
> caller is native_sched_clock+0x3c/0x68
> Pid: 337, comm: jbd2/sda2-8 Not tainted 2.6.35-rc1jan+ #4
> Call Trace:
> [<ffffffff812362c5>] debug_smp_processor_id+0xc9/0xe4
> [<ffffffff8101059d>] native_sched_clock+0x3c/0x68
> [<ffffffff8101043d>] sched_clock+0x9/0xd
> [<ffffffff81212d7a>] blk_rq_init+0x97/0xa3
> [<ffffffff81214d71>] get_request+0x1c4/0x2d0
> [<ffffffff81214ea6>] get_request_wait+0x29/0x1a6
> [<ffffffff81215537>] __make_request+0x338/0x45b
> [<ffffffff812147c2>] generic_make_request+0x2bb/0x330
> [<ffffffff81214909>] submit_bio+0xd2/0xef
> [<ffffffff811413cb>] submit_bh+0xf4/0x116
> [<ffffffff81144853>] block_write_full_page_endio+0x89/0x96
> [<ffffffff81144875>] block_write_full_page+0x15/0x17
> [<ffffffff8119b00a>] ext4_writepage+0x356/0x36b
> [<ffffffff810e1f91>] __writepage+0x1a/0x39
> [<ffffffff810e32a6>] write_cache_pages+0x20d/0x346
> [<ffffffff810e3406>] generic_writepages+0x27/0x29
> [<ffffffff811ca279>] journal_submit_data_buffers+0x110/0x17d
> [<ffffffff811ca986>] jbd2_journal_commit_transaction+0x4cb/0x156d
> [<ffffffff811d0cba>] kjournald2+0x147/0x37a
>
> (from the bugzilla thing)
The warning was introduced by this fresh commit (and a followup commit) merged
in the .35 merge window:
| commit 9195291e5f05e01d67f9a09c756b8aca8f009089
| Author: Divyesh Shah <dpshah@google.com>
| Date: Thu Apr 1 15:01:41 2010 -0700
|
| blkio: Increment the blkio cgroup stats for real now
IIRC Jens posted a fix for the regression. Jens, what's the status of that?
As the code there started using a raw sched_clock() call for block statistics
purposes, which was a poorly thought out (and buggy) approach:
- it takes timestamps on different cpus and then compares then, but doesnt
consider that sched_clock() is not comparable between CPUs without extra
care
- it doesnt consider the possibility for the sched_clock() result going
backwards on certain platforms (such as x86)
- it doesnt consider preemptability
(There's work ongoing to add a clock variant that can be used for such
purposes, but that's .36 fodder.)
Thanks,
Ingo
^ permalink raw reply
* Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34
From: Eric Dumazet @ 2010-06-09 6:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: Rafael J. Wysocki, Carl Worth, Eric Anholt, Venkatesh Pallipadi,
Jens Axboe, Dave Airlie, Jesse Barnes, Ingo Molnar,
David Härdeman, Mauro Carvalho Chehab,
Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
In-Reply-To: <alpine.LFD.2.00.1006081814240.4506@i5.linux-foundation.org>
Le mardi 08 juin 2010 à 18:53 -0700, Linus Torvalds a écrit :
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16120
> > Subject : Oops: 0000 [#1] SMP, unable to handle kernel NULL pointer dereference at (null)
> > Submitter : Alex Zhavnerchik <alex.vizor@gmail.com>
> > Date : 2010-06-04 09:25 (5 days old)
> > Handled-By : Eric Dumazet <eric.dumazet@gmail.com>
>
> This one seems to have a patch in bugzilla.
Yep, commit 035320d54758e21227987e3aae0d46e7a04f4ddc in David net-2.6
tree, i'll be included in its next pull request.
http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=035320d54758e21227987e3aae0d46e7a04f4ddc
Thanks
^ permalink raw reply
* Compilation problems with Linux-2.6.34 and compat-wireless-2010-06-05
From: Jaroslav Fojtik @ 2010-06-09 6:50 UTC (permalink / raw)
To: linux-wireless
Dears,
could you fix this compilation problem:
make -C /usr/src/linux-2.6.34 M=/I/USR_SRC/compat-wireless-2010-06-05 modules
make[1]: Entering directory `/I/USR_SRC/linux-2.6.34'
CC [M] /I/USR_SRC/compat-wireless-2010-06-05/drivers/net/wireless/ipw2x00/ipw2100.o
/I/USR_SRC/compat-wireless-2010-06-05/drivers/net/wireless/ipw2x00/ipw2100.c: In function
'ipw2100_alloc_device':
/I/USR_SRC/compat-wireless-2010-06-05/drivers/net/wireless/ipw2x00/ipw2100.c:6138: error:
'struct net_device' has no member named 'wireless_handlers'
/I/USR_SRC/compat-wireless-2010-06-05/drivers/net/wireless/ipw2x00/ipw2100.c:6144: error:
'struct net_device' has no member named 'wireless_data'
/I/USR_SRC/compat-wireless-2010-06-05/drivers/net/wireless/ipw2x00/ipw2100.c: At top
level:
/I/USR_SRC/compat-wireless-2010-06-05/drivers/net/wireless/ipw2x00/ipw2100.c:8406: error:
unknown field 'num_private' specified in initializer
/I/USR_SRC/compat-wireless-2010-06-05/drivers/net/wireless/ipw2x00/ipw2100.c:8406:
warning: initialization makes pointer from integer without a cast
/I/USR_SRC/compat-wireless-2010-06-05/drivers/net/wireless/ipw2x00/ipw2100.c:8407: error:
unknown field 'num_private_args' specified in initializer
/I/USR_SRC/compat-wireless-2010-06-05/drivers/net/wireless/ipw2x00/ipw2100.c:8407:
warning: excess elements in struct initializer
/I/USR_SRC/compat-wireless-2010-06-05/drivers/net/wireless/ipw2x00/ipw2100.c:8407:
warning: (near initialization for 'ipw2100_wx_handler_def')
/I/USR_SRC/compat-wireless-2010-06-05/drivers/net/wireless/ipw2x00/ipw2100.c:8408: error:
unknown field 'private' specified in initializer
/I/USR_SRC/compat-wireless-2010-06-05/drivers/net/wireless/ipw2x00/ipw2100.c:8408:
warning: excess elements in struct initializer
/I/USR_SRC/compat-wireless-2010-06-05/drivers/net/wireless/ipw2x00/ipw2100.c:8408:
warning: (near initialization for 'ipw2100_wx_handler_def')
/I/USR_SRC/compat-wireless-2010-06-05/drivers/net/wireless/ipw2x00/ipw2100.c:8409: error:
unknown field 'private_args' specified in initializer
/I/USR_SRC/compat-wireless-2010-06-05/drivers/net/wireless/ipw2x00/ipw2100.c:8409:
warning: excess elements in struct initializer
/I/USR_SRC/compat-wireless-2010-06-05/drivers/net/wireless/ipw2x00/ipw2100.c:8409:
warning: (near initialization for 'ipw2100_wx_handler_def')
make[4]: *** [/I/USR_SRC/compat-wireless-2010-06-
05/drivers/net/wireless/ipw2x00/ipw2100.o] Error 1
make[3]: *** [/I/USR_SRC/compat-wireless-2010-06-05/drivers/net/wireless/ipw2x00] Error 2
make[2]: *** [/I/USR_SRC/compat-wireless-2010-06-05/drivers/net/wireless] Error 2
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [_module_/I/USR_SRC/compat-wireless-2010-06-05] Error 2
make[1]: Leaving directory `/I/USR_SRC/linux-2.6.34'
make: *** [modules] Error 2
regards
Jara
^ permalink raw reply
* [PATCHv3] mac80211: Fix circular locking dependency in ARP filter handling
From: Juuso Oikarinen @ 2010-06-09 6:50 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, reinette.chatre
There is a circular locking dependency when configuring the
hardware ARP filters on association, occurring when flushing the mac80211
workqueue. This is what happens:
[ 92.026800] =======================================================
[ 92.030507] [ INFO: possible circular locking dependency detected ]
[ 92.030507] 2.6.34-04781-g2b2c009 #85
[ 92.030507] -------------------------------------------------------
[ 92.030507] modprobe/5225 is trying to acquire lock:
[ 92.030507] ((wiphy_name(local->hw.wiphy))){+.+.+.}, at: [<ffffffff8105b5c0>] flush_workq
ueue+0x0/0xb0
[ 92.030507]
[ 92.030507] but task is already holding lock:
[ 92.030507] (rtnl_mutex){+.+.+.}, at: [<ffffffff812b9ce2>] rtnl_lock+0x12/0x20
[ 92.030507]
[ 92.030507] which lock already depends on the new lock.
[ 92.030507]
[ 92.030507]
[ 92.030507] the existing dependency chain (in reverse order) is:
[ 92.030507]
[ 92.030507] -> #2 (rtnl_mutex){+.+.+.}:
[ 92.030507] [<ffffffff810761fb>] lock_acquire+0xdb/0x110
[ 92.030507] [<ffffffff81341754>] mutex_lock_nested+0x44/0x300
[ 92.030507] [<ffffffff812b9ce2>] rtnl_lock+0x12/0x20
[ 92.030507] [<ffffffffa022d47c>] ieee80211_assoc_done+0x6c/0xe0 [mac80211]
[ 92.030507] [<ffffffffa022f2ad>] ieee80211_work_work+0x31d/0x1280 [mac80211]
[ 92.030507] -> #1 ((&local->work_work)){+.+.+.}:
[ 92.030507] [<ffffffff810761fb>] lock_acquire+0xdb/0x110
[ 92.030507] [<ffffffff8105a51a>] worker_thread+0x22a/0x370
[ 92.030507] [<ffffffff8105ecc6>] kthread+0x96/0xb0
[ 92.030507] [<ffffffff81003a94>] kernel_thread_helper+0x4/0x10
[ 92.030507]
[ 92.030507] -> #0 ((wiphy_name(local->hw.wiphy))){+.+.+.}:
[ 92.030507] [<ffffffff81075fdc>] __lock_acquire+0x1c0c/0x1d50
[ 92.030507] [<ffffffff810761fb>] lock_acquire+0xdb/0x110
[ 92.030507] [<ffffffff8105b60e>] flush_workqueue+0x4e/0xb0
[ 92.030507] [<ffffffffa023ff7b>] ieee80211_stop_device+0x2b/0xb0 [mac80211]
[ 92.030507] [<ffffffffa0231635>] ieee80211_stop+0x3e5/0x680 [mac80211]
The locking in this case is quite complex. Fix the problem by rewriting the
way the hardware ARP filter list is handled - i.e. make a copy of the address
list to the bss_conf struct, and provide that list to the hardware driver
when needed.
Additionally, this patch ensures that hardware ARP filtering is not enabled
when promiscuous mode is set.
Reported-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
v3: - queue reconfig filter work to kernel default wq instead of mac80211 wq
- initialize arp_filter_state to "true" in if_add
include/net/mac80211.h | 34 +++++----
net/mac80211/driver-ops.h | 17 -----
net/mac80211/driver-trace.h | 25 -------
net/mac80211/ieee80211_i.h | 2 +
net/mac80211/iface.c | 8 ++-
net/mac80211/main.c | 166 +++++++++++++++++++++++++++++--------------
net/mac80211/mlme.c | 39 ++++++----
7 files changed, 164 insertions(+), 127 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index e3c1d47..f409d00 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -19,7 +19,6 @@
#include <linux/wireless.h>
#include <linux/device.h>
#include <linux/ieee80211.h>
-#include <linux/inetdevice.h>
#include <net/cfg80211.h>
/**
@@ -147,6 +146,7 @@ struct ieee80211_low_level_stats {
* enabled/disabled (beaconing modes)
* @BSS_CHANGED_CQM: Connection quality monitor config changed
* @BSS_CHANGED_IBSS: IBSS join status changed
+ * @BSS_CHANGED_ARP_FILTER: Hardware ARP filter address list or state changed.
*/
enum ieee80211_bss_change {
BSS_CHANGED_ASSOC = 1<<0,
@@ -161,10 +161,18 @@ enum ieee80211_bss_change {
BSS_CHANGED_BEACON_ENABLED = 1<<9,
BSS_CHANGED_CQM = 1<<10,
BSS_CHANGED_IBSS = 1<<11,
+ BSS_CHANGED_ARP_FILTER = 1<<12,
/* when adding here, make sure to change ieee80211_reconfig */
};
+/*
+ * The maximum number of IPv4 addresses listed for ARP filtering. If the number
+ * of addresses for an interface increase beyond this value, hardware ARP
+ * filtering will be disabled.
+ */
+#define IEEE80211_BSS_ARP_ADDR_LIST_LEN 4
+
/**
* struct ieee80211_bss_conf - holds the BSS's changing parameters
*
@@ -200,6 +208,14 @@ enum ieee80211_bss_change {
* @cqm_rssi_thold: Connection quality monitor RSSI threshold, a zero value
* implies disabled
* @cqm_rssi_hyst: Connection quality monitor RSSI hysteresis
+ * @arp_addr_list: List of IPv4 addresses for hardware ARP filtering. The
+ * may filter ARP queries targeted for other addresses than listed here.
+ * The driver must allow ARP queries targeted for all address listed here
+ * to pass through. An empty list implies no ARP queries need to pass.
+ * @arp_addr_cnt: Number of addresses currently on the list.
+ * @arp_filter_enabled: Enable ARP filtering - if enabled, the hardware may
+ * filter ARP queries based on the @arp_addr_list, if disabled, the
+ * hardware must not perform any ARP filtering.
*/
struct ieee80211_bss_conf {
const u8 *bssid;
@@ -220,6 +236,9 @@ struct ieee80211_bss_conf {
s32 cqm_rssi_thold;
u32 cqm_rssi_hyst;
enum nl80211_channel_type channel_type;
+ __be32 arp_addr_list[IEEE80211_BSS_ARP_ADDR_LIST_LEN];
+ u8 arp_addr_cnt;
+ bool arp_filter_enabled;
};
/**
@@ -1529,16 +1548,6 @@ enum ieee80211_ampdu_mlme_action {
* of the bss parameters has changed when a call is made. The callback
* can sleep.
*
- * @configure_arp_filter: Configuration function for hardware ARP query filter.
- * This function is called with all the IP addresses configured to the
- * interface as argument - all ARP queries targeted to any of these
- * addresses must pass through. If the hardware filter does not support
- * enought addresses, hardware filtering must be disabled. The ifa_list
- * argument may be NULL, indicating that filtering must be disabled.
- * This function is called upon association complete with current
- * address(es), and while associated whenever the IP address(es) change.
- * The callback can sleep.
- *
* @prepare_multicast: Prepare for multicast filter configuration.
* This callback is optional, and its return value is passed
* to configure_filter(). This callback must be atomic.
@@ -1678,9 +1687,6 @@ struct ieee80211_ops {
struct ieee80211_vif *vif,
struct ieee80211_bss_conf *info,
u32 changed);
- int (*configure_arp_filter)(struct ieee80211_hw *hw,
- struct ieee80211_vif *vif,
- struct in_ifaddr *ifa_list);
u64 (*prepare_multicast)(struct ieee80211_hw *hw,
struct netdev_hw_addr_list *mc_list);
void (*configure_filter)(struct ieee80211_hw *hw,
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index d1139e4..bbea3bc 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -83,23 +83,6 @@ static inline void drv_bss_info_changed(struct ieee80211_local *local,
trace_drv_bss_info_changed(local, sdata, info, changed);
}
-struct in_ifaddr;
-static inline int drv_configure_arp_filter(struct ieee80211_local *local,
- struct ieee80211_vif *vif,
- struct in_ifaddr *ifa_list)
-{
- int ret = 0;
-
- might_sleep();
-
- if (local->ops->configure_arp_filter)
- ret = local->ops->configure_arp_filter(&local->hw, vif,
- ifa_list);
-
- trace_drv_configure_arp_filter(local, vif_to_sdata(vif), ifa_list, ret);
- return ret;
-}
-
static inline u64 drv_prepare_multicast(struct ieee80211_local *local,
struct netdev_hw_addr_list *mc_list)
{
diff --git a/net/mac80211/driver-trace.h b/net/mac80211/driver-trace.h
index 6b90630..1e293df 100644
--- a/net/mac80211/driver-trace.h
+++ b/net/mac80211/driver-trace.h
@@ -219,31 +219,6 @@ TRACE_EVENT(drv_bss_info_changed,
)
);
-TRACE_EVENT(drv_configure_arp_filter,
- TP_PROTO(struct ieee80211_local *local,
- struct ieee80211_sub_if_data *sdata,
- struct in_ifaddr *ifa_list, int ret),
-
- TP_ARGS(local, sdata, ifa_list, ret),
-
- TP_STRUCT__entry(
- LOCAL_ENTRY
- VIF_ENTRY
- __field(int, ret)
- ),
-
- TP_fast_assign(
- LOCAL_ASSIGN;
- VIF_ASSIGN;
- __entry->ret = ret;
- ),
-
- TP_printk(
- VIF_PR_FMT LOCAL_PR_FMT " ret:%d",
- VIF_PR_ARG, LOCAL_PR_ARG, __entry->ret
- )
-);
-
TRACE_EVENT(drv_prepare_multicast,
TP_PROTO(struct ieee80211_local *local, int mc_count, u64 ret),
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 4d3883e..79e366e 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -517,6 +517,8 @@ struct ieee80211_sub_if_data {
u16 sequence_number;
+ bool arp_filter_state;
+
/*
* AP this belongs to: self in AP mode and
* corresponding AP in VLAN mode, NULL for
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 1afa9ec..4b64d85 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -588,7 +588,12 @@ static void ieee80211_set_multicast_list(struct net_device *dev)
spin_lock_bh(&local->filter_lock);
__hw_addr_sync(&local->mc_list, &dev->mc, dev->addr_len);
spin_unlock_bh(&local->filter_lock);
- ieee80211_queue_work(&local->hw, &local->reconfig_filter);
+
+ /*
+ * This work cannot be queued in the mac80211 workqueue as it requires
+ * rtnl_lock().
+ */
+ schedule_work(&local->reconfig_filter);
}
/*
@@ -959,6 +964,7 @@ int ieee80211_if_add(struct ieee80211_local *local, const char *name,
sdata->wdev.wiphy = local->hw.wiphy;
sdata->local = local;
sdata->dev = ndev;
+ sdata->arp_filter_state = true;
for (i = 0; i < IEEE80211_FRAGMENT_MAX; i++)
skb_queue_head_init(&sdata->fragments[i].skb_list);
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 5706156..b64066c 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -20,6 +20,7 @@
#include <linux/rtnetlink.h>
#include <linux/bitmap.h>
#include <linux/pm_qos_params.h>
+#include <linux/inetdevice.h>
#include <net/net_namespace.h>
#include <net/cfg80211.h>
@@ -84,12 +85,123 @@ void ieee80211_configure_filter(struct ieee80211_local *local)
local->filter_flags = new_flags & ~(1<<31);
}
+#ifdef CONFIG_INET
+static void ieee80211_reconfig_arp_filter(struct ieee80211_local *local)
+{
+ struct ieee80211_sub_if_data *sdata;
+ struct ieee80211_if_managed *ifmgd;
+ struct ieee80211_bss_conf *bss_conf;
+ u32 changed;
+ bool promisc;
+ bool old_state, new_state;
+
+ /* Check ARP filtering state for each interface */
+ rtnl_lock();
+ list_for_each_entry(sdata, &local->interfaces, list) {
+ if (sdata->vif.type != NL80211_IFTYPE_STATION)
+ continue;
+
+ ifmgd = &sdata->u.mgd;
+ mutex_lock(&ifmgd->mtx);
+ if (!ifmgd->associated) {
+ mutex_unlock(&ifmgd->mtx);
+ continue;
+ }
+
+ bss_conf = &sdata->vif.bss_conf;
+
+ old_state = !!(bss_conf->arp_filter_enabled);
+
+ promisc = sdata->flags & IEEE80211_SDATA_PROMISC;
+ new_state = !promisc && sdata->arp_filter_state;
+ bss_conf->arp_filter_enabled = new_state;
+
+ if (old_state != new_state) {
+ changed = BSS_CHANGED_ARP_FILTER;
+ ieee80211_bss_info_change_notify(sdata, changed);
+ }
+
+ mutex_unlock(&ifmgd->mtx);
+ }
+ rtnl_unlock();
+}
+
+static int ieee80211_ifa_changed(struct notifier_block *nb,
+ unsigned long data, void *arg)
+{
+ struct in_ifaddr *ifa = arg;
+ struct ieee80211_local *local =
+ container_of(nb, struct ieee80211_local,
+ ifa_notifier);
+ struct net_device *ndev = ifa->ifa_dev->dev;
+ struct wireless_dev *wdev = ndev->ieee80211_ptr;
+ struct in_device *idev;
+ struct ieee80211_sub_if_data *sdata;
+ struct ieee80211_bss_conf *bss_conf;
+ struct ieee80211_if_managed *ifmgd;
+ int c = 0;
+
+ /* Make sure it's our interface that got changed */
+ if (!wdev)
+ return NOTIFY_DONE;
+
+ if (wdev->wiphy != local->hw.wiphy)
+ return NOTIFY_DONE;
+
+ sdata = IEEE80211_DEV_TO_SUB_IF(ndev);
+ bss_conf = &sdata->vif.bss_conf;
+
+ /* ARP filtering is only supported in managed mode */
+ if (sdata->vif.type != NL80211_IFTYPE_STATION)
+ return NOTIFY_DONE;
+
+ idev = sdata->dev->ip_ptr;
+ if (!idev)
+ return NOTIFY_DONE;
+
+ ifmgd = &sdata->u.mgd;
+ mutex_lock(&ifmgd->mtx);
+
+ /* Copy the addresses to the bss_conf list */
+ ifa = idev->ifa_list;
+ while (c < IEEE80211_BSS_ARP_ADDR_LIST_LEN && ifa) {
+ bss_conf->arp_addr_list[c] = ifa->ifa_address;
+ ifa = ifa->ifa_next;
+ c++;
+ }
+
+ /* If not all addresses fit the list, disable filtering */
+ if (ifa) {
+ sdata->arp_filter_state = false;
+ c = 0;
+ } else {
+ sdata->arp_filter_state = true;
+ }
+ bss_conf->arp_addr_cnt = c;
+
+ /* Configure driver only if associated and not in promiscuous mode */
+ if (ifmgd->associated && !(sdata->flags & IEEE80211_SDATA_PROMISC)) {
+ bss_conf->arp_filter_enabled = sdata->arp_filter_state;
+ ieee80211_bss_info_change_notify(sdata,
+ BSS_CHANGED_ARP_FILTER);
+ }
+
+ mutex_unlock(&ifmgd->mtx);
+
+ return NOTIFY_DONE;
+}
+#endif
+
static void ieee80211_reconfig_filter(struct work_struct *work)
{
struct ieee80211_local *local =
container_of(work, struct ieee80211_local, reconfig_filter);
ieee80211_configure_filter(local);
+
+#ifdef CONFIG_INET
+ ieee80211_reconfig_arp_filter(local);
+#endif
}
int ieee80211_hw_config(struct ieee80211_local *local, u32 changed)
@@ -329,60 +441,6 @@ static void ieee80211_recalc_smps_work(struct work_struct *work)
mutex_unlock(&local->iflist_mtx);
}
-#ifdef CONFIG_INET
-int ieee80211_set_arp_filter(struct ieee80211_sub_if_data *sdata)
-{
- struct in_device *idev;
- int ret = 0;
-
- BUG_ON(!sdata);
- ASSERT_RTNL();
-
- idev = sdata->dev->ip_ptr;
- if (!idev)
- return 0;
-
- ret = drv_configure_arp_filter(sdata->local, &sdata->vif,
- idev->ifa_list);
- return ret;
-}
-
-static int ieee80211_ifa_changed(struct notifier_block *nb,
- unsigned long data, void *arg)
-{
- struct in_ifaddr *ifa = arg;
- struct ieee80211_local *local =
- container_of(nb, struct ieee80211_local,
- ifa_notifier);
- struct net_device *ndev = ifa->ifa_dev->dev;
- struct wireless_dev *wdev = ndev->ieee80211_ptr;
- struct ieee80211_sub_if_data *sdata;
- struct ieee80211_if_managed *ifmgd;
-
- /* Make sure it's our interface that got changed */
- if (!wdev)
- return NOTIFY_DONE;
-
- if (wdev->wiphy != local->hw.wiphy)
- return NOTIFY_DONE;
-
- /* We are concerned about IP addresses only when associated */
- sdata = IEEE80211_DEV_TO_SUB_IF(ndev);
-
- /* ARP filtering is only supported in managed mode */
- if (sdata->vif.type != NL80211_IFTYPE_STATION)
- return NOTIFY_DONE;
-
- ifmgd = &sdata->u.mgd;
- mutex_lock(&ifmgd->mtx);
- if (ifmgd->associated)
- ieee80211_set_arp_filter(sdata);
- mutex_unlock(&ifmgd->mtx);
-
- return NOTIFY_DONE;
-}
-#endif
-
struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,
const struct ieee80211_ops *ops)
{
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index ac68c41..d328e9a 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -806,11 +806,12 @@ static void ieee80211_set_associated(struct ieee80211_sub_if_data *sdata,
{
struct ieee80211_bss *bss = (void *)cbss->priv;
struct ieee80211_local *local = sdata->local;
+ struct ieee80211_bss_conf *bss_conf = &sdata->vif.bss_conf;
bss_info_changed |= BSS_CHANGED_ASSOC;
/* set timing information */
- sdata->vif.bss_conf.beacon_int = cbss->beacon_interval;
- sdata->vif.bss_conf.timestamp = cbss->tsf;
+ bss_conf->beacon_int = cbss->beacon_interval;
+ bss_conf->timestamp = cbss->tsf;
bss_info_changed |= BSS_CHANGED_BEACON_INT;
bss_info_changed |= ieee80211_handle_bss_capability(sdata,
@@ -835,7 +836,7 @@ static void ieee80211_set_associated(struct ieee80211_sub_if_data *sdata,
ieee80211_led_assoc(local, 1);
- sdata->vif.bss_conf.assoc = 1;
+ bss_conf->assoc = 1;
/*
* For now just always ask the driver to update the basic rateset
* when we have associated, we aren't checking whether it actually
@@ -848,9 +849,18 @@ static void ieee80211_set_associated(struct ieee80211_sub_if_data *sdata,
/* Tell the driver to monitor connection quality (if supported) */
if ((local->hw.flags & IEEE80211_HW_SUPPORTS_CQM_RSSI) &&
- sdata->vif.bss_conf.cqm_rssi_thold)
+ bss_conf->cqm_rssi_thold)
bss_info_changed |= BSS_CHANGED_CQM;
+#ifdef CONFIG_INET
+ /* Enable ARP filtering unless in promisc mode */
+ if (!(sdata->flags & IEEE80211_SDATA_PROMISC) &&
+ bss_conf->arp_filter_enabled != sdata->arp_filter_state) {
+ bss_conf->arp_filter_enabled = sdata->arp_filter_state;
+ bss_info_changed |= BSS_CHANGED_ARP_FILTER;
+ }
+#endif
+
ieee80211_bss_info_change_notify(sdata, bss_info_changed);
mutex_lock(&local->iflist_mtx);
@@ -932,6 +942,13 @@ static void ieee80211_set_disassoc(struct ieee80211_sub_if_data *sdata,
ieee80211_hw_config(local, config_changed);
+ /* Disable ARP filtering */
+ if (sdata->vif.bss_conf.arp_filter_enabled) {
+ sdata->vif.bss_conf.arp_filter_enabled = false;
+ changed |= BSS_CHANGED_ARP_FILTER;
+ }
+
+
/* The BSSID (not really interesting) and HT changed */
changed |= BSS_CHANGED_BSSID | BSS_CHANGED_HT;
ieee80211_bss_info_change_notify(sdata, changed);
@@ -2116,19 +2133,9 @@ static enum work_done_result ieee80211_assoc_done(struct ieee80211_work *wk,
cfg80211_send_assoc_timeout(wk->sdata->dev,
wk->filter_ta);
return WORK_DONE_DESTROY;
-#ifdef CONFIG_INET
- } else {
- mutex_unlock(&wk->sdata->u.mgd.mtx);
-
- /*
- * configure ARP filter IP addresses to the driver,
- * intentionally outside the mgd mutex.
- */
- rtnl_lock();
- ieee80211_set_arp_filter(wk->sdata);
- rtnl_unlock();
-#endif
}
+
+ mutex_unlock(&wk->sdata->u.mgd.mtx);
}
cfg80211_send_rx_assoc(wk->sdata->dev, skb->data, skb->len);
--
1.6.3.3
^ permalink raw reply related
* [PATCH] mac80211: Fix ps-qos network latency handling
From: Juuso Oikarinen @ 2010-06-09 6:51 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
The ps-qos latency handling is broken. It uses predetermined latency values
to select specific dynamic PS timeouts. With common AP configurations, these
values overlap with beacon interval and are therefore essentially useless
(for network latencies less than the beacon interval, PSM is disabled.)
This patch remedies the problem by replacing the predetermined network latency
values with one high value (1900ms) which is used to go trigger full psm. For
backwards compatibility, the value 2000ms is still mapped to a dynamic ps
timeout of 100ms.
Currently also the mac80211 internal value for storing user space configured
dynamic PSM values is incorrectly in the driver visible ieee80211_conf struct.
Move it to the ieee80211_local struct.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
include/net/mac80211.h | 5 +----
net/mac80211/cfg.c | 5 ++---
net/mac80211/ieee80211_i.h | 6 ++++++
net/mac80211/main.c | 2 +-
net/mac80211/mlme.c | 16 ++++++----------
5 files changed, 16 insertions(+), 18 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index e3c1d47..d195992 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -674,9 +674,6 @@ enum ieee80211_smps_mode {
* @dynamic_ps_timeout: The dynamic powersave timeout (in ms), see the
* powersave documentation below. This variable is valid only when
* the CONF_PS flag is set.
- * @dynamic_ps_forced_timeout: The dynamic powersave timeout (in ms) configured
- * by cfg80211 (essentially, wext) If set, this value overrules the value
- * chosen by mac80211 based on ps qos network latency.
*
* @power_level: requested transmit power (in dBm)
*
@@ -696,7 +693,7 @@ enum ieee80211_smps_mode {
*/
struct ieee80211_conf {
u32 flags;
- int power_level, dynamic_ps_timeout, dynamic_ps_forced_timeout;
+ int power_level, dynamic_ps_timeout;
int max_sleep_period;
u16 listen_interval;
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 952845e..2b1531f 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1446,7 +1446,6 @@ static int ieee80211_set_power_mgmt(struct wiphy *wiphy, struct net_device *dev,
{
struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
struct ieee80211_local *local = wdev_priv(dev->ieee80211_ptr);
- struct ieee80211_conf *conf = &local->hw.conf;
if (sdata->vif.type != NL80211_IFTYPE_STATION)
return -EOPNOTSUPP;
@@ -1455,11 +1454,11 @@ static int ieee80211_set_power_mgmt(struct wiphy *wiphy, struct net_device *dev,
return -EOPNOTSUPP;
if (enabled == sdata->u.mgd.powersave &&
- timeout == conf->dynamic_ps_forced_timeout)
+ timeout == local->dynamic_ps_forced_timeout)
return 0;
sdata->u.mgd.powersave = enabled;
- conf->dynamic_ps_forced_timeout = timeout;
+ local->dynamic_ps_forced_timeout = timeout;
/* no change, but if automatic follow powersave */
mutex_lock(&sdata->u.mgd.mtx);
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 4d3883e..a401da3 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -853,6 +853,12 @@ struct ieee80211_local {
struct notifier_block network_latency_notifier;
struct notifier_block ifa_notifier;
+ /*
+ * The dynamic ps timeout configured from user space via WEXT -
+ * this will override whatever chosen by mac80211 internally.
+ */
+ int dynamic_ps_forced_timeout;
+
int user_power_level; /* in dBm */
int power_constr_level; /* in dBm */
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 5706156..f7b269b 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -626,7 +626,7 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
local->hw.conf.listen_interval = local->hw.max_listen_interval;
- local->hw.conf.dynamic_ps_forced_timeout = -1;
+ local->dynamic_ps_forced_timeout = -1;
result = sta_info_start(local);
if (result < 0)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index ac68c41..cb12932 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -561,23 +561,19 @@ void ieee80211_recalc_ps(struct ieee80211_local *local, s32 latency)
beaconint_us = ieee80211_tu_to_usec(
found->vif.bss_conf.beacon_int);
- timeout = local->hw.conf.dynamic_ps_forced_timeout;
+ timeout = local->dynamic_ps_forced_timeout;
if (timeout < 0) {
/*
+ * Go to full PSM if the user configures a very low
+ * latency requirement.
* The 2 second value is there for compatibility until
* the PM_QOS_NETWORK_LATENCY is configured with real
* values.
*/
- if (latency == 2000000000)
- timeout = 100;
- else if (latency <= 50000)
- timeout = 300;
- else if (latency <= 100000)
- timeout = 100;
- else if (latency <= 500000)
- timeout = 50;
- else
+ if (latency > 1900000000 && latency != 2000000000)
timeout = 0;
+ else
+ timeout = 100;
}
local->hw.conf.dynamic_ps_timeout = timeout;
--
1.6.3.3
^ permalink raw reply related
* [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: Dmytro Milinevskyy @ 2010-06-09 7:31 UTC (permalink / raw)
To: ath5k-devel
Cc: Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez, Bob Copeland,
John W. Linville, GeunSik Lim, Greg Kroah-Hartman, Lukas Turek,
Mark Hindley, Jiri Kosina, Kalle Valo, Keng-Yu Lin, Luca Verdesca,
Shahar Or, linux-wireless, netdev, linux-kernel
Hi!
Here is the patch to disable ath5k leds support on build stage.
However if the leds support was enabled do not force selection of 802.11 leds layer.
Depency on LEDS_CLASS is kept.
Suggestion given by Pavel Roskin and Bob Copeland applied.
Changes from the previos version of the patch:
- Use bool directive in Kconfig for switching LEDs support
- Move ath5k_hw_set_ledstate into led.c and change its semantic to align with other leds routines
Regards,
--Dima
Signed-off-by: Dmytro Milinevskyy <milinevskyy@gmail.com>
---
drivers/net/wireless/ath/ath5k/Kconfig | 12 +++++--
drivers/net/wireless/ath/ath5k/Makefile | 2 +-
drivers/net/wireless/ath/ath5k/ath5k.h | 21 +++++++++++-
drivers/net/wireless/ath/ath5k/attach.c | 2 +-
drivers/net/wireless/ath/ath5k/base.c | 6 ++--
drivers/net/wireless/ath/ath5k/base.h | 11 ++++--
drivers/net/wireless/ath/ath5k/gpio.c | 52 ------------------------------
drivers/net/wireless/ath/ath5k/led.c | 53 +++++++++++++++++++++++++++++++
8 files changed, 94 insertions(+), 65 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/Kconfig b/drivers/net/wireless/ath/ath5k/Kconfig
index eb83b7b..6b2a682 100644
--- a/drivers/net/wireless/ath/ath5k/Kconfig
+++ b/drivers/net/wireless/ath/ath5k/Kconfig
@@ -1,9 +1,6 @@
config ATH5K
tristate "Atheros 5xxx wireless cards support"
depends on PCI && MAC80211
- select MAC80211_LEDS
- select LEDS_CLASS
- select NEW_LEDS
---help---
This module adds support for wireless adapters based on
Atheros 5xxx chipset.
@@ -18,6 +15,15 @@ config ATH5K
If you choose to build a module, it'll be called ath5k. Say M if
unsure.
+
+config ATH5K_LEDS
+ bool "Atheros 5xxx wireless cards LEDs support"
+ depends on ATH5K
+ select NEW_LEDS
+ select LEDS_CLASS
+ ---help---
+ Atheros 5xxx LED support.
+
config ATH5K_DEBUG
bool "Atheros 5xxx debugging"
depends on ATH5K
diff --git a/drivers/net/wireless/ath/ath5k/Makefile b/drivers/net/wireless/ath/ath5k/Makefile
index cc09595..6d552dd 100644
--- a/drivers/net/wireless/ath/ath5k/Makefile
+++ b/drivers/net/wireless/ath/ath5k/Makefile
@@ -10,8 +10,8 @@ ath5k-y += phy.o
ath5k-y += reset.o
ath5k-y += attach.o
ath5k-y += base.o
-ath5k-y += led.o
ath5k-y += rfkill.o
ath5k-y += ani.o
ath5k-$(CONFIG_ATH5K_DEBUG) += debug.o
+ath5k-$(CONFIG_ATH5K_LEDS) += led.o
obj-$(CONFIG_ATH5K) += ath5k.o
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h
index 2785946..202d143 100644
--- a/drivers/net/wireless/ath/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath/ath5k/ath5k.h
@@ -1148,11 +1148,31 @@ struct ath5k_hw {
int ath5k_hw_attach(struct ath5k_softc *sc);
void ath5k_hw_detach(struct ath5k_hw *ah);
+#ifdef CONFIG_ATH5K_LEDS
/* LED functions */
+void ath5k_hw_set_ledstate(struct ath5k_softc *sc, unsigned int state);
int ath5k_init_leds(struct ath5k_softc *sc);
void ath5k_led_enable(struct ath5k_softc *sc);
void ath5k_led_off(struct ath5k_softc *sc);
void ath5k_unregister_leds(struct ath5k_softc *sc);
+#else
+static inline void ath5k_hw_set_ledstate(struct ath5k_softc *sc, unsigned int state)
+{
+}
+static inline int ath5k_init_leds(struct ath5k_softc *sc)
+{
+ return 0;
+}
+static inline void ath5k_led_enable(struct ath5k_softc *sc)
+{
+}
+static inline void ath5k_led_off(struct ath5k_softc *sc)
+{
+}
+static inline void ath5k_unregister_leds(struct ath5k_softc *sc)
+{
+}
+#endif
/* Reset Functions */
int ath5k_hw_nic_wakeup(struct ath5k_hw *ah, int flags, bool initial);
@@ -1233,7 +1253,6 @@ int ath5k_hw_set_slot_time(struct ath5k_hw *ah, unsigned int slot_time);
int ath5k_hw_init_desc_functions(struct ath5k_hw *ah);
/* GPIO Functions */
-void ath5k_hw_set_ledstate(struct ath5k_hw *ah, unsigned int state);
int ath5k_hw_set_gpio_input(struct ath5k_hw *ah, u32 gpio);
int ath5k_hw_set_gpio_output(struct ath5k_hw *ah, u32 gpio);
u32 ath5k_hw_get_gpio(struct ath5k_hw *ah, u32 gpio);
diff --git a/drivers/net/wireless/ath/ath5k/attach.c b/drivers/net/wireless/ath/ath5k/attach.c
index e0c244b..7930a39 100644
--- a/drivers/net/wireless/ath/ath5k/attach.c
+++ b/drivers/net/wireless/ath/ath5k/attach.c
@@ -336,7 +336,7 @@ int ath5k_hw_attach(struct ath5k_softc *sc)
ath5k_hw_init_nfcal_hist(ah);
/* turn on HW LEDs */
- ath5k_hw_set_ledstate(ah, AR5K_LED_INIT);
+ ath5k_hw_set_ledstate(sc, AR5K_LED_INIT);
return 0;
err_free:
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 2978359..64ea83d 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -3411,7 +3411,7 @@ static void ath5k_bss_info_changed(struct ieee80211_hw *hw,
sc->assoc = bss_conf->assoc;
if (sc->opmode == NL80211_IFTYPE_STATION)
set_beacon_filter(hw, sc->assoc);
- ath5k_hw_set_ledstate(sc->ah, sc->assoc ?
+ ath5k_hw_set_ledstate(sc, sc->assoc ?
AR5K_LED_ASSOC : AR5K_LED_INIT);
if (bss_conf->assoc) {
ATH5K_DBG(sc, ATH5K_DEBUG_ANY,
@@ -3444,13 +3444,13 @@ static void ath5k_sw_scan_start(struct ieee80211_hw *hw)
{
struct ath5k_softc *sc = hw->priv;
if (!sc->assoc)
- ath5k_hw_set_ledstate(sc->ah, AR5K_LED_SCAN);
+ ath5k_hw_set_ledstate(sc, AR5K_LED_SCAN);
}
static void ath5k_sw_scan_complete(struct ieee80211_hw *hw)
{
struct ath5k_softc *sc = hw->priv;
- ath5k_hw_set_ledstate(sc->ah, sc->assoc ?
+ ath5k_hw_set_ledstate(sc, sc->assoc ?
AR5K_LED_ASSOC : AR5K_LED_INIT);
}
diff --git a/drivers/net/wireless/ath/ath5k/base.h b/drivers/net/wireless/ath/ath5k/base.h
index 56221bc..8d289a3 100644
--- a/drivers/net/wireless/ath/ath5k/base.h
+++ b/drivers/net/wireless/ath/ath5k/base.h
@@ -186,9 +186,6 @@ struct ath5k_softc {
u8 bssidmask[ETH_ALEN];
- unsigned int led_pin, /* GPIO pin for driving LED */
- led_on; /* pin setting for LED on */
-
struct tasklet_struct restq; /* reset tasklet */
unsigned int rxbufsize; /* rx size based on mtu */
@@ -196,7 +193,6 @@ struct ath5k_softc {
spinlock_t rxbuflock;
u32 *rxlink; /* link ptr in last RX desc */
struct tasklet_struct rxtq; /* rx intr tasklet */
- struct ath5k_led rx_led; /* rx led */
struct list_head txbuf; /* transmit buffer */
spinlock_t txbuflock;
@@ -204,7 +200,14 @@ struct ath5k_softc {
struct ath5k_txq txqs[AR5K_NUM_TX_QUEUES]; /* tx queues */
struct ath5k_txq *txq; /* main tx queue */
struct tasklet_struct txtq; /* tx intr tasklet */
+
+
+#ifdef CONFIG_ATH5K_LEDS
+ unsigned int led_pin, /* GPIO pin for driving LED */
+ led_on; /* pin setting for LED on */
+ struct ath5k_led rx_led; /* rx led */
struct ath5k_led tx_led; /* tx led */
+#endif
struct ath5k_rfkill rf_kill;
diff --git a/drivers/net/wireless/ath/ath5k/gpio.c b/drivers/net/wireless/ath/ath5k/gpio.c
index 64a27e7..1e8b145 100644
--- a/drivers/net/wireless/ath/ath5k/gpio.c
+++ b/drivers/net/wireless/ath/ath5k/gpio.c
@@ -26,58 +26,6 @@
#include "base.h"
/*
- * Set led state
- */
-void ath5k_hw_set_ledstate(struct ath5k_hw *ah, unsigned int state)
-{
- u32 led;
- /*5210 has different led mode handling*/
- u32 led_5210;
-
- ATH5K_TRACE(ah->ah_sc);
-
- /*Reset led status*/
- if (ah->ah_version != AR5K_AR5210)
- AR5K_REG_DISABLE_BITS(ah, AR5K_PCICFG,
- AR5K_PCICFG_LEDMODE | AR5K_PCICFG_LED);
- else
- AR5K_REG_DISABLE_BITS(ah, AR5K_PCICFG, AR5K_PCICFG_LED);
-
- /*
- * Some blinking values, define at your wish
- */
- switch (state) {
- case AR5K_LED_SCAN:
- case AR5K_LED_AUTH:
- led = AR5K_PCICFG_LEDMODE_PROP | AR5K_PCICFG_LED_PEND;
- led_5210 = AR5K_PCICFG_LED_PEND | AR5K_PCICFG_LED_BCTL;
- break;
-
- case AR5K_LED_INIT:
- led = AR5K_PCICFG_LEDMODE_PROP | AR5K_PCICFG_LED_NONE;
- led_5210 = AR5K_PCICFG_LED_PEND;
- break;
-
- case AR5K_LED_ASSOC:
- case AR5K_LED_RUN:
- led = AR5K_PCICFG_LEDMODE_PROP | AR5K_PCICFG_LED_ASSOC;
- led_5210 = AR5K_PCICFG_LED_ASSOC;
- break;
-
- default:
- led = AR5K_PCICFG_LEDMODE_PROM | AR5K_PCICFG_LED_NONE;
- led_5210 = AR5K_PCICFG_LED_PEND;
- break;
- }
-
- /*Write new status to the register*/
- if (ah->ah_version != AR5K_AR5210)
- AR5K_REG_ENABLE_BITS(ah, AR5K_PCICFG, led);
- else
- AR5K_REG_ENABLE_BITS(ah, AR5K_PCICFG, led_5210);
-}
-
-/*
* Set GPIO inputs
*/
int ath5k_hw_set_gpio_input(struct ath5k_hw *ah, u32 gpio)
diff --git a/drivers/net/wireless/ath/ath5k/led.c b/drivers/net/wireless/ath/ath5k/led.c
index 67aa52e..9cff1cf 100644
--- a/drivers/net/wireless/ath/ath5k/led.c
+++ b/drivers/net/wireless/ath/ath5k/led.c
@@ -41,6 +41,7 @@
#include <linux/pci.h>
#include "ath5k.h"
+#include "reg.h"
#include "base.h"
#define ATH_SDEVICE(subv,subd) \
@@ -86,6 +87,58 @@ static const struct pci_device_id ath5k_led_devices[] = {
{ }
};
+/*
+ * Set led state
+ */
+void ath5k_hw_set_ledstate(struct ath5k_softc *sc, unsigned int state)
+{
+ u32 led;
+ /*5210 has different led mode handling*/
+ u32 led_5210;
+
+ ATH5K_TRACE(sc);
+
+ /*Reset led status*/
+ if (sc->ah->ah_version != AR5K_AR5210)
+ AR5K_REG_DISABLE_BITS(sc->ah, AR5K_PCICFG,
+ AR5K_PCICFG_LEDMODE | AR5K_PCICFG_LED);
+ else
+ AR5K_REG_DISABLE_BITS(sc->ah, AR5K_PCICFG, AR5K_PCICFG_LED);
+
+ /*
+ * Some blinking values, define at your wish
+ */
+ switch (state) {
+ case AR5K_LED_SCAN:
+ case AR5K_LED_AUTH:
+ led = AR5K_PCICFG_LEDMODE_PROP | AR5K_PCICFG_LED_PEND;
+ led_5210 = AR5K_PCICFG_LED_PEND | AR5K_PCICFG_LED_BCTL;
+ break;
+
+ case AR5K_LED_INIT:
+ led = AR5K_PCICFG_LEDMODE_PROP | AR5K_PCICFG_LED_NONE;
+ led_5210 = AR5K_PCICFG_LED_PEND;
+ break;
+
+ case AR5K_LED_ASSOC:
+ case AR5K_LED_RUN:
+ led = AR5K_PCICFG_LEDMODE_PROP | AR5K_PCICFG_LED_ASSOC;
+ led_5210 = AR5K_PCICFG_LED_ASSOC;
+ break;
+
+ default:
+ led = AR5K_PCICFG_LEDMODE_PROM | AR5K_PCICFG_LED_NONE;
+ led_5210 = AR5K_PCICFG_LED_PEND;
+ break;
+ }
+
+ /*Write new status to the register*/
+ if (sc->ah->ah_version != AR5K_AR5210)
+ AR5K_REG_ENABLE_BITS(sc->ah, AR5K_PCICFG, led);
+ else
+ AR5K_REG_ENABLE_BITS(sc->ah, AR5K_PCICFG, led_5210);
+}
+
void ath5k_led_enable(struct ath5k_softc *sc)
{
if (test_bit(ATH_STAT_LEDSOFT, sc->status)) {
--
1.7.1
^ permalink raw reply related
* Re: [PATCHv3] mac80211: Fix circular locking dependency in ARP filter handling
From: Johannes Berg @ 2010-06-09 7:32 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linville, linux-wireless, reinette.chatre
In-Reply-To: <1276066224-17880-1-git-send-email-juuso.oikarinen@nokia.com>
On Wed, 2010-06-09 at 09:50 +0300, Juuso Oikarinen wrote:
> v3: - queue reconfig filter work to kernel default wq instead of mac80211 wq
I think it would make more sense to use a different lock instead, like
the iflist mutex?
johannes
^ permalink raw reply
* Re: [RFC 3/3] mac80211: Store basic rates for bss when joining ibss network
From: Johannes Berg @ 2010-06-09 7:36 UTC (permalink / raw)
To: Teemu Paasikivi; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1276058714.495.35.camel@paavo-desktop>
On Wed, 2010-06-09 at 07:45 +0300, Teemu Paasikivi wrote:
> > However this kinda confuses me.
> >
> > We had a long-standing TODO item on our list at
> > http://wireless.kernel.org/en/developers/todo-list
> >
> > "when leaving an IBSS and we were the only member, remove it from
> > cfg80211's BSS list"
> >
> > Maybe that would help here too?
> >
>
> Yes, I think that would propably solve that issue where IBSS was
> recreated and requested basic rates are changed.
Want to take a look at it? It shouldn't be too hard -- just call
cfg80211_unlink_bss() somewhere where we still have the BSS pointer.
Actually we don't keep it as you saw with the update, so need to find it
first and then unlink it.
> > However I don't understand the scenario anyway. If you create an IBSS,
> > you start beaconing and tell cfg80211 about it with a frame that
> > includes the supported and basic rates. Then you leave, but the BSS
> > stays around in cfg80211 for 15 seconds. If you re-join within those 15
> > seconds, the scan results will pick up the old IBSS that no longer
> > exists, and we "join" it rather than creating it.
> >
> > However -- joining it will take the basic rates from it. So wouldn't you
> > get the old basic rates which is fine? What do you mean by "left unset"?
> >
>
> By "left unset" I mean that in the sniffer logs there's no rates marked
> as basic rates in the beacons. No old ones or new ones.
Ok that's what I thought. But ... are they marked in our TX beacons when
we _first_ created the IBSS?
> > What happens if you join an IBSS that already exists?
> >
>
> It works, but I haven't captured what's in the air. That's one reason
> why I sent these patches as RFC.
I don't really see how the two scenarios differ, so that's odd...
johannes
^ permalink raw reply
* Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34
From: Jens Axboe @ 2010-06-09 7:53 UTC (permalink / raw)
To: Linus Torvalds
Cc: Rafael J. Wysocki, Carl Worth, Eric Anholt, Venkatesh Pallipadi,
Dave Airlie, Jesse Barnes, Ingo Molnar, David Härdeman,
Mauro Carvalho Chehab, Eric Dumazet, Linux Kernel Mailing List,
Maciej Rutecki, Andrew Morton, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <alpine.LFD.2.00.1006081814240.4506@i5.linux-foundation.org>
On 2010-06-09 03:53, Linus Torvalds wrote:
>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16129
>> Subject : BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2
>> Submitter : Jan Kreuzer <kontrollator@gmx.de>
>> Date : 2010-06-05 06:15 (4 days old)
>
> This seems to have been introduced by
>
> commit 7cbaef9c83e58bbd4bdd534b09052b6c5ec457d5
> Author: Ingo Molnar <mingo@elte.hu>
> Date: Sat Nov 8 17:05:38 2008 +0100
>
> sched: optimize sched_clock() a bit
>
> sched_clock() uses cycles_2_ns() needlessly - which is an irq-disabling
> variant of __cycles_2_ns().
>
> Most of the time sched_clock() is called with irqs disabled already.
> The few places that call it with irqs enabled need to be updated.
>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
>
> and this seems to be one of those calling cases that need to be updated.
>
> Ingo? The call trace is:
>
> BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2-8/337
> caller is native_sched_clock+0x3c/0x68
> Pid: 337, comm: jbd2/sda2-8 Not tainted 2.6.35-rc1jan+ #4
> Call Trace:
> [<ffffffff812362c5>] debug_smp_processor_id+0xc9/0xe4
> [<ffffffff8101059d>] native_sched_clock+0x3c/0x68
> [<ffffffff8101043d>] sched_clock+0x9/0xd
> [<ffffffff81212d7a>] blk_rq_init+0x97/0xa3
> [<ffffffff81214d71>] get_request+0x1c4/0x2d0
> [<ffffffff81214ea6>] get_request_wait+0x29/0x1a6
> [<ffffffff81215537>] __make_request+0x338/0x45b
> [<ffffffff812147c2>] generic_make_request+0x2bb/0x330
> [<ffffffff81214909>] submit_bio+0xd2/0xef
> [<ffffffff811413cb>] submit_bh+0xf4/0x116
> [<ffffffff81144853>] block_write_full_page_endio+0x89/0x96
> [<ffffffff81144875>] block_write_full_page+0x15/0x17
> [<ffffffff8119b00a>] ext4_writepage+0x356/0x36b
> [<ffffffff810e1f91>] __writepage+0x1a/0x39
> [<ffffffff810e32a6>] write_cache_pages+0x20d/0x346
> [<ffffffff810e3406>] generic_writepages+0x27/0x29
> [<ffffffff811ca279>] journal_submit_data_buffers+0x110/0x17d
> [<ffffffff811ca986>] jbd2_journal_commit_transaction+0x4cb/0x156d
> [<ffffffff811d0cba>] kjournald2+0x147/0x37a
>
> (from the bugzilla thing)
This should be fixed by commit 28f4197e which was merged on friday.
>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16122
>> Subject : 2.6.35-rc1: WARNING at fs/fs-writeback.c:1142 __mark_inode_dirty+0x103/0x170
>> Submitter : Larry Finger <Larry.Finger@lwfinger.net>
>> Date : 2010-06-04 13:18 (5 days old)
>
> Jens?
Looking into this one.
--
Jens Axboe
^ permalink raw reply
* Possible leak in the ampdu aggregation code?
From: Nishant Sarmukadam @ 2010-06-09 8:35 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Hi,
I wanted to get some views on a possible issue while using mac80211 ampdu support.
skb's from pending queue for a TID are spliced onto the local pending queue when tearing down a block ack session.
If aggregation is stopped before the ampdu state becomes HT_AGG_STATE_OPERATIONAL say on addba timer expiry or if the addba request is declined, the state is changed to HT_AGG_STATE_REQ_STOP_BA_MSK |(initiator <<
HT_AGG_STATE_INITIATOR_SHIFT) in ___ieee80211_stop_tx_ba_session.
After commit 416fbdff2137e8d8cc8f23f517bee3a26b11526f, the ampdu state needs to have HT_ADDBA_REQUESTED_MSK set, else the skb's are not spliced.
Since the ampdu state got changed in ___ieee80211_stop_tx_ba_session, this condition is not met due to which the skb's are not spliced.
tid_tx[tid] which has a pointer to the pending skb queue then gets freed leaving the skb's in the pending queue allocated forever resulting in a memory leak. Does this make sense? If yes, one way to fix the issue is modify the state in ___ieee80211_stop_tx_ba_session preserving the earlier state. This way HT_ADDBA_REQUESTED_MSK will be set and skb's will be spliced. Any other way to fix this issue? Thoughts?
Regards,
Nishant
^ permalink raw reply
* Re: [PATCHv3] mac80211: Fix circular locking dependency in ARP filter handling
From: Juuso Oikarinen @ 2010-06-09 8:50 UTC (permalink / raw)
To: ext Johannes Berg
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
reinette.chatre@intel.com
In-Reply-To: <1276068754.3727.0.camel@jlt3.sipsolutions.net>
On Wed, 2010-06-09 at 09:32 +0200, ext Johannes Berg wrote:
> On Wed, 2010-06-09 at 09:50 +0300, Juuso Oikarinen wrote:
>
> > v3: - queue reconfig filter work to kernel default wq instead of mac80211 wq
>
> I think it would make more sense to use a different lock instead, like
> the iflist mutex?
Yeah had that originally, but apparently the iflist mutex is acquired
*after* the mgd mutex in some places of the code, especially all around
mlme.c, and here I would have to acquire them in reverse order. So I
changed to the rtnl lock.
-Juuso
> johannes
>
^ permalink raw reply
* Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34
From: Rafael J. Wysocki @ 2010-06-09 8:55 UTC (permalink / raw)
To: Jens Axboe
Cc: Linus Torvalds, Carl Worth, Eric Anholt, Venkatesh Pallipadi,
Dave Airlie, Jesse Barnes, Ingo Molnar, David Härdeman,
Mauro Carvalho Chehab, Eric Dumazet, Linux Kernel Mailing List,
Maciej Rutecki, Andrew Morton, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <4C0F4872.7090909@fusionio.com>
On Wednesday 09 June 2010, Jens Axboe wrote:
> On 2010-06-09 03:53, Linus Torvalds wrote:
> >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16129
> >> Subject : BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2
> >> Submitter : Jan Kreuzer <kontrollator@gmx.de>
> >> Date : 2010-06-05 06:15 (4 days old)
> >
> > This seems to have been introduced by
> >
> > commit 7cbaef9c83e58bbd4bdd534b09052b6c5ec457d5
> > Author: Ingo Molnar <mingo@elte.hu>
> > Date: Sat Nov 8 17:05:38 2008 +0100
> >
> > sched: optimize sched_clock() a bit
> >
> > sched_clock() uses cycles_2_ns() needlessly - which is an irq-disabling
> > variant of __cycles_2_ns().
> >
> > Most of the time sched_clock() is called with irqs disabled already.
> > The few places that call it with irqs enabled need to be updated.
> >
> > Signed-off-by: Ingo Molnar <mingo@elte.hu>
> >
> > and this seems to be one of those calling cases that need to be updated.
> >
> > Ingo? The call trace is:
> >
> > BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2-8/337
> > caller is native_sched_clock+0x3c/0x68
> > Pid: 337, comm: jbd2/sda2-8 Not tainted 2.6.35-rc1jan+ #4
> > Call Trace:
> > [<ffffffff812362c5>] debug_smp_processor_id+0xc9/0xe4
> > [<ffffffff8101059d>] native_sched_clock+0x3c/0x68
> > [<ffffffff8101043d>] sched_clock+0x9/0xd
> > [<ffffffff81212d7a>] blk_rq_init+0x97/0xa3
> > [<ffffffff81214d71>] get_request+0x1c4/0x2d0
> > [<ffffffff81214ea6>] get_request_wait+0x29/0x1a6
> > [<ffffffff81215537>] __make_request+0x338/0x45b
> > [<ffffffff812147c2>] generic_make_request+0x2bb/0x330
> > [<ffffffff81214909>] submit_bio+0xd2/0xef
> > [<ffffffff811413cb>] submit_bh+0xf4/0x116
> > [<ffffffff81144853>] block_write_full_page_endio+0x89/0x96
> > [<ffffffff81144875>] block_write_full_page+0x15/0x17
> > [<ffffffff8119b00a>] ext4_writepage+0x356/0x36b
> > [<ffffffff810e1f91>] __writepage+0x1a/0x39
> > [<ffffffff810e32a6>] write_cache_pages+0x20d/0x346
> > [<ffffffff810e3406>] generic_writepages+0x27/0x29
> > [<ffffffff811ca279>] journal_submit_data_buffers+0x110/0x17d
> > [<ffffffff811ca986>] jbd2_journal_commit_transaction+0x4cb/0x156d
> > [<ffffffff811d0cba>] kjournald2+0x147/0x37a
> >
> > (from the bugzilla thing)
>
> This should be fixed by commit 28f4197e which was merged on friday.
Thanks, closed.
Rafael
^ permalink raw reply
* Re: [PATCHv3] mac80211: Fix circular locking dependency in ARP filter handling
From: Johannes Berg @ 2010-06-09 8:54 UTC (permalink / raw)
To: Juuso Oikarinen
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
reinette.chatre@intel.com
In-Reply-To: <1276073421.5277.33026.camel@wimaxnb.nmp.nokia.com>
On Wed, 2010-06-09 at 11:50 +0300, Juuso Oikarinen wrote:
> On Wed, 2010-06-09 at 09:32 +0200, ext Johannes Berg wrote:
> > On Wed, 2010-06-09 at 09:50 +0300, Juuso Oikarinen wrote:
> >
> > > v3: - queue reconfig filter work to kernel default wq instead of mac80211 wq
> >
> > I think it would make more sense to use a different lock instead, like
> > the iflist mutex?
>
> Yeah had that originally, but apparently the iflist mutex is acquired
> *after* the mgd mutex in some places of the code, especially all around
> mlme.c, and here I would have to acquire them in reverse order. So I
> changed to the rtnl lock.
Ah, right.
However I'm a bit worried that making this workqueue change will allow
the filter reconfigure to cross with suspend, which might mean it could
execute after the device is suspended?
johannes
^ permalink raw reply
* Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34
From: Rafael J. Wysocki @ 2010-06-09 9:00 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linus Torvalds, Carl Worth, Eric Anholt, Venkatesh Pallipadi,
Jens Axboe, Dave Airlie, Jesse Barnes, Ingo Molnar,
David Härdeman, Eric Dumazet, Linux Kernel Mailing List,
Maciej Rutecki, Andrew Morton, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <4C0EFBC1.5090401@redhat.com>
On Wednesday 09 June 2010, Mauro Carvalho Chehab wrote:
> Em 08-06-2010 22:53, Linus Torvalds escreveu:
>
> >
> >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16037
> >> Subject : NULL Pointer dereference in __ir_input_register/budget_ci_attach
> >> Submitter : Sean Finney <seanius@debian.org>
> >> Date : 2010-05-23 19:52 (17 days old)
> >
> > Perhaps related to commit 13c24497086418010bf4f76378bcae241d7f59cd?
> >
> > David Härdeman, Mauro Carvalho Chehab added to cc.
>
> This patch probably solves the issue:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=84b14f181a36eea6591779156ef356f8d198bbfd
>
> The patch were already applied upstream. I've already asked the reporter to test it, via BZ.
Confirmed fixed, so closing.
Thanks,
Rafael
^ permalink raw reply
* Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34
From: Sedat Dilek @ 2010-06-09 9:02 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Linus Torvalds, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI, dmonakhov
In-Reply-To: <Rlf_Qjov7bG.A.a8F.I8rDMB@chimera>
The patch from [1] is still missing.
"cpufreq-call-nr_iowait_cpu-with-disabled-preemption.patch" from
Dmitry Monakhoc
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Tested-by Maciej Rutecki <maciej.rutecki@gmail.com>
I have already reported this issue on LKML [2] and cpufreq ML [3].
- Sedat -
[1] http://www.spinics.net/lists/cpufreq/msg01631.html
[2] http://lkml.org/lkml/2010/5/31/77
[3] http://www.spinics.net/lists/cpufreq/msg01637.html
On Wed, Jun 9, 2010 at 12:06 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> [NOTES:
> * This by no means is a complete list, but we only put e-mail reports that
> are at least 1 week old into the Bugzilla.
> * Quite a few of the already reported regressions may be related to the bug
> fixed by 386f40c86d6c8d5b717ef20620af1a750d0dacb4 (Revert "tty: fix a little
> bug in scrup, vt.c"), so reporters please retest with this commit applied.]
>
> This message contains a list of some regressions from 2.6.34,
> for which there are no fixes in the mainline known to the tracking team.
> If any of them have been fixed already, please let us know.
>
> If you know of any other unresolved regressions from 2.6.34, please let us
> know either and we'll add them to the list. Also, please let us know
> if any of the entries below are invalid.
>
> Each entry from the list will be sent additionally in an automatic reply
> to this message with CCs to the people involved in reporting and handling
> the issue.
>
>
> Listed regressions statistics:
>
> Date Total Pending Unresolved
> ----------------------------------------
> 2010-06-09 15 13 10
>
>
> Unresolved regressions
> ----------------------
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16163
> Subject : [2.6.35-rc1 Regression] i915: Commit cfecde causes VGA to stay off
> Submitter : David John <davidjon@xenontk.org>
> Date : 2010-06-02 12:52 (7 days old)
> Message-ID : <4C065423.3000202@xenontk.org>
> References : http://marc.info/?l=linux-kernel&m=127548313828613&w=2
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16161
> Subject : [2.6.35-rc1 regression] sysfs: cannot create duplicate filename ... XVR-600 related?
> Submitter : Mikael Pettersson <mikpe@it.uu.se>
> Date : 2010-06-01 19:57 (8 days old)
> Message-ID : <19461.26166.427857.612983@pilspetsen.it.uu.se>
> References : http://marc.info/?l=linux-kernel&m=127542227511925&w=2
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16160
> Subject : 2.6.35 Radeon KMS power management regression?
> Submitter : Nigel Cunningham <ncunningham@crca.org.au>
> Date : 2010-06-01 6:23 (8 days old)
> Message-ID : <4C04A767.8000209@crca.org.au>
> References : http://marc.info/?l=linux-kernel&m=127537343722290&w=2
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16145
> Subject : Unable to boot after "ACPI: Don't let acpi_pad needlessly mark TSC unstable"
> Submitter : Tom Gundersen <teg@jklm.no>
> Date : 2010-06-07 13:11 (2 days old)
> Handled-By : Venkatesh Pallipadi <venki@google.com>
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16129
> Subject : BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2
> Submitter : Jan Kreuzer <kontrollator@gmx.de>
> Date : 2010-06-05 06:15 (4 days old)
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16122
> Subject : 2.6.35-rc1: WARNING at fs/fs-writeback.c:1142 __mark_inode_dirty+0x103/0x170
> Submitter : Larry Finger <Larry.Finger@lwfinger.net>
> Date : 2010-06-04 13:18 (5 days old)
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16120
> Subject : Oops: 0000 [#1] SMP, unable to handle kernel NULL pointer dereference at (null)
> Submitter : Alex Zhavnerchik <alex.vizor@gmail.com>
> Date : 2010-06-04 09:25 (5 days old)
> Handled-By : Eric Dumazet <eric.dumazet@gmail.com>
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16104
> Subject : Radeon KMS does not start after merge of the new PM-Code
> Submitter : Jan Kreuzer <kontrollator@gmx.de>
> Date : 2010-06-02 07:47 (7 days old)
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16090
> Subject : sysfs: cannot create duplicate filename
> Submitter : Tobias <devnull@plzk.org>
> Date : 2010-06-01 15:59 (8 days old)
> Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org>
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16037
> Subject : NULL Pointer dereference in __ir_input_register/budget_ci_attach
> Submitter : Sean Finney <seanius@debian.org>
> Date : 2010-05-23 19:52 (17 days old)
>
>
> Regressions with patches
> ------------------------
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16131
> Subject : kernel BUG at fs/btrfs/extent-tree.c:4363 (btrfs_free_tree_block)
> Submitter : Chow Loong Jin <hyperair@ubuntu.com>
> Date : 2010-06-05 18:53 (4 days old)
> Handled-By : Yan Zheng <zheng.yan@oracle.com>
> Patch : https://patchwork.kernel.org/patch/103235/
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16127
> Subject : Boot freeze on HP Compaq nx6325 (RS482) with Radeon KMS
> Submitter : Jure Repinc <jlp.bugs@gmail.com>
> Date : 2010-06-04 21:14 (5 days old)
> Handled-By : Dave Airlie <airlied@linux.ie>
> Patch : https://bugzilla.kernel.org/attachment.cgi?id=26677
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16092
> Subject : Caught 64-bit read from uninitialized memory in memtype_rb_augment_cb
> Submitter : Christian Casteyde <casteyde.christian@free.fr>
> Date : 2010-06-01 18:08 (8 days old)
> Handled-By : Venki <venki@google.com>
> Patch : https://bugzilla.kernel.org/show_bug.cgi?id=16092#c2
>
>
> For details, please visit the bug entries and follow the links given in
> references.
>
> As you can see, there is a Bugzilla entry for each of the listed regressions.
> There also is a Bugzilla entry used for tracking the regressions from 2.6.34,
> unresolved as well as resolved, at:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=16055
>
> Please let the tracking team know if there are any Bugzilla entries that
> should be added to the list in there.
>
> Thanks!
>
> --
> 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: 2.6.35-rc2-git2: Reported regressions from 2.6.34
From: Rafael J. Wysocki @ 2010-06-09 9:06 UTC (permalink / raw)
To: Linus Torvalds
Cc: Carl Worth, Eric Anholt, Venkatesh Pallipadi, Jens Axboe,
Dave Airlie, Jesse Barnes, Ingo Molnar, David Härdeman,
Mauro Carvalho Chehab, Eric Dumazet, Linux Kernel Mailing List,
Maciej Rutecki, Andrew Morton, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <alpine.LFD.2.00.1006081814240.4506@i5.linux-foundation.org>
On Wednesday 09 June 2010, Linus Torvalds wrote:
>
> [ Added lots of cc's to direct specific people to look at the regressions
> that may or may not be theirs... ]
>
> On Wed, 9 Jun 2010, Rafael J. Wysocki wrote:
> >
> > * Quite a few of the already reported regressions may be related to the bug
> > fixed by 386f40c86d6c8d5b717ef20620af1a750d0dacb4 (Revert "tty: fix a little
> > bug in scrup, vt.c"), so reporters please retest with this commit applied.]
>
> From a quick look, most of them look unrelated to that unfortunate bug.
> It's hard to tell for sure, of course (memory corruption can do pretty
> much anything), but I'm not seeing the 07200720.. pattern at least.
>
> And some of them do seem to be bisected to likely culprits and/or have
> patches that are claimed to have fixed them.
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16163
> > Subject : [2.6.35-rc1 Regression] i915: Commit cfecde causes VGA to stay off
> > Submitter : David John <davidjon@xenontk.org>
> > Date : 2010-06-02 12:52 (7 days old)
> > Message-ID : <4C065423.3000202@xenontk.org>
> > References : http://marc.info/?l=linux-kernel&m=127548313828613&w=2
>
> That has a "reverting the commit fixes it", and a confirmation from Nick
> Bowler.
>
> Eric, Carl: should I just revert that commit? Or do you have a fix?
This one is reported to have been fixed already. Closed now.
...
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16104
> > Subject : Radeon KMS does not start after merge of the new PM-Code
> > Submitter : Jan Kreuzer <kontrollator@gmx.de>
> > Date : 2010-06-02 07:47 (7 days old)
>
> This one also has a patch in Bugzilla, I think Airlie is just waiting to
> calm down his queue and already removed the dependency on the temperature
> code. DaveA?
This should be fixed by commit f8ed8b4c5d30b5214f185997131b06e35f6f7113, so
closing now.
Rafael
^ permalink raw reply
* Re: [PATCHv3] mac80211: Fix circular locking dependency in ARP filter handling
From: Juuso Oikarinen @ 2010-06-09 9:08 UTC (permalink / raw)
To: ext Johannes Berg
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
reinette.chatre@intel.com
In-Reply-To: <1276073670.3727.12.camel@jlt3.sipsolutions.net>
On Wed, 2010-06-09 at 10:54 +0200, ext Johannes Berg wrote:
> On Wed, 2010-06-09 at 11:50 +0300, Juuso Oikarinen wrote:
> > On Wed, 2010-06-09 at 09:32 +0200, ext Johannes Berg wrote:
> > > On Wed, 2010-06-09 at 09:50 +0300, Juuso Oikarinen wrote:
> > >
> > > > v3: - queue reconfig filter work to kernel default wq instead of mac80211 wq
> > >
> > > I think it would make more sense to use a different lock instead, like
> > > the iflist mutex?
> >
> > Yeah had that originally, but apparently the iflist mutex is acquired
> > *after* the mgd mutex in some places of the code, especially all around
> > mlme.c, and here I would have to acquire them in reverse order. So I
> > changed to the rtnl lock.
>
> Ah, right.
>
> However I'm a bit worried that making this workqueue change will allow
> the filter reconfigure to cross with suspend, which might mean it could
> execute after the device is suspended?
Ah yes. That's an obvious side-effect. I wonder if it would be solved by
flushing this particular work along with the mac80211 wq in the suspend
call, or would the implications then just move further?
Apart from the above, I'm out of ideas. If this is getting too complex,
I'll need to revert back to the patch that does not take into account
the promisc mode.
-Juuso
^ permalink raw reply
* Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34
From: Rafael J. Wysocki @ 2010-06-09 9:22 UTC (permalink / raw)
To: sedat.dilek
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Linus Torvalds, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI, dmonakhov
In-Reply-To: <AANLkTiksbL1qHg7Q0A-6TbX0uUrxra4jctUoIGVk5vnE@mail.gmail.com>
On Wednesday 09 June 2010, Sedat Dilek wrote:
> The patch from [1] is still missing.
>
> "cpufreq-call-nr_iowait_cpu-with-disabled-preemption.patch" from
> Dmitry Monakhoc
>
> Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
> Tested-by Maciej Rutecki <maciej.rutecki@gmail.com>
>
> I have already reported this issue on LKML [2] and cpufreq ML [3].
>
> - Sedat -
>
> [1] http://www.spinics.net/lists/cpufreq/msg01631.html
> [2] http://lkml.org/lkml/2010/5/31/77
> [3] http://www.spinics.net/lists/cpufreq/msg01637.html
Thanks, added.
Rafael
^ 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