* [PATCH] iwlwifi 3945: Fix IWL_SCAN compile error
From: Tim Gardner @ 2009-07-13 19:08 UTC (permalink / raw)
To: yi.zhu; +Cc: ipw3945-devel, linux-kernel, linux-wireless, reinette.chatre
>From 2c7c806570ad72f5af2e778f2fe71aae7d727e02 Mon Sep 17 00:00:00 2001
From: Tim Gardner <tim.gardner@canonical.com>
Date: Mon, 13 Jul 2009 12:53:32 -0600
Subject: [PATCH] iwlwifi 3945: Fix IWL_DEBUG_SCAN compile
Added a missing parameter in the macro invocation to correct a
compile error when CONFIG_IWLWIFI_DEBUG is enabled.
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
---
drivers/net/wireless/iwlwifi/iwl3945-base.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 2564288..67332fb 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -2962,7 +2962,7 @@ static void iwl3945_bg_request_scan(struct work_struct *data)
}
if (scan->channel_count == 0) {
- IWL_DEBUG_SCAN("channel count %d\n", scan->channel_count);
+ IWL_DEBUG_SCAN(priv,"channel count %d\n", scan->channel_count);
goto done;
}
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] iwlwifi 3945: Fix IWL_SCAN compile error
From: Tim Gardner @ 2009-07-13 20:05 UTC (permalink / raw)
To: reinette chatre
Cc: Zhu, Yi, ipw3945-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org
In-Reply-To: <1247515401.17896.1630.camel@rc-desk>
reinette chatre wrote:
> Hi Tim,
>
> On Mon, 2009-07-13 at 12:08 -0700, Tim Gardner wrote:
>> From 2c7c806570ad72f5af2e778f2fe71aae7d727e02 Mon Sep 17 00:00:00 2001
>> From: Tim Gardner <tim.gardner@canonical.com>
>> Date: Mon, 13 Jul 2009 12:53:32 -0600
>> Subject: [PATCH] iwlwifi 3945: Fix IWL_DEBUG_SCAN compile
>>
>> Added a missing parameter in the macro invocation to correct a
>> compile error when CONFIG_IWLWIFI_DEBUG is enabled.
>>
>> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
>> ---
>> drivers/net/wireless/iwlwifi/iwl3945-base.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
>> index 2564288..67332fb 100644
>> --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
>> +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
>> @@ -2962,7 +2962,7 @@ static void iwl3945_bg_request_scan(struct work_struct *data)
>> }
>>
>> if (scan->channel_count == 0) {
>> - IWL_DEBUG_SCAN("channel count %d\n", scan->channel_count);
>> + IWL_DEBUG_SCAN(priv,"channel count %d\n", scan->channel_count);
>> goto done;
>> }
>>
>
> On which code did you base this patch?
>
> Reinette
>
>
Head of Linus' tree, but I see that its already fixed in
wireless-testing. I guess I pulled the trigger too soon.
rtg
--
Tim Gardner timg@tpi.com www.tpi.com
OR 503-601-0234 x102 MT 406-443-5357
^ permalink raw reply
* Re: [PATCH] iwlwifi 3945: Fix IWL_SCAN compile error
From: reinette chatre @ 2009-07-13 20:03 UTC (permalink / raw)
To: Tim Gardner
Cc: Zhu, Yi, ipw3945-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org
In-Reply-To: <20090713190803.9A70BF8D2C@sepang.rtg.net>
Hi Tim,
On Mon, 2009-07-13 at 12:08 -0700, Tim Gardner wrote:
> From 2c7c806570ad72f5af2e778f2fe71aae7d727e02 Mon Sep 17 00:00:00 2001
> From: Tim Gardner <tim.gardner@canonical.com>
> Date: Mon, 13 Jul 2009 12:53:32 -0600
> Subject: [PATCH] iwlwifi 3945: Fix IWL_DEBUG_SCAN compile
>
> Added a missing parameter in the macro invocation to correct a
> compile error when CONFIG_IWLWIFI_DEBUG is enabled.
>
> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
> ---
> drivers/net/wireless/iwlwifi/iwl3945-base.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> index 2564288..67332fb 100644
> --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
> +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> @@ -2962,7 +2962,7 @@ static void iwl3945_bg_request_scan(struct work_struct *data)
> }
>
> if (scan->channel_count == 0) {
> - IWL_DEBUG_SCAN("channel count %d\n", scan->channel_count);
> + IWL_DEBUG_SCAN(priv,"channel count %d\n", scan->channel_count);
> goto done;
> }
>
On which code did you base this patch?
Reinette
^ permalink raw reply
* Re: [ipw3945-devel] iwlwifi 4965 uCode available
From: John Ranson @ 2009-07-13 19:52 UTC (permalink / raw)
To: reinette chatre
Cc: Helmut Schaa, linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <1247511400.17896.1625.camel@rc-desk>
Reinette,
On Mon, Jul 13, 2009 at 11:56 AM, reinette
chatre<reinette.chatre@intel.com> wrote:
> John,
>
> On Mon, 2009-07-13 at 11:43 -0700, John Ranson wrote:
>> I am also seeing frequent loss of association and firmware restarts
>> with the new firmware. On occasion, I can't recover even when I
>> reload the driver. Admittedly, I am using an old driver right now
>> (2.6.29, I think).
>
> The better restart work was added in 2.6.31 I think, so it is only in
> the recent driver that you will have a smooth recovery after a failure.
> You may thus be seeing the same problem as Helmut, with him running the
> recent restart code.
Can I also get this with the latest compat wireless release and
2.6.30.1? I don't usually switch to a new kernel until it's been
stable for a while.
>
>>
>> I'm going to upgrade to 2.6.30.1 with the latest compat-wireless. I'll
>> file a bug if things continue as they are.
>
> Even if the restart code gets you up and running smoothly after a
> failure, please do submit a bug report so that we can look into this.
I'll be sure to file a bug.
John
^ permalink raw reply
* Re: [RFC/RFT] rtl8187: Fix for kernel oops when unloading with LEDs enabled
From: Johannes Berg @ 2009-07-13 19:49 UTC (permalink / raw)
To: Larry Finger; +Cc: John W Linville, linux-wireless
In-Reply-To: <4A5B8F57.5020601@lwfinger.net>
[-- Attachment #1: Type: text/plain, Size: 1402 bytes --]
On Mon, 2009-07-13 at 14:47 -0500, Larry Finger wrote:
> Johannes Berg wrote:
> > On Mon, 2009-07-13 at 10:43 -0500, Larry Finger wrote:
> >> When rtl8187 is unloaded and CONFIG_RTL8187_LEDS is set, the kernel
> >> may oops when the module is unloaded as the workqueue for led_on was
> >> not being cancelled. To prevent interference between cfg80211 and rtl8187,
> >> a separate workqueue has also been established.
> >
> > It doesn't seem like a separate workqueue should be necessary -- why is
> > it? Might make more sense to fix cfg80211 or mac80211 instead.
>
> Probably.
>
> Attached is the dump for the locking error when b43 is unloaded.
>
>
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> 2.6.31-rc2-wl #178
> -------------------------------------------------------
> modprobe/14721 is trying to acquire lock:
> (&rdev->conn_work){+.+.+.}, at: [<ffffffff810510c0>]
> __cancel_work_timer+0xd9/0x222
>
> but task is already holding lock:
> (cfg80211_mutex){+.+.+.}, at: [<ffffffffa0220524>]
> wiphy_unregister+0x3a/0xf8 [cfg80211]
That's purely a problem within cfg80211, and I don't think it could be
solved by your patch at all. I did send a patch earlier today though to
solve this.
(maybe you didn't reboot, and then lockdep was disabled after the first
warning?)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [RFC/RFT] rtl8187: Fix for kernel oops when unloading with LEDs enabled
From: Larry Finger @ 2009-07-13 19:47 UTC (permalink / raw)
To: Johannes Berg; +Cc: John W Linville, linux-wireless
In-Reply-To: <1247501812.4166.24.camel@johannes.local>
Johannes Berg wrote:
> On Mon, 2009-07-13 at 10:43 -0500, Larry Finger wrote:
>> When rtl8187 is unloaded and CONFIG_RTL8187_LEDS is set, the kernel
>> may oops when the module is unloaded as the workqueue for led_on was
>> not being cancelled. To prevent interference between cfg80211 and rtl8187,
>> a separate workqueue has also been established.
>
> It doesn't seem like a separate workqueue should be necessary -- why is
> it? Might make more sense to fix cfg80211 or mac80211 instead.
Probably.
Attached is the dump for the locking error when b43 is unloaded.
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.31-rc2-wl #178
-------------------------------------------------------
modprobe/14721 is trying to acquire lock:
(&rdev->conn_work){+.+.+.}, at: [<ffffffff810510c0>]
__cancel_work_timer+0xd9/0x222
but task is already holding lock:
(cfg80211_mutex){+.+.+.}, at: [<ffffffffa0220524>]
wiphy_unregister+0x3a/0xf8 [cfg80211]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (cfg80211_mutex){+.+.+.}:
[<ffffffff8106577b>] __lock_acquire+0x12d3/0x1621
[<ffffffff81065b82>] lock_acquire+0xb9/0xdd
[<ffffffff8127b28f>] mutex_lock_nested+0x56/0x2a8
[<ffffffffa02210c0>] cfg80211_get_dev_from_ifindex+0x17/0x8a
[cfg80211]
[<ffffffffa0224117>] cfg80211_wext_giwscan+0x40/0xf22 [cfg80211]
[<ffffffff81269c5a>] ioctl_standard_iw_point+0x198/0x227
[<ffffffff81269d7e>] ioctl_standard_call+0x95/0xb4
[<ffffffff81269ed3>] wext_ioctl_dispatch+0x9a/0x172
[<ffffffff8126a096>] wext_handle_ioctl+0x39/0x6f
[<ffffffff8120d6ea>] dev_ioctl+0x61e/0x647
[<ffffffff811fbcaf>] sock_ioctl+0x21d/0x22c
[<ffffffff810db01c>] vfs_ioctl+0x2a/0x78
[<ffffffff810db58f>] do_vfs_ioctl+0x4aa/0x4e7
[<ffffffff810db60e>] sys_ioctl+0x42/0x65
[<ffffffff8100ba6b>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
-> #1 (rtnl_mutex){+.+.+.}:
[<ffffffff8106577b>] __lock_acquire+0x12d3/0x1621
[<ffffffff81065b82>] lock_acquire+0xb9/0xdd
[<ffffffff8127b28f>] mutex_lock_nested+0x56/0x2a8
[<ffffffff81214e70>] rtnl_lock+0x12/0x14
[<ffffffffa0230429>] cfg80211_conn_work+0x2b/0x106 [cfg80211]
[<ffffffff81050618>] worker_thread+0x1fa/0x30a
[<ffffffff81054b2e>] kthread+0x88/0x90
[<ffffffff8100cb7a>] child_rip+0xa/0x20
[<ffffffffffffffff>] 0xffffffffffffffff
-> #0 (&rdev->conn_work){+.+.+.}:
[<ffffffff810654b0>] __lock_acquire+0x1008/0x1621
[<ffffffff81065b82>] lock_acquire+0xb9/0xdd
[<ffffffff810510f9>] __cancel_work_timer+0x112/0x222
[<ffffffff81051223>] cancel_work_sync+0xb/0xd
[<ffffffffa022055b>] wiphy_unregister+0x71/0xf8 [cfg80211]
[<ffffffffa026010a>] ieee80211_unregister_hw+0xb9/0xd9 [mac80211]
[<ffffffffa0296aee>] b43_remove+0x53/0x8a [b43]
[<ffffffffa01a2201>] ssb_device_remove+0x2b/0x3f [ssb]
[<ffffffff811d82d2>] __device_release_driver+0x80/0xc9
[<ffffffff811d83a2>] driver_detach+0x87/0xad
[<ffffffff811d75ab>] bus_remove_driver+0x89/0xb9
[<ffffffff811d88ab>] driver_unregister+0x66/0x6e
[<ffffffffa01a32eb>] ssb_driver_unregister+0xd/0xf [ssb]
[<ffffffffa02ab794>] b43_exit+0x10/0x17 [b43]
[<ffffffff8106dfd0>] sys_delete_module+0x1d3/0x249
[<ffffffff8100ba6b>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
other info that might help us debug this:
1 lock held by modprobe/14721:
#0: (cfg80211_mutex){+.+.+.}, at: [<ffffffffa0220524>]
wiphy_unregister+0x3a/0xf8 [cfg80211]
stack backtrace:
Pid: 14721, comm: modprobe Not tainted 2.6.31-rc2-wl #178
Call Trace:
[<ffffffff8106400d>] print_circular_bug_tail+0xc1/0xcc
[<ffffffff810654b0>] __lock_acquire+0x1008/0x1621
[<ffffffff81063f18>] ? check_noncircular+0xe4/0x118
[<ffffffff81064496>] ? check_irq_usage+0xb3/0xc5
[<ffffffff81065b82>] lock_acquire+0xb9/0xdd
[<ffffffff810510c0>] ? __cancel_work_timer+0xd9/0x222
[<ffffffff810510f9>] __cancel_work_timer+0x112/0x222
[<ffffffff810510c0>] ? __cancel_work_timer+0xd9/0x222
[<ffffffff810635b2>] ? mark_held_locks+0x4d/0x6b
[<ffffffff810635b2>] ? mark_held_locks+0x4d/0x6b
[<ffffffff8127b0d7>] ? __mutex_unlock_slowpath+0x10d/0x119
[<ffffffff81063825>] ? trace_hardirqs_on_caller+0x10b/0x12f
[<ffffffff81063856>] ? trace_hardirqs_on+0xd/0xf
[<ffffffff81051223>] cancel_work_sync+0xb/0xd
[<ffffffffa022055b>] wiphy_unregister+0x71/0xf8 [cfg80211]
[<ffffffffa026010a>] ieee80211_unregister_hw+0xb9/0xd9 [mac80211]
[<ffffffffa0296aee>] b43_remove+0x53/0x8a [b43]
[<ffffffffa01a2201>] ssb_device_remove+0x2b/0x3f [ssb]
[<ffffffff811d82d2>] __device_release_driver+0x80/0xc9
[<ffffffff811d83a2>] driver_detach+0x87/0xad
[<ffffffff811d75ab>] bus_remove_driver+0x89/0xb9
[<ffffffff811d88ab>] driver_unregister+0x66/0x6e
[<ffffffffa01a32eb>] ssb_driver_unregister+0xd/0xf [ssb]
[<ffffffffa02ab794>] b43_exit+0x10/0x17 [b43]
[<ffffffff8106dfd0>] sys_delete_module+0x1d3/0x249
[<ffffffff81063825>] ? trace_hardirqs_on_caller+0x10b/0x12f
[<ffffffff8127c726>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff8100ba6b>] system_call_fastpath+0x16/0x1b
b43-pci-bridge 0000:04:00.0: PCI INT A disabled
^ permalink raw reply
* iwl: potential deadlock?
From: Jiri Slaby @ 2009-07-13 19:34 UTC (permalink / raw)
To: yi.zhu
Cc: reinette.chatre, linux-wireless, ipw3945-devel,
Linux kernel mailing list
Hi,
we found a potential deadlock in iwl code by our tool.
Can this happen:
iwl_update_tkip_key()
-> spin_lock_irqsave(&priv->sta_lock)
-> iwl_send_add_sta()
-> iwl_sta_ucode_activate()
-> spin_lock_irqsave(&priv->sta_lock)
?
Thanks.
^ permalink raw reply
* Re: nl80211 and wext interoperability
From: Johannes Berg @ 2009-07-13 19:14 UTC (permalink / raw)
To: Dan Williams; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <1247512206.4369.67.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 819 bytes --]
On Mon, 2009-07-13 at 15:10 -0400, Dan Williams wrote:
> On Mon, 2009-07-13 at 19:54 +0200, Johannes Berg wrote:
> > On Mon, 2009-07-13 at 13:53 -0400, Dan Williams wrote:
> >
> > > Mainly because there's no way to tell WEXT drivers to "stop whatever
> > > you're doing and just be idle"...
> > >
> > > The supplicant clears out the keys on TERM anyway, and in some cases
> > > (iwlagn) the driver will keep trying to reassociate internally
> >
> > Seems unlikely, ITYM ipw?
>
> Nope. I saw this behavior with iwlagn (both 3945 and 4965) when I was
> doing all that hidden stuff back in April with 2.6.27 kernels. Might be
> different in very recent kernels?
That doesn't sound right, to the best of my knowledge the _driver_ has
no chance to try to associate, and mac80211 didn't.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: nl80211 and wext interoperability
From: Dan Williams @ 2009-07-13 19:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <1247507677.4166.27.camel@johannes.local>
On Mon, 2009-07-13 at 19:54 +0200, Johannes Berg wrote:
> On Mon, 2009-07-13 at 13:53 -0400, Dan Williams wrote:
>
> > Mainly because there's no way to tell WEXT drivers to "stop whatever
> > you're doing and just be idle"...
> >
> > The supplicant clears out the keys on TERM anyway, and in some cases
> > (iwlagn) the driver will keep trying to reassociate internally
>
> Seems unlikely, ITYM ipw?
Nope. I saw this behavior with iwlagn (both 3945 and 4965) when I was
doing all that hidden stuff back in April with 2.6.27 kernels. Might be
different in very recent kernels?
Dan
^ permalink raw reply
* Re: [ipw3945-devel] iwlwifi 4965 uCode available
From: reinette chatre @ 2009-07-13 18:56 UTC (permalink / raw)
To: John Ranson
Cc: Helmut Schaa, linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <bcd1ba70907131143m2940444ch372ae0bc01417bc4@mail.gmail.com>
John,
On Mon, 2009-07-13 at 11:43 -0700, John Ranson wrote:
> I am also seeing frequent loss of association and firmware restarts
> with the new firmware. On occasion, I can't recover even when I
> reload the driver. Admittedly, I am using an old driver right now
> (2.6.29, I think).
The better restart work was added in 2.6.31 I think, so it is only in
the recent driver that you will have a smooth recovery after a failure.
You may thus be seeing the same problem as Helmut, with him running the
recent restart code.
>
> I'm going to upgrade to 2.6.30.1 with the latest compat-wireless. I'll
> file a bug if things continue as they are.
Even if the restart code gets you up and running smoothly after a
failure, please do submit a bug report so that we can look into this.
> Thank you very much for getting the new firmware out!
Reinette
^ permalink raw reply
* Re: [ipw3945-devel] iwlwifi 4965 uCode available
From: John Ranson @ 2009-07-13 18:43 UTC (permalink / raw)
To: reinette chatre
Cc: Helmut Schaa, linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <1247499979.17896.1556.camel@rc-desk>
I am also seeing frequent loss of association and firmware restarts
with the new firmware. On occasion, I can't recover even when I
reload the driver. Admittedly, I am using an old driver right now
(2.6.29, I think).
I'm going to upgrade to 2.6.30.1 with the latest compat-wireless. I'll
file a bug if things continue as they are.
Thank you very much for getting the new firmware out!
Cheers,
John
On Mon, Jul 13, 2009 at 8:46 AM, reinette
chatre<reinette.chatre@intel.com> wrote:
> Hi Helmut,
>
> On Sun, 2009-07-12 at 05:45 -0700, Helmut Schaa wrote:
>> Am Donnerstag, 9. Juli 2009 schrieb reinette chatre:
>> > Version 228.61.2.24 of uCode for Intel Wireless WiFi Link 4965AGN is now
>> > available for download from
>> > http://intellinuxwireless.org/?n=Downloads
>>
>> The new ucode seems to cause fw restarts every now and then (together
>> with wireless-testing).
>
> oh no ...
>
>>
>> iwlagn 0000:10:00.0: Microcode SW error detected. Restarting 0x82000000.
>
> What is the status when such an error occurs? Can it recover on its own
> or do you need to take action? What action is needed?
>
>>
>> I couldn't figure out how to reproduce this but it happened a few times
>> now since I switched to the new ucode.
>>
>> Should I load iwlagn with some special debug flags?
>
> If your driver is compiled with CONFIG_IWLWIFI_DEBUG then you can pass a
> debug flag to the module that will print a ucode event log when it
> encounters a problem like this. As it will only print out the event log
> when this error occurs you can safely turn this debugging on permanently
> without risking a clutter of your logs. Later, if you know how to
> reproduce is you can increase debugging to get more details about what
> the driver is actually doing. The debug flag for _just_ the ucode event
> log is 0x40000 (like "modprobe iwlagn debug=0x40000"). The 0x43fff is a
> more general debug flag that helps with obtaining more information.
>
> When you have this data - could you please submit a bug at
> intellinuxwireless.org/bugzilla for us to be able to track it?
>
> Thank you very much
>
> Reinette
>
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Ipw3945-devel mailing list
> Ipw3945-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ipw3945-devel
>
^ permalink raw reply
* Re: iwlwifi 4965 uCode available
From: Helmut Schaa @ 2009-07-13 18:29 UTC (permalink / raw)
To: reinette chatre
Cc: linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <1247499979.17896.1556.camel@rc-desk>
Am Montag, 13. Juli 2009 schrieb reinette chatre:
> On Sun, 2009-07-12 at 05:45 -0700, Helmut Schaa wrote:
> > Am Donnerstag, 9. Juli 2009 schrieb reinette chatre:
> > > Version 228.61.2.24 of uCode for Intel Wireless WiFi Link 4965AGN is now
> > > available for download from
> > > http://intellinuxwireless.org/?n=Downloads
> >
> > The new ucode seems to cause fw restarts every now and then (together
> > with wireless-testing).
>
> oh no ...
>
> >
> > iwlagn 0000:10:00.0: Microcode SW error detected. Restarting 0x82000000.
>
> What is the status when such an error occurs? Can it recover on its own
> or do you need to take action? What action is needed?
It recovers automatically, no action required. Not sure if it has any
negative impact on the connection. At least I did not notice anything yet.
> > I couldn't figure out how to reproduce this but it happened a few times
> > now since I switched to the new ucode.
> >
> > Should I load iwlagn with some special debug flags?
>
> If your driver is compiled with CONFIG_IWLWIFI_DEBUG then you can pass a
> debug flag to the module that will print a ucode event log when it
> encounters a problem like this. As it will only print out the event log
> when this error occurs you can safely turn this debugging on permanently
> without risking a clutter of your logs. Later, if you know how to
> reproduce is you can increase debugging to get more details about what
> the driver is actually doing. The debug flag for _just_ the ucode event
> log is 0x40000 (like "modprobe iwlagn debug=0x40000"). The 0x43fff is a
> more general debug flag that helps with obtaining more information.
>
> When you have this data - could you please submit a bug at
> intellinuxwireless.org/bugzilla for us to be able to track it?
Will do as soon as I find a way to reproduce it.
Helmut
^ permalink raw reply
* Re: iwl3945 dropping from network
From: reinette chatre @ 2009-07-13 18:26 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless@vger.kernel.org, Johannes Berg
In-Reply-To: <87r5wl5alj.fsf@litku.valot.fi>
Hi,
On Mon, 2009-07-13 at 00:02 -0700, Kalle Valo wrote:
> Good morning,
>
> during the weekend I have noticed that my iwl3945 is dropping from
> network and wpa_supplicant can't connect to the network anymore, only
> 'wpa_action wlan0 stop' (which essentially quits wpa_supplicant) and
> 'ifup wlan0' (which starts wpa_supplicant, debian is weird here) makes
> it work again. I think I'm seeing similar behaviour also when I resume.
I started seeing the exact same thing last friday with my 5100. In my
setup I am using networkmanager and it did not give me much debug
information when the problem occurred. I had to restart networkmanager
to be able to connect again. My logs look the same as yours though. I am
now running with wpa_supplicant in foreground with full debugging but so
far it has not happened yet.
Reinette
^ permalink raw reply
* Re: nl80211 and wext interoperability
From: Johannes Berg @ 2009-07-13 17:54 UTC (permalink / raw)
To: Dan Williams; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <1247507618.4369.11.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 350 bytes --]
On Mon, 2009-07-13 at 13:53 -0400, Dan Williams wrote:
> Mainly because there's no way to tell WEXT drivers to "stop whatever
> you're doing and just be idle"...
>
> The supplicant clears out the keys on TERM anyway, and in some cases
> (iwlagn) the driver will keep trying to reassociate internally
Seems unlikely, ITYM ipw?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: nl80211 and wext interoperability
From: Dan Williams @ 2009-07-13 17:55 UTC (permalink / raw)
To: Johannes Berg; +Cc: Pavel Roskin, linux-wireless
In-Reply-To: <1247161696.22527.1.camel@johannes.local>
On Thu, 2009-07-09 at 19:48 +0200, Johannes Berg wrote:
> On Thu, 2009-07-09 at 13:13 -0400, Pavel Roskin wrote:
>
> > I think using random data is a problem by itself. Are we exposing
> > random pieces of kernel memory in probe requests? That's bad.
>
> You misunderstood. wpa_supplicant _explicitly_ tells us it _wants_ to
> use that 32-byte random SSID. It's just like it telling us it wants to
> use the ssid "foobar" or "Pavel's House" or ... I don't see what we can
> do, other than actually take it seriously and at least attempt to
> connect to that network.
That was the idea, expect that this random BSSID/SSID combo will simply
fail to be found in a scan, and either the card driver will just keep
periodically scanning to find the AP until another request comes in, or
they will eventually just give up and idle. What it was meant to do was
to stop the card from trying to keep re-associating to a previous AP now
that the supplicant has terminated. See my just-posted mail a bit up in
this thread as to why. WEXT sucks.
Dan
^ permalink raw reply
* Re: nl80211 and wext interoperability
From: Dan Williams @ 2009-07-13 17:53 UTC (permalink / raw)
To: Johannes Berg; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <1247163342.22527.2.camel@johannes.local>
On Thu, 2009-07-09 at 20:15 +0200, Johannes Berg wrote:
> On Thu, 2009-07-09 at 10:53 -0700, Luis R. Rodriguez wrote:
> > On Thu, Jul 9, 2009 at 4:43 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> > > Hi!
> > >
> > > With the recent work I've done in cfg80211 for nl80211 and wext, we've
> > > mostly removed wext code everywhere. The only thing missing right now is
> > > the key support, and I think then we can declare cfg80211's wext compat
> > > layer pretty much done in terms of what mac80211 had -- orinoco will
> > > need the sensitivity (or AP density) thing but I'm not sure how we
> > > should do that since it's a value that is hardware dependent -- we'll
> > > need to have very good discovery code for the allowed values (unlike
> > > wext where you can set 0..3 and don't know what that means). Anyway,
> > > that wasn't the point of this email.
> > >
> > > Currently, if you use wpa_supplicant -Dwext and -Dnl80211 mixed,
> > > -Dnl80211 gets confused because -Dwext will set a 32-byte random SSID to
> > > "disconnect".
> >
> > When do we disconnect like this? Upon initialization of wpa_supplicant
> > -Dwext -Dnl80211 ?
>
> When you shut down wpa_supplicant -Dwext it does that.
Mainly because there's no way to tell WEXT drivers to "stop whatever
you're doing and just be idle"...
The supplicant clears out the keys on TERM anyway, and in some cases
(iwlagn) the driver will keep trying to reassociate internally, and if
the keys aren't there, the AP will keep rejecting it, which just means
you're spamming the air and the AP continuously, and then when you
re-start the supplicant, you get a constant stream of WEXT disconnect
events because the AP keeps rejecting you, and the supplicant freaks
out.
So, forcing a random SSID/BSSID combo is the best way (with WEXT) to
tell the driver to just stop trying to associate to anything.
Dan
^ permalink raw reply
* Re: Proper Regulatory Enforcement
From: Luis R. Rodriguez @ 2009-07-13 17:36 UTC (permalink / raw)
To: Richard Farina; +Cc: linux-wireless
In-Reply-To: <4A5B301B.8060405@gmail.com>
On Mon, Jul 13, 2009 at 6:01 AM, Richard Farina<sidhayn@gmail.com> wrote:
> Many discussions in #Linux-wireless and even on this list seem to revolve
> around how regulatory enforcement is provided. At one point I thought that
> I understood how this works, but as things evolve it seems I am losing my
> edge. With the goal of understanding a unified policy for all drivers and
> proper (safe) regulatory enforcement, I'm starting this thread so that
> people can help clarify how this currently works, and how it should work.
>
> As I see this all working in an ideal world is as follows:
>
> 1.) Driver reads eeprom of card for the permissible frequencies for that
> hardware. It is only safe to allow the frequencies in the eeprom because we
> cannot assume that any other values were calibrated in the hardware. This
> information (or initial regulatory domain) should be passed up to and
> immediately enforced by crda. Drivers shouldn't have their own enforcement
> in addition to crda as we have a properly functioning regulatory enforcement
> engine and having 1 per driver makes things pointlessly complicated.
You for got the case 0) where cards have no EEPROM information from
which a regulatory_hint() can be constructed for. In this case we
always world roam at first but user input can then set the channels
for the user. User input in these cases may enable new channels as the
card has no location information. It certainly would shave off some
more pounds from the driver.
You also forgot the case where cards have EEPROM information but also
have a few set of custom world regulatory domains. For example,
Atheros cards have 12 world regulatory domains, apart from the group
regulatory domains (which map to an alpha2) or a specific alpha2
country code mapping. cfg80211 allows drivers to specify custom world
regulatory domains and use them when applicable. It may be the case we
can just get rid of these in favor of the 1 world regulatory domain
that cfg80211 has, but that needs some good internal company review.
> 2.) If the user sets a reg domain, intersect user reg domain with eeprom reg
> domain.
>
> 3.) When user connects to AP, if available, read country IE and intersect
> that with the currently effective reg domain (which is at least the eeprom
> and may include user input from step 2 as well).
You also forgot about the world roaming feature of scanning and
finding beacons. When you scan and find a beacon from an AP passive
scan flags and no-ibss flags are lifted. This is under the assumption
APs which beacon can be trusted. This feature is only used when your
card is world roaming.
> I realize some distros have cool stuff happening like setting a reg domain
> using the location from the timezone or some other cool thing. For the
> purpose of this discussion however, that is really nothing different from a
> user set reg domain (in fact I believe that is how it is done) so let's not
> worry about those specifics of "well the user didn't directly call iw reg
> set so blah blah blah".
>
> How far off base am I here?
Pretty good -- except for the few notes above.
> I know that Intel enforces reg domain in their
> ucode and we cannot do anything about it,
Well you can help compliance further by setting the regdomain, that
may disable channels your country does not allow for which the intel
cards may have passive scanning enabled for. This can help in scan
time since no APs are expected to be found in those channels.
> but I'm more interested in the
> cards where our drivers have full control. Are the drivers themselves
> performing limiting that users don't even get to see?
ath9k reads the CTL (Conformance Test Limit) indexes for the target
frequency and may reduce power further depending on the information
read. This is where that argument about calibration comes in -- this
the that calibrated data that should be cared for. Each frequency a
card is capable of gets tested and has a CTL index map. If it does not
have a CTL index power the max regulatory EIRP is used. CTL index for
Atheros cards come in quite handy at band edges where we want to
ensure the power curve does not go over the edge but it also can be
used for regular regulatory compliance and ensures you also won't bust
your card by trying to use a tx power that can damage the card.
> Or is all this
> actually passed up to crda as it should be?
CRDA is used to get the driver regulatory control information for each
country. Drivers then can use calibration data at will for further
compliance. Each device may do this differently. For instance, I have
no idea how Intel handles band edge power compliance parameters, it
must be data stuffed in the EEPROM somewhere or it may just user a
lower safe value.. not sure. Also not sure how Broadcom does this, I
think Johannes mentioned to me once that the firmware may be doing
that.
> I'm personally especially
> interested in how the three atheros drivers do it, but I think this
> discussion should extend beyond my personal interests and any and all
> drivers should be discussed.
Some devices may not even have such band edge calibration data, and
don't ask me how they ensure proper regulatory power is used, I know
only exactly how Atheros stuff does it.
Luis
^ permalink raw reply
* Re: [RFC/RFT] rtl8187: Fix for kernel oops when unloading with LEDs enabled
From: Johannes Berg @ 2009-07-13 16:16 UTC (permalink / raw)
To: Larry Finger
Cc: netrolller.3d, Herton Ronaldo Krzesinski, Hin-Tak Leung,
John W Linville, linux-wireless
In-Reply-To: <4a5b563e.AuhPXmHA0dUFYtzx%Larry.Finger@lwfinger.net>
[-- Attachment #1: Type: text/plain, Size: 479 bytes --]
On Mon, 2009-07-13 at 10:43 -0500, Larry Finger wrote:
> When rtl8187 is unloaded and CONFIG_RTL8187_LEDS is set, the kernel
> may oops when the module is unloaded as the workqueue for led_on was
> not being cancelled. To prevent interference between cfg80211 and rtl8187,
> a separate workqueue has also been established.
It doesn't seem like a separate workqueue should be necessary -- why is
it? Might make more sense to fix cfg80211 or mac80211 instead.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: iwlwifi 4965 uCode available
From: reinette chatre @ 2009-07-13 15:46 UTC (permalink / raw)
To: Helmut Schaa
Cc: linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <200907121445.42289.helmut.schaa@gmail.com>
Hi Helmut,
On Sun, 2009-07-12 at 05:45 -0700, Helmut Schaa wrote:
> Am Donnerstag, 9. Juli 2009 schrieb reinette chatre:
> > Version 228.61.2.24 of uCode for Intel Wireless WiFi Link 4965AGN is now
> > available for download from
> > http://intellinuxwireless.org/?n=Downloads
>
> The new ucode seems to cause fw restarts every now and then (together
> with wireless-testing).
oh no ...
>
> iwlagn 0000:10:00.0: Microcode SW error detected. Restarting 0x82000000.
What is the status when such an error occurs? Can it recover on its own
or do you need to take action? What action is needed?
>
> I couldn't figure out how to reproduce this but it happened a few times
> now since I switched to the new ucode.
>
> Should I load iwlagn with some special debug flags?
If your driver is compiled with CONFIG_IWLWIFI_DEBUG then you can pass a
debug flag to the module that will print a ucode event log when it
encounters a problem like this. As it will only print out the event log
when this error occurs you can safely turn this debugging on permanently
without risking a clutter of your logs. Later, if you know how to
reproduce is you can increase debugging to get more details about what
the driver is actually doing. The debug flag for _just_ the ucode event
log is 0x40000 (like "modprobe iwlagn debug=0x40000"). The 0x43fff is a
more general debug flag that helps with obtaining more information.
When you have this data - could you please submit a bug at
intellinuxwireless.org/bugzilla for us to be able to track it?
Thank you very much
Reinette
^ permalink raw reply
* [RFC/RFT] rtl8187: Fix for kernel oops when unloading with LEDs enabled
From: Larry Finger @ 2009-07-13 15:43 UTC (permalink / raw)
To: netrolller.3d
Cc: Herton Ronaldo Krzesinski, Hin-Tak Leung, John W Linville,
linux-wireless
When rtl8187 is unloaded and CONFIG_RTL8187_LEDS is set, the kernel
may oops when the module is unloaded as the workqueue for led_on was
not being cancelled. To prevent interference between cfg80211 and rtl8187,
a separate workqueue has also been established.
Reported-by: Gábor Stefanik <netrolller.3d@gmail.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger>
---
Gábor,
I hope this version of the patch fixes your problem. On my system
I ran more than 20 rmmod/insmod cycles without a problem.
Larry
---
Index: wireless-testing/drivers/net/wireless/rtl818x/rtl8187_leds.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/rtl818x/rtl8187_leds.c
+++ wireless-testing/drivers/net/wireless/rtl818x/rtl8187_leds.c
@@ -108,11 +108,11 @@ static void rtl8187_led_brightness_set(s
struct rtl8187_priv *priv = hw->priv;
if (brightness == LED_OFF) {
- queue_delayed_work(hw->workqueue, &priv->led_off, 0);
+ queue_delayed_work(priv->workqueue, &priv->led_off, 0);
/* The LED is off for 1/20 sec so that it just blinks. */
- queue_delayed_work(hw->workqueue, &priv->led_on, HZ / 20);
+ queue_delayed_work(priv->workqueue, &priv->led_on, HZ / 20);
} else
- queue_delayed_work(hw->workqueue, &priv->led_on, 0);
+ queue_delayed_work(priv->workqueue, &priv->led_on, 0);
}
static int rtl8187_register_led(struct ieee80211_hw *dev,
@@ -193,7 +193,7 @@ void rtl8187_leds_init(struct ieee80211_
err = rtl8187_register_led(dev, &priv->led_rx, name,
ieee80211_get_rx_led_name(dev), ledpin);
if (!err) {
- queue_delayed_work(dev->workqueue, &priv->led_on, 0);
+ queue_delayed_work(priv->workqueue, &priv->led_on, 0);
return;
}
/* registration of RX LED failed - unregister TX */
@@ -208,11 +208,12 @@ void rtl8187_leds_exit(struct ieee80211_
{
struct rtl8187_priv *priv = dev->priv;
- rtl8187_unregister_led(&priv->led_tx);
/* turn the LED off before exiting */
- queue_delayed_work(dev->workqueue, &priv->led_off, 0);
+ queue_delayed_work(priv->workqueue, &priv->led_off, 0);
cancel_delayed_work_sync(&priv->led_off);
+ cancel_delayed_work_sync(&priv->led_on);
rtl8187_unregister_led(&priv->led_rx);
+ rtl8187_unregister_led(&priv->led_tx);
}
#endif /* def CONFIG_RTL8187_LED */
Index: wireless-testing/drivers/net/wireless/rtl818x/rtl8187.h
===================================================================
--- wireless-testing.orig/drivers/net/wireless/rtl818x/rtl8187.h
+++ wireless-testing/drivers/net/wireless/rtl818x/rtl8187.h
@@ -104,6 +104,7 @@ struct rtl8187_priv {
struct delayed_work work;
struct ieee80211_hw *dev;
#ifdef CONFIG_RTL8187_LEDS
+ struct workqueue_struct *workqueue;
struct rtl8187_led led_tx;
struct rtl8187_led led_rx;
struct delayed_work led_on;
Index: wireless-testing/drivers/net/wireless/rtl818x/rtl8187_dev.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/rtl818x/rtl8187_dev.c
+++ wireless-testing/drivers/net/wireless/rtl818x/rtl8187_dev.c
@@ -1507,6 +1507,12 @@ static int __devinit rtl8187_probe(struc
#ifdef CONFIG_RTL8187_LEDS
eeprom_93cx6_read(&eeprom, 0x3F, ®);
reg &= 0xFF;
+ priv->workqueue =
+ create_singlethread_workqueue(wiphy_name(dev->wiphy));
+ if (!priv->workqueue) {
+ err = -ENOMEM;
+ goto err_free_dmabuf;
+ }
rtl8187_leds_init(dev, reg);
#endif
^ permalink raw reply
* Re: ath5k and Atheros AR242x - No scan results
From: Bob Copeland @ 2009-07-13 14:08 UTC (permalink / raw)
To: Joel Roth; +Cc: Nick Kossifidis, linux-wireless
In-Reply-To: <20090712203449.GA3058@sprite>
On Sun, Jul 12, 2009 at 4:34 PM, Joel Roth<joelz@pobox.com> wrote:
> Vista advised me to:
>
> 1) turn on the hardware wifi switch <blush>
>
> 2) use the hotkey combination to enable wifi
It might be worth trying compat-wireless or 2.6.31-rcX. Support
for reading the card's internal rfkill state was added in the
post-2.6.30 time-frame.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Proper Regulatory Enforcement
From: Richard Farina @ 2009-07-13 13:01 UTC (permalink / raw)
To: linux-wireless
Many discussions in #Linux-wireless and even on this list seem to
revolve around how regulatory enforcement is provided. At one point I
thought that I understood how this works, but as things evolve it seems
I am losing my edge. With the goal of understanding a unified policy
for all drivers and proper (safe) regulatory enforcement, I'm starting
this thread so that people can help clarify how this currently works,
and how it should work.
As I see this all working in an ideal world is as follows:
1.) Driver reads eeprom of card for the permissible frequencies for that
hardware. It is only safe to allow the frequencies in the eeprom because
we cannot assume that any other values were calibrated in the hardware.
This information (or initial regulatory domain) should be passed up to
and immediately enforced by crda. Drivers shouldn't have their own
enforcement in addition to crda as we have a properly functioning
regulatory enforcement engine and having 1 per driver makes things
pointlessly complicated.
2.) If the user sets a reg domain, intersect user reg domain with eeprom
reg domain.
3.) When user connects to AP, if available, read country IE and
intersect that with the currently effective reg domain (which is at
least the eeprom and may include user input from step 2 as well).
I realize some distros have cool stuff happening like setting a reg
domain using the location from the timezone or some other cool thing.
For the purpose of this discussion however, that is really nothing
different from a user set reg domain (in fact I believe that is how it
is done) so let's not worry about those specifics of "well the user
didn't directly call iw reg set so blah blah blah".
How far off base am I here? I know that Intel enforces reg domain in
their ucode and we cannot do anything about it, but I'm more interested
in the cards where our drivers have full control. Are the drivers
themselves performing limiting that users don't even get to see? Or is
all this actually passed up to crda as it should be? I'm personally
especially interested in how the three atheros drivers do it, but I
think this discussion should extend beyond my personal interests and any
and all drivers should be discussed.
Thanks,
Rick Farina
^ permalink raw reply
* Re: Reading the RSSI from a Kernel Module
From: Richard Farina @ 2009-07-13 11:57 UTC (permalink / raw)
To: Tim Schneider, wireless
In-Reply-To: <2E605895-C629-47C5-8DF8-DF012A3749EB@cs.uni-bonn.de>
Tim Schneider wrote:
>
> Am 13.07.2009 um 08:59 schrieb Richard Farina:
>> I don't mean to make this a flame so please do not take it that way.
>> How exactly do you expect to get the RECEIVED Signal Strength
>> indication for a packet which you are SENDING? If you send it, you
>> don't receive it...
>>
>> Just my 0.02
>>
>> -Rick Farina
>
> Hi Rick,
>
> as far, as I understood, the RSSI-Mechanism also displays the signal
> strength of the just sent package. I figured there was some way the
> MAC-Layer transported that information, but you're right, I could be
> mistaken. Anyways, since I'm trying to implement a TCP Algorithm, i
> definitely have a two-way connection. Assuming, that the route back
> is going to be the same as it was on the way there (which basically
> should be true, based on the Routing algorithms we're using in our
> wireless mesh network), I could just use the RSSI Value of the
> received ACK.
>
Any RSSI on a sent packet will be a calculated number not an observed
number and as such it will be completely pointless for any kind of rate
control algorithm. Assuming that the card could actually receive the
packets it is sending (which it can't) then you would be observing a
24dBm signal (for instance) with 0 patch loss and your RSSI would be at
or above max. Realistically you can assume that every packet you sent
has a max RSSI on your end because you are the one transmitting it.
Now, if you want to know what the RSSI on the receiver side is that is a
completely different question, one which you cannot answer at all. When
you send a packet you do not have the good fortune to know what RSSI the
receiver got. You can roughly assume based on your RSSI when you get an
ACK, but honestly that isn't even close to correct because every packet
has a very unique experience in the air and you cannot assume things
like the same tx power and rx sensitivity will be the same on both
ends. There is some 802.11 protocol (the letter eludes me at present)
which is in draft form which adds information to packets so that both
ends know each other's RSSI, but I have never seen it implemented
anywhere yet.
I advise you keep the discussion on list as I am by no means an expert
and many people much better at this than I may respond.
-Rick Farina
> Regards,
>
> Tim Schneider
>
>
^ permalink raw reply
* Re: [PATCH] rfkill: fix rfkill_set_states() to set the hw state
From: Johannes Berg @ 2009-07-13 11:30 UTC (permalink / raw)
To: Alan Jenkins; +Cc: linux-wireless
In-Reply-To: <4A5A0941.2000408@tuffmail.co.uk>
[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]
On Sun, 2009-07-12 at 17:03 +0100, Alan Jenkins wrote:
> The point of this function is to set the software and hardware state at
> the same time. When I tried to use it, I found it was only setting the
> software state.
Oops, thanks.
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
This is for 2.6.31, obviously.
> Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
> ---
> net/rfkill/core.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> index 79693fe..db9948e 100644
> --- a/net/rfkill/core.c
> +++ b/net/rfkill/core.c
> @@ -549,6 +549,10 @@ void rfkill_set_states(struct rfkill *rfkill, bool
> sw, bool hw)
> swprev = !!(rfkill->state & RFKILL_BLOCK_SW);
> hwprev = !!(rfkill->state & RFKILL_BLOCK_HW);
> __rfkill_set_sw_state(rfkill, sw);
> + if (hw)
> + rfkill->state |= RFKILL_BLOCK_HW;
> + else
> + rfkill->state &= ~RFKILL_BLOCK_HW;
>
> spin_unlock_irqrestore(&rfkill->lock, flags);
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] mac80211_hwsim: fix use after free
From: Johannes Berg @ 2009-07-13 11:25 UTC (permalink / raw)
To: John Linville; +Cc: Jouni Malinen, linux-wireless
Once the "data" pointer is freed, we can't be iterating
to the next item in the list any more so we need to use
list_for_each_entry_safe with a temporary variable.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
drivers/net/wireless/mac80211_hwsim.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- wireless-testing.orig/drivers/net/wireless/mac80211_hwsim.c 2009-07-13 13:21:18.000000000 +0200
+++ wireless-testing/drivers/net/wireless/mac80211_hwsim.c 2009-07-13 13:21:42.000000000 +0200
@@ -790,7 +790,7 @@ static const struct ieee80211_ops mac802
static void mac80211_hwsim_free(void)
{
struct list_head tmplist, *i, *tmp;
- struct mac80211_hwsim_data *data;
+ struct mac80211_hwsim_data *data, *tmpdata;
INIT_LIST_HEAD(&tmplist);
@@ -799,7 +799,7 @@ static void mac80211_hwsim_free(void)
list_move(i, &tmplist);
spin_unlock_bh(&hwsim_radio_lock);
- list_for_each_entry(data, &tmplist, list) {
+ list_for_each_entry_safe(data, tmpdata, &tmplist, list) {
debugfs_remove(data->debugfs_group);
debugfs_remove(data->debugfs_ps);
debugfs_remove(data->debugfs);
^ 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