* Re: [PATCH] mac80211: fix oops in ieee80211_scan_state_set_channel()
From: Helmut Schaa @ 2009-07-25 18:34 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Johannes Berg, linux-wireless, John Linville, Larry Finger
In-Reply-To: <200907252015.07010.helmut.schaa@googlemail.com>
Am Samstag, 25. Juli 2009 schrieb Helmut Schaa:
> Am Samstag, 25. Juli 2009 schrieb Pavel Roskin:
> > Lack of SCAN_DONE in mac80211_scan_state. We exit scanning through the
> > "entry point".
>
> I also thought of a separate state SCAN_DONE or something similar but
> dropped that idea as the only thing this state would have to do is the
> call to ieee80211_scan_completed. So, once the scan is finished we
> just stay in SCAN_DECISION as long as the scan state machine gets poked
> again by a start_scan call.
Maybe we should add a state SCAN_IDLE which is entered after the scan
finished just for consistency?
Helmut
^ permalink raw reply
* Re: [PATCH] mac80211: fix oops in ieee80211_scan_state_set_channel()
From: Helmut Schaa @ 2009-07-25 18:15 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Johannes Berg, linux-wireless, John Linville, Larry Finger
In-Reply-To: <1248541636.2554.12.camel@ct>
Am Samstag, 25. Juli 2009 schrieb Pavel Roskin:
> On Sat, 2009-07-25 at 15:06 +0200, Helmut Schaa wrote:
>
> > Hmm, I'd prefer to keep the decision state as entry and exit point to
> > the scan state machine. The patch below should also fix this issue
> > by returning back to the decision state after every skipped channel.
>
> The patch is working and I'm fine with it.
Great, thanks a lot.
> We should fix that in the
> tree as soon as possible, or it will stand in the way of bisection.
Yes, you're right.
> I forgot to mention that the oops was happening in x86_64 with rt61pci
> and US regulatory domain. The device only works in the 2.4 GHz range.
>
> > In the long run I would like to move the channel selection also to
> > the decision state in order to implement various improvements (like
> > scanning multiple channels in a row or reordering the channel list).
>
> I don't know the code enough, but two things surprised me:
>
> Lack of SCAN_DONE in mac80211_scan_state. We exit scanning through the
> "entry point".
I also thought of a separate state SCAN_DONE or something similar but
dropped that idea as the only thing this state would have to do is the
call to ieee80211_scan_completed. So, once the scan is finished we
just stay in SCAN_DECISION as long as the scan state machine gets poked
again by a start_scan call.
> Use of "unsigned long" for bitwise fields, such as queue_stop_reasons
> and scanning. This reminds me of the good old days where long was
> always 32 bit, but int wasn't. I think "unsigned int" should be enough,
> and you can annotate it with __bitwise to make sparse catch some
> misuses.
No objections :)
Helmut
^ permalink raw reply
* Re: ath9k panic (ath_tx_rc_status)
From: Davide Pesavento @ 2009-07-25 17:39 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <20090724235804.GB26729@bombadil.infradead.org>
On Sat, Jul 25, 2009 at 01:58, Luis R.
Rodriguez<mcgrof@bombadil.infradead.org> wrote:
> On Sat, Jul 25, 2009 at 01:31:24AM +0200, Davide Pesavento wrote:
>> Hi,
>>
>> after the latest pull from wireless-testing
>> (2.6.31-rc4-wl-29133-g1addf37) I always get a kernel panic with the
>> ath9k driver. The panic happens as soon as I start wpa_supplicant
>> (with -Dnl80211) or NetworkManager. I think that the kernel spits out
>> some warnings (lockdep?) before crashing, but I haven't been able to
>> capture them.
>> This is a regression since my previous pull (2.6.31-rc3-wl... + something).
>
> Yup, wrong patch applied/sent/fuckup. Try the patch posted.
>
> Luis
>
Yes, I can confirm the patch fixes the panic. Thanks!
Davide
^ permalink raw reply
* RE: [PATCH 12/14] iwlwifi: debugFs to enable/disable 40MHz channel support
From: Guy, Wey-Yi W @ 2009-07-25 17:24 UTC (permalink / raw)
To: Gábor Stefanik, Chatre, Reinette
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <69e28c910907241440m470ee210v29ea1f971caf2f09@mail.gmail.com>
Sure, I will make the change and re-submit.
Wey-Yi Guy
Intel Corporation
2111 N.E. 25th Avenue M/S JF3-308
Hillsboro OR 97124-5961
USA
Work Phone: 503-264-6023 (OR)
Cell Phone: 503-329-8410
Email: wey-yi.w.guy@intel.com
-----Original Message-----
From: Gábor Stefanik [mailto:netrolller.3d@gmail.com]
Sent: Friday, July 24, 2009 2:41 PM
To: Chatre, Reinette
Cc: linville@tuxdriver.com; linux-wireless@vger.kernel.org; ipw3945-devel@lists.sourceforge.net; Guy, Wey-Yi W
Subject: Re: [PATCH 12/14] iwlwifi: debugFs to enable/disable 40MHz channel support
On Fri, Jul 24, 2009 at 8:13 PM, Reinette
Chatre<reinette.chatre@intel.com> wrote:
> From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
>
> Add debugfs file to enable/disable Fat(40MHz) channel support.
> By default, 40MHz is supported if AP can support the function.
>
> By echo "1" to "disable_fat_mode" file, iwlwifi driver will disable the 40MHz
> support and only allow 20MHz channel.
Please make that disable_ht40. The term "fat channel" is deprecated in
favor of "HT40".
>
> Because the information exchange happen during association time,
> so enable/disable fat channel only can be performed when it is not
> associated with AP.
>
> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
> ---
> drivers/net/wireless/iwlwifi/iwl-core.c | 4 ++
> drivers/net/wireless/iwlwifi/iwl-debug.h | 1 +
> drivers/net/wireless/iwlwifi/iwl-debugfs.c | 46 ++++++++++++++++++++++++++++
> drivers/net/wireless/iwlwifi/iwl-dev.h | 1 +
> 4 files changed, 52 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
> index 710dd41..edfdbe8 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-core.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-core.c
> @@ -632,6 +632,10 @@ u8 iwl_is_fat_tx_allowed(struct iwl_priv *priv,
> if (!sta_ht_inf->ht_supported)
> return 0;
> }
> +#ifdef CONFIG_IWLWIFI_DEBUG
> + if (priv->disable_fat)
> + return 0;
> +#endif
> return iwl_is_channel_extension(priv, priv->band,
> le16_to_cpu(priv->staging_rxon.channel),
> iwl_ht_conf->extension_chan_offset);
> diff --git a/drivers/net/wireless/iwlwifi/iwl-debug.h b/drivers/net/wireless/iwlwifi/iwl-debug.h
> index 609a681..2e10da3 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-debug.h
> +++ b/drivers/net/wireless/iwlwifi/iwl-debug.h
> @@ -88,6 +88,7 @@ struct iwl_debugfs {
> #ifdef CONFIG_IWLWIFI_LEDS
> struct dentry *file_led;
> #endif
> + struct dentry *file_disable_fat_mode;
> } dbgfs_data_files;
> struct dir_rf_files {
> struct dentry *file_disable_sensitivity;
> diff --git a/drivers/net/wireless/iwlwifi/iwl-debugfs.c b/drivers/net/wireless/iwlwifi/iwl-debugfs.c
> index 748dc31..03486d5 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-debugfs.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-debugfs.c
> @@ -653,6 +653,49 @@ static ssize_t iwl_dbgfs_thermal_throttling_read(struct file *file,
> return ret;
> }
>
> +static ssize_t iwl_dbgfs_disable_fat_mode_write(struct file *file,
> + const char __user *user_buf,
> + size_t count, loff_t *ppos)
> +{
> + struct iwl_priv *priv = file->private_data;
> + char buf[8];
> + int buf_size;
> + int fat_mode;
> +
> + memset(buf, 0, sizeof(buf));
> + buf_size = min(count, sizeof(buf) - 1);
> + if (copy_from_user(buf, user_buf, buf_size))
> + return -EFAULT;
> + if (sscanf(buf, "%d", &fat_mode) != 1)
> + return -EFAULT;
> + if (!iwl_is_associated(priv))
> + priv->disable_fat = fat_mode ? true : false;
> + else {
> + IWL_ERR(priv, "Sta associated with AP - "
> + "Change fat mode is not allowed\n");
> + return -EINVAL;
> + }
> +
> + return count;
> +}
> +
> +static ssize_t iwl_dbgfs_disable_fat_mode_read(struct file *file,
> + char __user *user_buf,
> + size_t count, loff_t *ppos)
> +{
> + struct iwl_priv *priv = (struct iwl_priv *)file->private_data;
> + char buf[100];
> + int pos = 0;
> + const size_t bufsz = sizeof(buf);
> + ssize_t ret;
> +
> + pos += scnprintf(buf + pos, bufsz - pos,
> + "11n 40Mhz Mode: %s\n",
> + priv->disable_fat ? "Disabled" : "Enabled");
> + ret = simple_read_from_buffer(user_buf, count, ppos, buf, pos);
> + return ret;
> +}
> +
> DEBUGFS_READ_WRITE_FILE_OPS(sram);
> DEBUGFS_WRITE_FILE_OPS(log_event);
> DEBUGFS_READ_FILE_OPS(nvm);
> @@ -667,6 +710,7 @@ DEBUGFS_READ_FILE_OPS(qos);
> DEBUGFS_READ_FILE_OPS(led);
> #endif
> DEBUGFS_READ_FILE_OPS(thermal_throttling);
> +DEBUGFS_READ_WRITE_FILE_OPS(disable_fat_mode);
>
> /*
> * Create the debugfs files and directories
> @@ -708,6 +752,7 @@ int iwl_dbgfs_register(struct iwl_priv *priv, const char *name)
> DEBUGFS_ADD_FILE(led, data);
> #endif
> DEBUGFS_ADD_FILE(thermal_throttling, data);
> + DEBUGFS_ADD_FILE(disable_fat_mode, data);
> DEBUGFS_ADD_BOOL(disable_sensitivity, rf, &priv->disable_sens_cal);
> DEBUGFS_ADD_BOOL(disable_chain_noise, rf,
> &priv->disable_chain_noise_cal);
> @@ -747,6 +792,7 @@ void iwl_dbgfs_unregister(struct iwl_priv *priv)
> DEBUGFS_REMOVE(priv->dbgfs->dbgfs_data_files.file_led);
> #endif
> DEBUGFS_REMOVE(priv->dbgfs->dbgfs_data_files.file_thermal_throttling);
> + DEBUGFS_REMOVE(priv->dbgfs->dbgfs_data_files.file_disable_fat_mode);
> DEBUGFS_REMOVE(priv->dbgfs->dir_data);
> DEBUGFS_REMOVE(priv->dbgfs->dbgfs_rf_files.file_disable_sensitivity);
> DEBUGFS_REMOVE(priv->dbgfs->dbgfs_rf_files.file_disable_chain_noise);
> diff --git a/drivers/net/wireless/iwlwifi/iwl-dev.h b/drivers/net/wireless/iwlwifi/iwl-dev.h
> index facbc3d..6101d12 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-dev.h
> +++ b/drivers/net/wireless/iwlwifi/iwl-dev.h
> @@ -1164,6 +1164,7 @@ struct iwl_priv {
> /* debugging info */
> u32 framecnt_to_us;
> atomic_t restrict_refcnt;
> + bool disable_fat;
> #ifdef CONFIG_IWLWIFI_DEBUGFS
> /* debugfs */
> struct iwl_debugfs *dbgfs;
> --
> 1.5.6.3
>
> --
> 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
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH] mac80211: fix oops in ieee80211_scan_state_set_channel()
From: Pavel Roskin @ 2009-07-25 17:07 UTC (permalink / raw)
To: Helmut Schaa; +Cc: Johannes Berg, linux-wireless, John Linville, Larry Finger
In-Reply-To: <200907251506.34943.helmut.schaa@googlemail.com>
On Sat, 2009-07-25 at 15:06 +0200, Helmut Schaa wrote:
> Hmm, I'd prefer to keep the decision state as entry and exit point to
> the scan state machine. The patch below should also fix this issue
> by returning back to the decision state after every skipped channel.
The patch is working and I'm fine with it. We should fix that in the
tree as soon as possible, or it will stand in the way of bisection.
I forgot to mention that the oops was happening in x86_64 with rt61pci
and US regulatory domain. The device only works in the 2.4 GHz range.
> In the long run I would like to move the channel selection also to
> the decision state in order to implement various improvements (like
> scanning multiple channels in a row or reordering the channel list).
I don't know the code enough, but two things surprised me:
Lack of SCAN_DONE in mac80211_scan_state. We exit scanning through the
"entry point".
Use of "unsigned long" for bitwise fields, such as queue_stop_reasons
and scanning. This reminds me of the good old days where long was
always 32 bit, but int wasn't. I think "unsigned int" should be enough,
and you can annotate it with __bitwise to make sparse catch some
misuses.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] mac80211: fix an oops in ieee80211_scan_state_set_channel
From: Larry Finger @ 2009-07-25 16:17 UTC (permalink / raw)
To: Helmut Schaa; +Cc: John Linville, Johannes Berg, Pavel Roskin, linux-wireless
In-Reply-To: <200907251725.52084.helmut.schaa@googlemail.com>
Helmut Schaa wrote:
> Fix an oops in ieee80211_scan_state_set_channel which was triggered
> if the last scanned channel was skipped (for example due to regulatory
> restrictions) by returning to the decision state after each skipped
> channel.
>
> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
> ---
Better late than never, but this patch does fix the problem for me.
Larry
^ permalink raw reply
* Re: [PATCH] nl80211: add missing parameter clearing
From: Maxim Levitsky @ 2009-07-25 16:09 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless, Jouni Malinen
In-Reply-To: <1248533676.19945.2.camel@johannes.local>
On Sat, 2009-07-25 at 16:54 +0200, Johannes Berg wrote:
> Jouni and Maxim reported an oops when using wpa_supplicant -Dnl80211,
> which seems to be due to random data being contained in the crypto
> settings for the assoc() command. This seems to be due to the missing
> memset here, so add it -- it's certainly missing but I'm not 100%
> certain that it will fix the problem.
Indeed this fixes it.
Although the NM still reports zero as signal level, and I see
[ 417.210115] No probe response from AP 00:1b:9e:d8:77:02 after 200ms,
disconnecting.
[ 419.363655] wlan0: direct probe to AP 00:1b:9e:d8:77:02 (try 1)
[ 419.369285] wlan0 direct probe responded
[ 419.369292] wlan0: authenticate with AP 00:1b:9e:d8:77:02 (try 1)
[ 419.371189] wlan0: authenticated
[ 419.371513] wlan0: associate with AP 00:1b:9e:d8:77:02 (try 1)
[ 419.374094] wlan0: RX AssocResp from 00:1b:9e:d8:77:02 (capab=0x411
status=0 aid=3)
Although it isn't visible any more.
Did wext compatibility layer got partially removed?
iwconfig does show now much
The last use of it, is to set tx power and bitrate, as this doesn't seem
to be implemented in iw.
Also NM applet doesn't show my network as connected. When I attempted to
connect it freezed the system.
Best regards,
Maxim Levitsky
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> ---
> net/wireless/nl80211.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> --- wireless-testing.orig/net/wireless/nl80211.c 2009-07-25 16:50:39.000000000 +0200
> +++ wireless-testing/net/wireless/nl80211.c 2009-07-25 16:51:00.000000000 +0200
> @@ -3385,6 +3385,8 @@ static int nl80211_crypto_settings(struc
> struct cfg80211_crypto_settings *settings,
> int cipher_limit)
> {
> + memset(settings, 0, sizeof(*settings));
> +
> settings->control_port = info->attrs[NL80211_ATTR_CONTROL_PORT];
>
> if (info->attrs[NL80211_ATTR_CIPHER_SUITES_PAIRWISE]) {
>
>
^ permalink raw reply
* [PATCH] mac80211: fix an oops in ieee80211_scan_state_set_channel
From: Helmut Schaa @ 2009-07-25 15:25 UTC (permalink / raw)
To: John Linville; +Cc: Johannes Berg, Pavel Roskin, linux-wireless, Larry Finger
Fix an oops in ieee80211_scan_state_set_channel which was triggered
if the last scanned channel was skipped (for example due to regulatory
restrictions) by returning to the decision state after each skipped
channel.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
---
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index b376775..147772a 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -605,8 +605,11 @@ static void ieee80211_scan_state_set_channel(struct ieee80211_local *local,
/* advance state machine to next channel/band */
local->scan_channel_idx++;
- if (skip)
+ if (skip) {
+ /* if we skip this channel return to the decision state */
+ local->next_scan_state = SCAN_DECISION;
return;
+ }
/*
* Probe delay is used to update the NAV, cf. 11.1.3.2.2
^ permalink raw reply related
* [PATCH] nl80211: add missing parameter clearing
From: Johannes Berg @ 2009-07-25 14:54 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Jouni Malinen, Maxim Levitsky
Jouni and Maxim reported an oops when using wpa_supplicant -Dnl80211,
which seems to be due to random data being contained in the crypto
settings for the assoc() command. This seems to be due to the missing
memset here, so add it -- it's certainly missing but I'm not 100%
certain that it will fix the problem.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/wireless/nl80211.c | 2 ++
1 file changed, 2 insertions(+)
--- wireless-testing.orig/net/wireless/nl80211.c 2009-07-25 16:50:39.000000000 +0200
+++ wireless-testing/net/wireless/nl80211.c 2009-07-25 16:51:00.000000000 +0200
@@ -3385,6 +3385,8 @@ static int nl80211_crypto_settings(struc
struct cfg80211_crypto_settings *settings,
int cipher_limit)
{
+ memset(settings, 0, sizeof(*settings));
+
settings->control_port = info->attrs[NL80211_ATTR_CONTROL_PORT];
if (info->attrs[NL80211_ATTR_CIPHER_SUITES_PAIRWISE]) {
^ permalink raw reply
* Re: [PATCH] mac80211: fix receiving deauth
From: Marcel Holtmann @ 2009-07-25 14:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless, Reinette Chatre
In-Reply-To: <1248527245.28545.162.camel@violet>
Hi Johannes,
> > Marcel reported a warning, which quite obviously comes
> > from an oversight in the code handling deauth frames,
> > and which resulted in multiple follow-up warnings due
> > to this missing handling. This patch adds the missing
> > deauth handling (telling cfg80211 about it) and also
> > removes the follow-up warnings since they could happen
> > due to races even if nothing is wrong. I've explained
> > the races in the comments.
> >
> > Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> > Reported-by: Marcel Holtmann <marcel@holtmann.org>
>
> so me current wireless-testing tree now contains the tree from today
> with the oops fix from Luiz, your lockdep fix, Reinette's iwlwifi
> updates and this one. No oopses so far and my connection to the AP stays
> stable. No immediate disconnects anymore. Everything looks good again.
while this fixes the oops and helps with my connect/disconnect issues I
have seen, it doesn't fully fix them. As soon as the AP is something
like more than 5m or 10m away, it connects, disconnects, re-connects
etc. all over again :(
Regards
Marcel
^ permalink raw reply
* [BUG] Current head of wireless testing unusable
From: Maxim Levitsky @ 2009-07-25 14:10 UTC (permalink / raw)
To: linux-wireless, iwlwifi maling list
I probably should work more to did these bugs out myself, but anyway I
want to let you know what I currently see.
First system oopses just after NM starts up, happens always, and after
planting few test points bug happens somewhere in following lines.
net/mac80211/mlme.c:ieee80211_mgd_assoc:
> list_add(&wk->list, &ifmgd->work_list);
>
> ifmgd->flags &= ~IEEE80211_STA_DISABLE_11N;
>
> for (i = 0; i < req->crypto.n_ciphers_pairwise; i++)
> if (req->crypto.ciphers_pairwise[i] == WLAN_CIPHER_SUITE_WEP40 ||
> req->crypto.ciphers_pairwise[i] == WLAN_CIPHER_SUITE_TKIP ||
> req->crypto.ciphers_pairwise[i] == WLAN_CIPHER_SUITE_WEP104)
> ifmgd->flags |= IEEE80211_STA_DISABLE_11N;
>
>
The oops message
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087268] PGD 1002063 PUD 8067 PMD 9067 PTE 0
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087282] CPU 0
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087285] Modules linked in: af_packet sco bridge stp llc rfcomm bnep l2cap bluetooth nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc usb_storage usb_libusual cpufreq_powersave cpufreq_conservative cpufreq_userspace acpi_cpufreq coretemp sbp2 joydev uvcvideo iwl3945 videodev v4l1_compat v4l2_compat_ioctl32 iwlcore snd_hda_codec_realtek mac80211 snd_hda_intel snd_hda_codec cfg80211 snd_hwdep acer_wmi backlight psmouse snd_pcm snd_timer tg3 sdhci_pci uhci_hcd ehci_hcd rfkill serio_raw snd_page_alloc libphy sdhci usbcore ohci1394 iTCO_wdt iTCO_vendor_support wmi evdev fuse
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087337] Pid: 4061, comm: wpa_supplicant Not tainted 2.6.31-rc4-wl #31 Aspire 5720
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087340] RIP: 0010:[<ffffffffa018cbeb>] [<ffffffffa018cbeb>] ieee80211_mgd_assoc+0x18b/0x320 [mac80211]
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087355] RSP: 0018:ffff88007e4bf7b8 EFLAGS: 00010212
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087358] RAX: 00000000fff053ff RBX: ffff88007e6d5600 RCX: 0000000000000000
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087361] RDX: 000000000066c1e3 RSI: ffff88007fe6ffd4 RDI: ffffffff8161f870
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087364] RBP: ffff88007e4bf7e8 R08: 0000000000000000 R09: 0000000000000001
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087366] R10: 000000000000000a R11: 0000000000000000 R12: ffff88007e1d7a60
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087369] R13: ffff88007e4bf848 R14: ffff88007e1d7580 R15: ffff88007e1d7a38
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087372] FS: 00007f2f97d7e6f0(0000) GS:ffff8800016a3000(0000) knlGS:0000000000000000
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087375] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087378] CR2: ffff88007fe70000 CR3: 000000007f273000 CR4: 00000000000006f0
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087381] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087383] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087387] Process wpa_supplicant (pid: 4061, threadinfo ffff88007e4be000, task ffff8800748f4230)
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087391] ffff88007e99d000 00000000fffffffe ffff88007e1d7590 ffff88007e4bf848
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087396] <0> ffff88007e820180 ffff88007e1d7000 ffff88007e4bf7f8 ffffffffa0193363
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087400] <0> ffff88007e4bf8d8 ffffffffa014aba8 0000000000000001 0000000000000304
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087421] [<ffffffffa0193363>] ieee80211_assoc+0x13/0x20 [mac80211]
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087437] [<ffffffffa014aba8>] __cfg80211_mlme_assoc+0x1a8/0x1b0 [cfg80211]
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087449] [<ffffffffa014ac3a>] cfg80211_mlme_assoc+0x8a/0xb0 [cfg80211]
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087461] [<ffffffffa013b3e9>] ? cfg80211_get_dev_from_ifindex+0x79/0x90 [cfg80211]
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087474] [<ffffffffa0143661>] nl80211_associate+0x221/0x230 [cfg80211]
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087481] [<ffffffff81340b06>] genl_rcv_msg+0x1b6/0x1f0
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087485] [<ffffffff81340950>] ? genl_rcv_msg+0x0/0x1f0
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087489] [<ffffffff813408e9>] netlink_rcv_skb+0x89/0xb0
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087493] [<ffffffff81340937>] genl_rcv+0x27/0x40
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087496] [<ffffffff81340449>] ? netlink_sendmsg+0x159/0x300
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087500] [<ffffffff813402da>] netlink_unicast+0x2da/0x2f0
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087505] [<ffffffff8131fefe>] ? __alloc_skb+0x6e/0x170
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087509] [<ffffffff813404ee>] netlink_sendmsg+0x1fe/0x300
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087515] [<ffffffff810ac158>] ? generic_file_buffered_write+0x128/0x340
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087519] [<ffffffff8134024e>] ? netlink_unicast+0x24e/0x2f0
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087524] [<ffffffff81316ed7>] sock_sendmsg+0x127/0x140
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087529] [<ffffffff81063ee0>] ? autoremove_wake_function+0x0/0x40
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087534] [<ffffffff8132902d>] ? netdev_run_todo+0x4d/0x240
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087538] [<ffffffff81334359>] ? rtnl_unlock+0x9/0x10
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087543] [<ffffffff813a009e>] ? wext_ioctl_dispatch+0xbe/0x200
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087547] [<ffffffff8139fe40>] ? ioctl_standard_call+0x0/0xe0
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087552] [<ffffffff810ad382>] ? generic_file_aio_write+0x72/0xd0
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087556] [<ffffffff81315b1b>] ? move_addr_to_kernel+0x2b/0x40
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087559] [<ffffffff8132151c>] ? verify_iovec+0x3c/0xd0
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087563] [<ffffffff81317079>] sys_sendmsg+0x189/0x320
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087567] [<ffffffff81063ee0>] ? autoremove_wake_function+0x0/0x40
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087572] [<ffffffff810f05d1>] ? vfs_ioctl+0x31/0xa0
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087576] [<ffffffff810f0acb>] ? do_vfs_ioctl+0x3fb/0x580
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087581] [<ffffffff810e194f>] ? vfs_write+0x13f/0x1a0
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087587] [<ffffffff8100beeb>] system_call_fastpath+0x16/0x1b
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087645] RSP <ffff88007e4bf7b8>
Jul 25 15:53:59 maxim-laptop kernel: [ 38.087650] ---[ end trace f5ad5d447afd4b36 ]---
As a first aid I noticed that if I kill wpa_supplicant (I have modified
dbus settings not to start it automatically)
And start it manually (wpa_supplicant -u) NM will talk to it and
connect.
Then many more surprises:
maxim@maxim-laptop:~$ iwconfig
lo no wireless extensions.
eth0 no wireless extensions.
wlan0 IEEE 802.11bg Mode:Managed Access Point: Not-Associated
Tx-Power=15 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off
pan0 no wireless extensions.
NM doesn't even show that it is connected.
I use nl80211 in wpa_supplicant btw.
On top of that wireless disconnects and reconnects every few minutes
with that in dmesg:
[ 4252.387686] wlan0: associate with AP 00:1b:9e:d8:77:02 (try 1)
[ 4252.391177] wlan0: RX AssocResp from 00:1b:9e:d8:77:02 (capab=0x411 status=0 aid=3)
[ 4252.391182] wlan0: associated
[ 4255.240133] No probe response from AP 00:1b:9e:d8:77:02 after 200ms, disconnecting.
[ 4257.391739] wlan0: direct probe to AP 00:1b:9e:d8:77:02 (try 1)
[ 4257.590128] wlan0: direct probe to AP 00:1b:9e:d8:77:02 (try 2)
[ 4257.790101] wlan0: direct probe to AP 00:1b:9e:d8:77:02 (try 3)
[ 4257.990064] wlan0: direct probe to AP 00:1b:9e:d8:77:02 timed out
[ 4264.031984] wlan0: direct probe to AP 00:1b:9e:d8:77:02 (try 1)
[ 4264.230112] wlan0: direct probe to AP 00:1b:9e:d8:77:02 (try 2)
[ 4264.440100] wlan0: direct probe to AP 00:1b:9e:d8:77:02 (try 3)
[ 4264.640098] wlan0: direct probe to AP 00:1b:9e:d8:77:02 timed out
[ 4270.662053] wlan0: direct probe to AP 00:1b:9e:d8:77:02 (try 1)
[ 4270.665611] wlan0 direct probe responded
[ 4270.665617] wlan0: authenticate with AP 00:1b:9e:d8:77:02 (try 1)
[ 4270.667542] wlan0: authenticated
And this despite me sitting next to my AP.
I have iwl3945, latest wireless testing (pulled a hour ago)
I didn't update anything in more that two months, now I have updated the kernel and wpa_supplicant
(I did wpa_supplicant update first, and it seems not to affect anything, and besides older kernel works just fine)
Best regards,
Maxim Levitsky
^ permalink raw reply
* Re: [PATCH] mac80211: fix receiving deauth
From: Marcel Holtmann @ 2009-07-25 13:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless, Reinette Chatre
In-Reply-To: <1248515916.19945.1.camel@johannes.local>
Hi Johannes,
> Marcel reported a warning, which quite obviously comes
> from an oversight in the code handling deauth frames,
> and which resulted in multiple follow-up warnings due
> to this missing handling. This patch adds the missing
> deauth handling (telling cfg80211 about it) and also
> removes the follow-up warnings since they could happen
> due to races even if nothing is wrong. I've explained
> the races in the comments.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> Reported-by: Marcel Holtmann <marcel@holtmann.org>
so me current wireless-testing tree now contains the tree from today
with the oops fix from Luiz, your lockdep fix, Reinette's iwlwifi
updates and this one. No oopses so far and my connection to the AP stays
stable. No immediate disconnects anymore. Everything looks good again.
Tested-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] mac80211: fix oops in ieee80211_scan_state_set_channel()
From: Helmut Schaa @ 2009-07-25 13:06 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Johannes Berg, linux-wireless, John Linville, Larry Finger
In-Reply-To: <20090725051801.2965.76768.stgit@ct.roinet.com>
Am Samstag, 25. Juli 2009 schrieb Pavel Roskin:
> Move check for the final value of local->scan_channel_idx from
> ieee80211_scan_state_decision() to ieee80211_scan_state_set_channel().
>
> Stop the state machine in ieee80211_scan_work() by checking
> local->scanning. Don't return a value from
> ieee80211_scan_state_decision().
Hmm, I'd prefer to keep the decision state as entry and exit point to
the scan state machine. The patch below should also fix this issue
by returning back to the decision state after every skipped channel.
In the long run I would like to move the channel selection also to
the decision state in order to implement various improvements (like
scanning multiple channels in a row or reordering the channel list).
I was in the meantime able to reproduce the oops by setting an other
regulatory domain. Pavel, Larry, does this patch help you as well?
Thanks,
Helmut
---
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index b376775..147772a 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -605,8 +605,11 @@ static void ieee80211_scan_state_set_channel(struct ieee80211_local *local,
/* advance state machine to next channel/band */
local->scan_channel_idx++;
- if (skip)
+ if (skip) {
+ /* if we skip this channel return to the decision state */
+ local->next_scan_state = SCAN_DECISION;
return;
+ }
/*
* Probe delay is used to update the NAV, cf. 11.1.3.2.2
^ permalink raw reply related
* Re: [patch] wireless: ERR_PTR vs null
From: Marcel Holtmann @ 2009-07-25 12:46 UTC (permalink / raw)
To: Dan Carpenter; +Cc: samuel.ortiz, yi.zhu, linux-wireless
In-Reply-To: <alpine.DEB.2.00.0907241000250.11771@bicker>
Hi Dan,
> iwm_wdev_alloc() returns an ERR_PTR on failure and not null. It also
> prints its own dev_err() message so I removed that as well.
>
> Compile tested only. Sorry.
> Found by smatch (http://repo.or.cz/w/smatch.git).
>
> regards,
> dan carpenter
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
>
> --- orig/drivers/net/wireless/iwmc3200wifi/netdev.c 2009-07-24 09:56:49.000000000 +0300
> +++ devel/drivers/net/wireless/iwmc3200wifi/netdev.c 2009-07-24 09:57:31.000000000 +0300
> @@ -106,10 +106,8 @@
> int ret = 0;
>
> wdev = iwm_wdev_alloc(sizeof_bus, dev);
> - if (!wdev) {
> - dev_err(dev, "no memory for wireless device instance\n");
> - return ERR_PTR(-ENOMEM);
> - }
> + if (IS_ERR(wdev))
> + return wdev;
>
> iwm = wdev_to_iwm(wdev);
> iwm->bus_ops = if_ops;
I just quickly double-checked with the code. Patch looks good.
Regards
Marcel
^ permalink raw reply
* [patch] wireless: ERR_PTR vs null
From: Dan Carpenter @ 2009-07-25 12:22 UTC (permalink / raw)
To: samuel.ortiz, yi.zhu; +Cc: linux-wireless
iwm_wdev_alloc() returns an ERR_PTR on failure and not null. It also
prints its own dev_err() message so I removed that as well.
Compile tested only. Sorry.
Found by smatch (http://repo.or.cz/w/smatch.git).
regards,
dan carpenter
Signed-off-by: Dan Carpenter <error27@gmail.com>
--- orig/drivers/net/wireless/iwmc3200wifi/netdev.c 2009-07-24 09:56:49.000000000 +0300
+++ devel/drivers/net/wireless/iwmc3200wifi/netdev.c 2009-07-24 09:57:31.000000000 +0300
@@ -106,10 +106,8 @@
int ret = 0;
wdev = iwm_wdev_alloc(sizeof_bus, dev);
- if (!wdev) {
- dev_err(dev, "no memory for wireless device instance\n");
- return ERR_PTR(-ENOMEM);
- }
+ if (IS_ERR(wdev))
+ return wdev;
iwm = wdev_to_iwm(wdev);
iwm->bus_ops = if_ops;
^ permalink raw reply
* [PATCH] mac80211: fix receiving deauth
From: Johannes Berg @ 2009-07-25 9:58 UTC (permalink / raw)
To: John Linville; +Cc: Marcel Holtmann, linux-wireless
Marcel reported a warning, which quite obviously comes
from an oversight in the code handling deauth frames,
and which resulted in multiple follow-up warnings due
to this missing handling. This patch adds the missing
deauth handling (telling cfg80211 about it) and also
removes the follow-up warnings since they could happen
due to races even if nothing is wrong. I've explained
the races in the comments.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Reported-by: Marcel Holtmann <marcel@holtmann.org>
---
net/mac80211/mlme.c | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
--- wireless-testing.orig/net/mac80211/mlme.c 2009-07-25 11:03:12.000000000 +0200
+++ wireless-testing/net/mac80211/mlme.c 2009-07-25 11:55:35.000000000 +0200
@@ -2003,6 +2003,9 @@ static void ieee80211_sta_rx_queued_mgmt
case RX_MGMT_CFG80211_ASSOC:
cfg80211_send_rx_assoc(sdata->dev, (u8 *) mgmt, skb->len);
break;
+ case RX_MGMT_CFG80211_DEAUTH:
+ cfg80211_send_deauth(sdata->dev, (u8 *)mgmt, skb->len, NULL);
+ break;
default:
WARN(1, "unexpected: %d", rma);
}
@@ -2498,8 +2501,13 @@ int ieee80211_mgd_deauth(struct ieee8021
}
}
- /* cfg80211 should catch this... */
- if (WARN_ON(!bssid)) {
+ /*
+ * cfg80211 should catch this ... but it's racy since
+ * we can receive a deauth frame, process it, hand it
+ * to cfg80211 while that's in a locked section already
+ * trying to tell us that the user wants to disconnect.
+ */
+ if (!bssid) {
mutex_unlock(&ifmgd->mtx);
return -ENOLINK;
}
@@ -2524,8 +2532,13 @@ int ieee80211_mgd_disassoc(struct ieee80
mutex_lock(&ifmgd->mtx);
- /* cfg80211 should catch that */
- if (WARN_ON(&ifmgd->associated->cbss != req->bss)) {
+ /*
+ * cfg80211 should catch this ... but it's racy since
+ * we can receive a disassoc frame, process it, hand it
+ * to cfg80211 while that's in a locked section already
+ * trying to tell us that the user wants to disconnect.
+ */
+ if (&ifmgd->associated->cbss != req->bss) {
mutex_unlock(&ifmgd->mtx);
return -ENOLINK;
}
^ permalink raw reply
* Re: [PATCH] mac80211: fix oops in ieee80211_scan_state_set_channel()
From: Helmut Schaa @ 2009-07-25 9:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: Pavel Roskin, linux-wireless, John Linville, Larry Finger
In-Reply-To: <1248512095.32151.50.camel@johannes.local>
Am Samstag, 25. Juli 2009 schrieb Johannes Berg:
> On Sat, 2009-07-25 at 01:18 -0400, Pavel Roskin wrote:
> > Move check for the final value of local->scan_channel_idx from
> > ieee80211_scan_state_decision() to ieee80211_scan_state_set_channel().
> >
> > Stop the state machine in ieee80211_scan_work() by checking
> > local->scanning. Don't return a value from
> > ieee80211_scan_state_decision().
>
> Helmut, can you please take a look at this? I'm not entirely sure what's
> going on.
That's strange. I cannot reproduce the oops here :(
Investigating ...
Thanks,
Helmut
^ permalink raw reply
* Re: wireless-testing regression: iwl3945 scan fails
From: Kalle Valo @ 2009-07-25 9:18 UTC (permalink / raw)
To: Johannes Berg; +Cc: reinette chatre, linux-wireless@vger.kernel.org
In-Reply-To: <1248510692.32151.46.camel@johannes.local>
Johannes Berg <johannes@sipsolutions.net> writes:
>> This is getting very odd, I cannot reproduce the problem anymore with
>> rc4-wl. Just to be safe, I rebooted back to rc3-wl and I was immediately
>> able to reproduce it. To summarise, rc2-wl and rc4-wl were ok and only
>> rc3-wl is broken. So something fixed this, I just don't know what.
>
> That makes sense though, I posted a fix for at least a similar problem
> that only happened right after bootup ;)
The patch in question:
commit 8b0fd0af6b36b2123af7da4eabe228d1fc101e38
Author: Johannes Berg <johannes@sipsolutions.net>
Date: Thu Jul 23 16:50:16 2009 +0200
mac80211: fix mlme timeouts
I tried reverting the patch in rc4-wl and I again was able to reproduce
the problem. This confirms that the patch fixed it. Thanks.
Tested-by: Kalle Valo <kalle.valo@iki.fi>
--
Kalle Valo
^ permalink raw reply
* Re: new lockdep warning in 2.6.31-rc3-wl
From: Johannes Berg @ 2009-07-25 9:13 UTC (permalink / raw)
To: reinette chatre; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1248461132.1216.53.camel@rc-desk>
[-- Attachment #1: Type: text/plain, Size: 2351 bytes --]
Reinette, Luis,
It's easy to see why this is happening, but I have no easy fix.
> [ 65.053694] phy0/3223 is trying to acquire lock:
> [ 65.053738] (cfg80211_mutex){+.+.+.}, at: [<ffffffffa01c9a72>] regulatory_hint_11d+0x32/0x430 [cfg80211]
> [ 65.053887]
> [ 65.053888] but task is already holding lock:
> [ 65.053968] (&ifmgd->mtx){+.+.+.}, at: [<ffffffffa0220f78>] ieee80211_sta_work+0x118/0x11c0 [mac80211]
Clearly, ifmgd->mtx has to be taken from a bunch of cfg80211 calls, but
all calls from cfg80211 into mac80211 hold the cfg80211_mutex.
Now the problem here is that regulatory_hint_11d takes the
cfg80211_mutex.
I looked at two possible solutions:
1) Remove the requirement to hold cfg80211_mutex in cfg80211 for this
function. This is my preferred solution, since I don't think a hint
function should have strange locking constraints. However, the
function accesses a whole bunch of global variables and right now I
don't see how to reduce that, except possibly by allocating and
queueing new work struct, but then I don't see how to cancel that
work struct when the wiphy is unregistered while it might be pending.
2) Move the regulatory_hint_11d call outside the ifmgd->mtx locked
section. This isn't nice, as it means we require more effort from the
callers. Also, I think it's not sufficient, because mac80211 has to
cancel_work_sync() the sta work, which would be calling this, when an
interface is taken down --- BUT taking down an interface can happen,
when it's simply removed with nl80211 (!), within cfg80211 context,
and as such again under the lock, which has the same problem.
3) Remove the regulatory_hint_11d function (or rather make it not
exported), and instead pass the country IE (or the whole beacon
frame) to regulatory_hint_found_beacon(), and process it all from the
regulatory work that hint_found_beacon queues. That also reduces the
number of entry points from drivers, and means that if the driver
uses cfg80211-based scanning, it also automatically takes part in the
regulatory infrastructure. Win.
Obviously 3) is my favourite solution, not only because it's the only
one that seems feasible at all, but it's somewhat more complex, and I
don't really have time to do that today.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] mac80211: fix oops in ieee80211_scan_state_set_channel()
From: Johannes Berg @ 2009-07-25 8:54 UTC (permalink / raw)
To: Pavel Roskin; +Cc: linux-wireless, John Linville, Larry Finger, Helmut Schaa
In-Reply-To: <20090725051801.2965.76768.stgit@ct.roinet.com>
[-- Attachment #1: Type: text/plain, Size: 3052 bytes --]
On Sat, 2009-07-25 at 01:18 -0400, Pavel Roskin wrote:
> Move check for the final value of local->scan_channel_idx from
> ieee80211_scan_state_decision() to ieee80211_scan_state_set_channel().
>
> Stop the state machine in ieee80211_scan_work() by checking
> local->scanning. Don't return a value from
> ieee80211_scan_state_decision().
Helmut, can you please take a look at this? I'm not entirely sure what's
going on.
johannes
> Signed-off-by: Pavel Roskin <proski@gnu.org>
> ---
> net/mac80211/scan.c | 22 +++++++++++-----------
> 1 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
> index b376775..8b5a4a3 100644
> --- a/net/mac80211/scan.c
> +++ b/net/mac80211/scan.c
> @@ -470,18 +470,12 @@ static int __ieee80211_start_scan(struct ieee80211_sub_if_data *sdata,
> return rc;
> }
>
> -static int ieee80211_scan_state_decision(struct ieee80211_local *local,
> - unsigned long *next_delay)
> +static void ieee80211_scan_state_decision(struct ieee80211_local *local,
> + unsigned long *next_delay)
> {
> bool associated = false;
> struct ieee80211_sub_if_data *sdata;
>
> - /* if no more bands/channels left, complete scan and advance to the idle state */
> - if (local->scan_channel_idx >= local->scan_req->n_channels) {
> - ieee80211_scan_completed(&local->hw, false);
> - return 1;
> - }
> -
> /* check if at least one STA interface is associated */
> mutex_lock(&local->iflist_mtx);
> list_for_each_entry(sdata, &local->interfaces, list) {
> @@ -517,7 +511,6 @@ static int ieee80211_scan_state_decision(struct ieee80211_local *local,
> }
>
> *next_delay = 0;
> - return 0;
> }
>
> static void ieee80211_scan_state_leave_oper_channel(struct ieee80211_local *local,
> @@ -587,6 +580,12 @@ static void ieee80211_scan_state_set_channel(struct ieee80211_local *local,
> struct ieee80211_channel *chan;
> struct ieee80211_sub_if_data *sdata = local->scan_sdata;
>
> + /* if no more bands/channels left, complete scan and advance to the idle state */
> + if (local->scan_channel_idx >= local->scan_req->n_channels) {
> + ieee80211_scan_completed(&local->hw, false);
> + return;
> + }
> +
> skip = 0;
> chan = local->scan_req->channels[local->scan_channel_idx];
>
> @@ -695,8 +694,7 @@ void ieee80211_scan_work(struct work_struct *work)
> do {
> switch (local->next_scan_state) {
> case SCAN_DECISION:
> - if (ieee80211_scan_state_decision(local, &next_delay))
> - return;
> + ieee80211_scan_state_decision(local, &next_delay);
> break;
> case SCAN_SET_CHANNEL:
> ieee80211_scan_state_set_channel(local, &next_delay);
> @@ -711,6 +709,8 @@ void ieee80211_scan_work(struct work_struct *work)
> ieee80211_scan_state_enter_oper_channel(local, &next_delay);
> break;
> }
> + if (!local->scanning)
> + return;
> } while (next_delay == 0);
>
> queue_delayed_work(local->hw.workqueue, &local->scan_work,
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] cfg80211: fix circular lock dependency (1)
From: Johannes Berg @ 2009-07-25 8:54 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Luis R. Rodriguez
Luis reported this lockdep complaint, that he had also
reported earlier but when trying to analyse I had been
locking at the wrong code, and never saw the problem:
(slightly abridged)
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.31-rc4-wl #6
-------------------------------------------------------
wpa_supplicant/3799 is trying to acquire lock:
(cfg80211_mutex){+.+.+.}, at: [<ffffffffa009246a>] cfg80211_get_dev_from_ifindex+0x1a/0x90 [cfg80211]
but task is already holding lock:
(rtnl_mutex){+.+.+.}, at: [<ffffffff81400ff2>] rtnl_lock+0x12/0x20
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (rtnl_mutex){+.+.+.}:
[<ffffffff810857b6>] __lock_acquire+0xd76/0x12b0
[<ffffffff81085dd3>] lock_acquire+0xe3/0x120
[<ffffffff814ee7a4>] mutex_lock_nested+0x44/0x350
[<ffffffff81400ff2>] rtnl_lock+0x12/0x20
[<ffffffffa009f6a5>] nl80211_send_reg_change_event+0x1f5/0x2a0 [cfg80211]
[<ffffffffa009529e>] set_regdom+0x28e/0x4c0 [cfg80211]
-> #0 (cfg80211_mutex){+.+.+.}:
[<ffffffff8108587b>] __lock_acquire+0xe3b/0x12b0
[<ffffffff81085dd3>] lock_acquire+0xe3/0x120
[<ffffffff814ee7a4>] mutex_lock_nested+0x44/0x350
[<ffffffffa009246a>] cfg80211_get_dev_from_ifindex+0x1a/0x90 [cfg80211]
[<ffffffffa009813f>] get_rdev_dev_by_info_ifindex+0x6f/0xa0 [cfg80211]
[<ffffffffa009b12b>] nl80211_set_interface+0x3b/0x260 [cfg80211]
When looking at the correct code, the problem is quite
obvious. I'm not entirely sure which code paths lead
here, so until I can analyse it better let's just use
RCU to avoid the problem.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/wireless/nl80211.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- wireless-testing.orig/net/wireless/nl80211.c 2009-07-25 10:49:13.000000000 +0200
+++ wireless-testing/net/wireless/nl80211.c 2009-07-25 10:49:24.000000000 +0200
@@ -4517,10 +4517,10 @@ void nl80211_send_reg_change_event(struc
return;
}
- rtnl_lock();
+ rcu_read_lock();
genlmsg_multicast_allns(msg, 0, nl80211_regulatory_mcgrp.id,
- GFP_KERNEL);
- rtnl_unlock();
+ GFP_ATOMIC);
+ rcu_read_unlock();
return;
^ permalink raw reply
* Re: [PATCH] mac80211: redefine usage of the mac80211 workqueue
From: Johannes Berg @ 2009-07-25 8:35 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linville, linux-wireless, ath9k-devel, Reinette Chatre,
Dan Williams, Lennert Buytenhek, Daniel Drake
In-Reply-To: <1248482853-17032-2-git-send-email-lrodriguez@atheros.com>
[-- Attachment #1: Type: text/plain, Size: 979 bytes --]
On Fri, 2009-07-24 at 20:47 -0400, Luis R. Rodriguez wrote:
> The mac80211 workqueue exists to enable mac80211 and drivers
> to queue their own work on a single threaded workqueue. mac80211
> takes care to flush the workqueue during suspend but we never
> really had requirements on drivers for how they should use
> the workqueue in consideration for suspend.
>
> We extend mac80211 to document how the mac80211 workqueue should
> be used, how it should not be used and finally move raw access to
> the workqueue to mac80211 only. Drivers and mac80211 use helpers
> to queue work and flush the mac80211 workqueue:
>
> * ieee80211_queue_work()
> * ieee80211_queue_delayed_work()
> * ieee80211_flush_workqueue()
I would prefer to have wait_on_work() and/or cancel_work_sync() instead
of flushing? It's often preferable due to locking constraints to
cancel_work_sync() instead of flush_workqueue(). Do people really need
flush_workqueue()?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: wireless-testing regression: iwl3945 scan fails
From: Johannes Berg @ 2009-07-25 8:31 UTC (permalink / raw)
To: Kalle Valo; +Cc: reinette chatre, linux-wireless@vger.kernel.org
In-Reply-To: <87skglqpb0.fsf@litku.valot.fi>
[-- Attachment #1: Type: text/plain, Size: 865 bytes --]
On Sat, 2009-07-25 at 08:55 +0300, Kalle Valo wrote:
> Kalle Valo <kalle.valo@iki.fi> writes:
>
> > reinette chatre <reinette.chatre@intel.com> writes:
> >
> >> Are you saying that this problem occurs always with wpa_supplicant and
> >> sometimes with iw?
> >
> > I did some more testing and I can now reproduce this with iw as well. I
> > just need to reboot my laptop to reproduce it. I'll debug this more on a
> > rainy day.
>
> This is getting very odd, I cannot reproduce the problem anymore with
> rc4-wl. Just to be safe, I rebooted back to rc3-wl and I was immediately
> able to reproduce it. To summarise, rc2-wl and rc4-wl were ok and only
> rc3-wl is broken. So something fixed this, I just don't know what.
That makes sense though, I posted a fix for at least a similar problem
that only happened right after bootup ;)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: PCI express card that does AP mode? (abit wlp-01?)
From: Jon Fairbairn @ 2009-07-25 7:46 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1248452675.32151.31.camel@johannes.local>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Fri, 2009-07-24 at 17:16 +0100, Jon Fairbairn wrote:
>> (In the "asking for the moon on a stick" department, it would be handy
>> to have a table somewhere with "supported features" and "form factor"
>> dropdowns, so that I could have selected "AP" and "PCIe" and get the
>> card I now have ;-)
[...]
> I'm starting to think we should remove all the numbers (pci vendor,
> product, subvendor, subsystem) in favour of more interesting information
> like that.
That would be good -- I suspect that the number of people who understand
the purpose of the ids is rather smaller than the number of people who
just want wireless of some description (though the numeric stuff needs
to be somewhere).
> However, as far as AP is concerned, how about we just add a little help
> text that explains that you should look on the Drivers page to see
> whether it supports what you need, and then select by driver? We could
> make the driver table better to allow filtering.
That would be a help. Mind you, I'm now a satisfied customer hoping he
won't have to look for AP information for a while...
--
Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
^ permalink raw reply
* Re: wireless-testing regression: iwl3945 scan fails
From: Kalle Valo @ 2009-07-25 5:55 UTC (permalink / raw)
To: reinette chatre; +Cc: linux-wireless@vger.kernel.org, Johannes Berg
In-Reply-To: <874ot2sa51.fsf@litku.valot.fi>
Kalle Valo <kalle.valo@iki.fi> writes:
> reinette chatre <reinette.chatre@intel.com> writes:
>
>> Are you saying that this problem occurs always with wpa_supplicant and
>> sometimes with iw?
>
> I did some more testing and I can now reproduce this with iw as well. I
> just need to reboot my laptop to reproduce it. I'll debug this more on a
> rainy day.
This is getting very odd, I cannot reproduce the problem anymore with
rc4-wl. Just to be safe, I rebooted back to rc3-wl and I was immediately
able to reproduce it. To summarise, rc2-wl and rc4-wl were ok and only
rc3-wl is broken. So something fixed this, I just don't know what.
--
Kalle Valo
^ 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