* REGRESSION: v3.2-rcX: iwlagn refuses to associate with my AP's @ 2011-12-12 19:42 Theodore Ts'o 2011-12-13 17:26 ` Ted Ts'o 2011-12-13 18:22 ` Johannes Berg 0 siblings, 2 replies; 11+ messages in thread From: Theodore Ts'o @ 2011-12-12 19:42 UTC (permalink / raw) To: linux-kernel; +Cc: ilw, linux-wireless Hi there, I recently discovered a regression in the iwlagn driver (works in v3.1 but not in v3.2-rc2... I'm going to continue to bisect, but I thought I'd give a heads up now). I'm using a Lenovo T410, with the following wireless card: [ 11.197410] iwlwifi 0000:03:00.0: HW Revision ID = 0x35 [ 11.197637] iwlwifi 0000:03:00.0: Detected Intel(R) Centrino(R) Advanced-N + WiMAX 6250 AGN, REV=0x84 This doesn't appear to be the same regression as the one reported in the thread "iwlagn regression in v3.1.5", since the commit which Andrej pointed at (and which fixed his problem when he reverted it, "iwlwifi: do not re-configure HT40 after associated") does not appear in v3.2-rc2. The failure to associate with access points happens at work, with whatever AP's are in use at the Cambridge Google office. When I tried v3.2-rc5 at home, I was able to associate with a consumer-grade NetGear AP, although it was flaky --- that is, it completely failed to associate initially, but then I tried rebooting and I was eventually able to get it to work. At work, I was able to reproduce the problem with a v3.2-rc5 and v3.2-rc2 kernel, but the problem did not manifest itself with a v3.1 kernel. One interesting thing is that I'm getting the following WARNING message triggering in my dmesg logs: [ 48.518246] wlan0: deauthenticating from 00:1a:1e:26:2b:30 by local choice (r eason=3) [ 48.525625] ------------[ cut here ]------------ [ 48.525653] WARNING: at net/wireless/mlme.c:309 __cfg80211_auth_remove+0xc2/0xcf [cfg80211]() [ 48.525656] Hardware name: 2516CTO [ 48.525658] Modules linked in: ecryptfs encrypted_keys trusted binfmt_misc rfcomm ppdev bridge stp bnep snd_hda_codec_hdmi ip6t_LOG nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT ipt_LOG nvidia(P) ipt_ULOG xt_limit xt_tcpudp btusb xt_addrtype bluetooth xt_owner uvcvideo xt_conntrack videodev v4l2_compat_ioctl32 ip6table_filter ip6_tables xt_state xt_helper nf_nat_tftp nf_conntrack_tftp nf_nat_irc iwlwifi nf_conntrack_irc nf_nat_ftp nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack_ftp snd_hda_codec_conexant mac80211 intel_ips nf_conntrack iptable_filter ip_tables x_tables cfg80211 sdhci_pci snd_hda_intel snd_hda_codec snd_hwdep thinkpad_acpi nvram tpm_tis tpm tpm_bios lp parport mxm_wmi intel_agp ehci_hcd intel_gtt [ 48.525782] Pid: 69, comm: kworker/u:5 Tainted: P O 3.2.0-rc5 #14 [ 48.525786] Call Trace: [ 48.525798] [<ffffffff8105bf6e>] warn_slowpath_common+0x85/0x9d [ 48.525804] [<ffffffff8105bfa0>] warn_slowpath_null+0x1a/0x1c [ 48.525816] [<ffffffffa00b29db>] __cfg80211_auth_remove+0xc2/0xcf [cfg80211] [ 48.525828] [<ffffffffa00b3290>] cfg80211_send_auth_timeout+0x98/0xaf [cfg80211] [ 48.525845] [<ffffffffa0106cdb>] ieee80211_probe_auth_done+0x39/0xcb [mac80211] [ 48.525858] [<ffffffffa01096f2>] ieee80211_work_work+0x1003/0x1074 [mac80211] [ 48.525864] [<ffffffff8108ac9d>] ? print_lock_contention_bug+0x1b/0xee [ 48.525877] [<ffffffffa01086ef>] ? free_work+0x19/0x19 [mac80211] [ 48.525884] [<ffffffff81074989>] process_one_work+0x230/0x398 [ 48.525889] [<ffffffff810748fa>] ? process_one_work+0x1a1/0x398 [ 48.525897] [<ffffffff81074c2c>] worker_thread+0x13b/0x25a [ 48.525902] [<ffffffff81074af1>] ? process_one_work+0x398/0x398 [ 48.525909] [<ffffffff810789f7>] kthread+0xa0/0xa8 [ 48.525915] [<ffffffff8108b66f>] ? trace_hardirqs_on_caller+0x123/0x15a [ 48.525923] [<ffffffff815173c4>] kernel_thread_helper+0x4/0x10 [ 48.525930] [<ffffffff8150f274>] ? retint_restore_args+0x13/0x13 [ 48.525936] [<ffffffff81078957>] ? __init_kthread_worker+0x5b/0x5b [ 48.525941] [<ffffffff815173c0>] ? gs_change+0x13/0x13 [ 48.525945] ---[ end trace d5c80202b94eccb9 ]--- [ 64.008073] wlan0: deauthenticating from 00:1a:1e:26:2c:90 by local choice (reason=3) [ 64.014596] ------------[ cut here ]------------ This seems to be happening after the failure to associate with the AP, so it could be a red herring. - Ted ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: REGRESSION: v3.2-rcX: iwlagn refuses to associate with my AP's 2011-12-12 19:42 REGRESSION: v3.2-rcX: iwlagn refuses to associate with my AP's Theodore Ts'o @ 2011-12-13 17:26 ` Ted Ts'o 2011-12-13 17:54 ` [Ilw] " wwguy 2011-12-13 18:22 ` Johannes Berg 1 sibling, 1 reply; 11+ messages in thread From: Ted Ts'o @ 2011-12-13 17:26 UTC (permalink / raw) To: linux-kernel; +Cc: ilw, linux-wireless, Johannes Berg On Mon, Dec 12, 2011 at 02:42:53PM -0500, Theodore Ts'o wrote: > Hi there, > > I recently discovered a regression in the iwlagn driver (works in v3.1 > but not in v3.2-rc2... I'm going to continue to bisect, but I thought > I'd give a heads up now). I'm using a Lenovo T410, with the following > wireless card: > > [ 11.197410] iwlwifi 0000:03:00.0: HW Revision ID = 0x35 > [ 11.197637] iwlwifi 0000:03:00.0: Detected Intel(R) Centrino(R) Advanced-N + WiMAX 6250 AGN, REV=0x84 > > The failure to associate with access points happens at work, with > whatever AP's are in use at the Cambridge Google office. When I tried > v3.2-rc5 at home, I was able to associate with a consumer-grade NetGear > AP, although it was flaky --- that is, it completely failed to associate > initially, but then I tried rebooting and I was eventually able to get > it to work. At work, I was able to reproduce the problem with a > v3.2-rc5 and v3.2-rc2 kernel, but the problem did not manifest itself > with a v3.1 kernel. OK, a follow up. A bisection puts the finger of blame very firmly at: debcf73 iwlagn: handle GO powersave Specifically, I can't associate with *any* access points (encrypted or not) if I compile a kernel at commit debcf73, but if I compile a kernel with its parent (commit 8ad71be), it works fine. However, as a puzzler, when I tried reverted compiling 3.2-rc5 with debcf73 reverted, it did not make the problem go away. So there's something more going on here. I could try doing a bisect with reverts of debcf73 at each step, trying to find the problem, but I'm hoping this is enough of a hint that someone can tell me either that this is fixed already in the linux-wireless tree, or that they know what's wrong and can provide a test patch... Thanks, - Ted ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Ilw] Re: REGRESSION: v3.2-rcX: iwlagn refuses to associate with my AP's 2011-12-13 17:26 ` Ted Ts'o @ 2011-12-13 17:54 ` wwguy 2011-12-13 18:06 ` Johannes Berg 0 siblings, 1 reply; 11+ messages in thread From: wwguy @ 2011-12-13 17:54 UTC (permalink / raw) To: Ted Ts'o Cc: linux-kernel@vger.kernel.org, ilw@linux.intel.com, linux-wireless@vger.kernel.org [-- Attachment #1: Type: text/plain, Size: 2619 bytes --] Hi Ted, On Tue, 2011-12-13 at 09:26 -0800, Ted Ts'o wrote: > On Mon, Dec 12, 2011 at 02:42:53PM -0500, Theodore Ts'o wrote: > > Hi there, > > > > I recently discovered a regression in the iwlagn driver (works in v3.1 > > but not in v3.2-rc2... I'm going to continue to bisect, but I thought > > I'd give a heads up now). I'm using a Lenovo T410, with the following > > wireless card: > > > > [ 11.197410] iwlwifi 0000:03:00.0: HW Revision ID = 0x35 > > [ 11.197637] iwlwifi 0000:03:00.0: Detected Intel(R) Centrino(R) Advanced-N + WiMAX 6250 AGN, REV=0x84 > > > > The failure to associate with access points happens at work, with > > whatever AP's are in use at the Cambridge Google office. When I tried > > v3.2-rc5 at home, I was able to associate with a consumer-grade NetGear > > AP, although it was flaky --- that is, it completely failed to associate > > initially, but then I tried rebooting and I was eventually able to get > > it to work. At work, I was able to reproduce the problem with a > > v3.2-rc5 and v3.2-rc2 kernel, but the problem did not manifest itself > > with a v3.1 kernel. > > OK, a follow up. A bisection puts the finger of blame very firmly at: > > debcf73 iwlagn: handle GO powersave > > Specifically, I can't associate with *any* access points (encrypted or > not) if I compile a kernel at commit debcf73, but if I compile a > kernel with its parent (commit 8ad71be), it works fine. > > However, as a puzzler, when I tried reverted compiling 3.2-rc5 with > debcf73 reverted, it did not make the problem go away. So there's > something debcf73more going on here. I could try doing a bisect with reverts > of debcf73 at each step, trying to find the problem, but I'm hoping > this is enough of a hint that someone can tell me either that this is > fixed already in the linux-wireless tree, or that they know what's > wrong and can provide a test patch... > Thank you for doing all those works, The "debcf73 iwlagn: handle GO powersave" is part of new WiFi Direct feature we are introducing for our up-coming new products. As you can see, the feature still under development and for sure there are a lot issues we need to flush out and make it perfect. Here I attach a patch which will disable P2P feature by default, could you please give it a try, so we know for sure it is something being introduced by P2P changes. Of cause, we still need to understand why it is happening and find the correct solution for it. Thanks Wey > > _______________________________________________ > ilw mailing list > ilw@linux.intel.com > http://linux.intel.com/mailman/listinfo/ilw [-- Attachment #2: 0001-iwlwifi-P2P-is-not-enabled-by-default.patch --] [-- Type: text/x-patch, Size: 3040 bytes --] >From 788e8d4221b118c1818eb501858323c7f10b5bff Mon Sep 17 00:00:00 2001 From: Wey-Yi Guy <wey-yi.w.guy@intel.com> Date: Fri, 2 Dec 2011 07:32:08 -0800 Subject: [PATCH v2 1/1] iwlwifi: P2P is not enabled by default P2P still under development. it will not enabled by default, but user always can enable it manually for testing. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> --- v2: only disable p2p but not newscan, need testing --- drivers/net/wireless/iwlwifi/Kconfig | 16 ++++++++++++++++ drivers/net/wireless/iwlwifi/iwl-agn.c | 10 +++++++++- 2 files changed, 25 insertions(+), 1 deletions(-) diff --git a/drivers/net/wireless/iwlwifi/Kconfig b/drivers/net/wireless/iwlwifi/Kconfig index 82c8cca..ae08498 100644 --- a/drivers/net/wireless/iwlwifi/Kconfig +++ b/drivers/net/wireless/iwlwifi/Kconfig @@ -111,3 +111,19 @@ config IWLWIFI_DEVICE_TESTMODE NL80211_TESTMODE. This provide the capabilities of enable user space validation applications to interacts with the device through the generic netlink message via NL80211_TESTMODE channel. + +config IWLWIFI_P2P + bool "iwlwifi experimental P2P support" + depends on IWLWIFI + help + This option enables experimental P2P support for some devices + based on microcode support. Since P2P support is still under + development, this option may even enable it for some devices + now that turn out to not support it in the future due to + microcode restrictions. + + To determine if your microcode supports the experimental P2P + offered by this option, check if the driver advertises AP + support when it is loaded. + + Say Y only if you want to experiment with P2P. diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c index 8ca6ad3..368c28e 100644 --- a/drivers/net/wireless/iwlwifi/iwl-agn.c +++ b/drivers/net/wireless/iwlwifi/iwl-agn.c @@ -1036,6 +1036,9 @@ static void iwl_ucode_callback(const struct firmware *ucode_raw, void *context) priv->inst_evtlog_size = priv->cfg->base_params->max_event_log_size; priv->inst_errlog_ptr = pieces.inst_errlog_ptr; +#ifndef CONFIG_IWLWIFI_P2P + ucode_capa.flags &= ~IWL_UCODE_TLV_FLAGS_PAN; +#endif priv->new_scan_threshold_behaviour = !!(ucode_capa.flags & IWL_UCODE_TLV_FLAGS_NEWSCAN); @@ -1057,7 +1060,6 @@ static void iwl_ucode_callback(const struct firmware *ucode_raw, void *context) priv->sta_key_max_num = STA_KEY_MAX_NUM; priv->shrd->cmd_queue = IWL_DEFAULT_CMD_QUEUE_NUM; } - /* * figure out the offset of chain noise reset and gain commands * base on the size of standard phy calibration commands table size @@ -1707,6 +1709,12 @@ static void iwl_debug_config(struct iwl_priv *priv) #else "disabled\n"); #endif + dev_printk(KERN_INFO, bus(priv)->dev, "CONFIG_IWLWIFI_P2P " +#ifdef CONFIG_IWLWIFI_P2P + "enabled\n"); +#else + "disabled\n"); +#endif } int iwl_probe(struct iwl_bus *bus, const struct iwl_trans_ops *trans_ops, -- 1.7.0.4 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [Ilw] Re: REGRESSION: v3.2-rcX: iwlagn refuses to associate with my AP's 2011-12-13 17:54 ` [Ilw] " wwguy @ 2011-12-13 18:06 ` Johannes Berg 0 siblings, 0 replies; 11+ messages in thread From: Johannes Berg @ 2011-12-13 18:06 UTC (permalink / raw) To: wwguy Cc: Ted Ts'o, linux-kernel@vger.kernel.org, ilw@linux.intel.com, linux-wireless@vger.kernel.org On Tue, 2011-12-13 at 09:54 -0800, wwguy wrote: > Thank you for doing all those works, > > The "debcf73 iwlagn: handle GO powersave" is part of new WiFi Direct > feature we are introducing for our up-coming new products. As you can > see, the feature still under development and for sure there are a lot > issues we need to flush out and make it perfect. > > Here I attach a patch which will disable P2P feature by default, could > you please give it a try, so we know for sure it is something being > introduced by P2P changes. I don't think this will make a difference since tx_sync is still done. johannes ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: REGRESSION: v3.2-rcX: iwlagn refuses to associate with my AP's 2011-12-12 19:42 REGRESSION: v3.2-rcX: iwlagn refuses to associate with my AP's Theodore Ts'o 2011-12-13 17:26 ` Ted Ts'o @ 2011-12-13 18:22 ` Johannes Berg 2011-12-13 20:17 ` Ted Ts'o 1 sibling, 1 reply; 11+ messages in thread From: Johannes Berg @ 2011-12-13 18:22 UTC (permalink / raw) To: Theodore Ts'o; +Cc: linux-kernel, ilw, linux-wireless Hi Ted, > The failure to associate with access points happens at work, with > whatever AP's are in use at the Cambridge Google office. When I tried > v3.2-rc5 at home, I was able to associate with a consumer-grade NetGear > AP, although it was flaky --- that is, it completely failed to associate > initially, but then I tried rebooting and I was eventually able to get > it to work. At work, I was able to reproduce the problem with a > v3.2-rc5 and v3.2-rc2 kernel, but the problem did not manifest itself > with a v3.1 kernel. > > One interesting thing is that I'm getting the following WARNING message > triggering in my dmesg logs: > > [ 48.518246] wlan0: deauthenticating from 00:1a:1e:26:2b:30 by local choice (r > eason=3) > [ 48.525625] ------------[ cut here ]------------ > [ 48.525653] WARNING: at net/wireless/mlme.c:309 __cfg80211_auth_remove+0xc2/0xcf [cfg80211]() > This seems to be happening after the failure to associate with the AP, > so it could be a red herring. I think this is. It's interesting though that it is deauthenticating -- is there anything in the log before? But since you bisected it to the TX sync commit, I'd say let's try the below patch. You might have to adjust the iwl-mac80211.c file to iwl-agn.c, I'm not entirely sure what version has the moved code. Please let me know -- this commit is probably the right thing to do until we get rid of tx_sync completely. Thanks, Johannes --- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-mac80211.c 2011-12-13 09:06:14.000000000 +0100 +++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-mac80211.c 2011-12-13 19:20:24.000000000 +0100 @@ -1014,6 +1014,9 @@ static int iwlagn_mac_tx_sync(struct iee int ret; u8 sta_id; + if (!vif->p2p) + return 0; + IWL_DEBUG_MAC80211(priv, "enter\n"); mutex_lock(&priv->shrd->mutex); @@ -1063,6 +1066,9 @@ static void iwlagn_mac_finish_tx_sync(st struct iwl_vif_priv *vif_priv = (void *)vif->drv_priv; struct iwl_rxon_context *ctx = vif_priv->ctx; + if (!vif->p2p) + return; + IWL_DEBUG_MAC80211(priv, "enter\n"); mutex_lock(&priv->shrd->mutex); ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: REGRESSION: v3.2-rcX: iwlagn refuses to associate with my AP's 2011-12-13 18:22 ` Johannes Berg @ 2011-12-13 20:17 ` Ted Ts'o 2011-12-14 1:59 ` Ted Ts'o 0 siblings, 1 reply; 11+ messages in thread From: Ted Ts'o @ 2011-12-13 20:17 UTC (permalink / raw) To: Johannes Berg; +Cc: linux-kernel, ilw, linux-wireless On Tue, Dec 13, 2011 at 07:22:37PM +0100, Johannes Berg wrote: > > I think this is. It's interesting though that it is deauthenticating -- > is there anything in the log before? But since you bisected it to the TX > sync commit, I'd say let's try the below patch. You might have to adjust > the iwl-mac80211.c file to iwl-agn.c, I'm not entirely sure what version > has the moved code. > > Please let me know -- this commit is probably the right thing to do > until we get rid of tx_sync completely. Well, this patch seems to fix things for the non-authenticated case. I can now associate with the GoogleGuest SSID without any problems. I'm still having problems associating with the EAP-TLS encrypted network, but that looks like it's a different bug. (And that may explain why I had so much trouble bisecting this; there are two issues that have very similar symptoms.) I did have to slightly modify your patch since at least as of 3.2-rc5, the functions involved were in a different file (iwl-agn.c). I tried Wey's patch, but it didn't seem to result in any change in behavior, as you had suggested. OK, now to see if I can figure out what's going on with the EAP-TLS authentication case.... - Ted >From c1160e3b5dfadc8ac26f5a7ff0ff6ce1e8e7dbae Mon Sep 17 00:00:00 2001 From: Theodore Ts'o <tytso@google.com> Date: Tue, 13 Dec 2011 14:58:50 -0500 Subject: [PATCH] iwlwifi: disable tx_sync if p2p is not enabled Test patch sent to LKML from by Johnnes Berg Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> --- drivers/net/wireless/iwlwifi/iwl-agn.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c index bacc06c..78ce547 100644 --- a/drivers/net/wireless/iwlwifi/iwl-agn.c +++ b/drivers/net/wireless/iwlwifi/iwl-agn.c @@ -2850,6 +2850,9 @@ static int iwlagn_mac_tx_sync(struct ieee80211_hw *hw, int ret; u8 sta_id; + if (!vif->p2p) + return 0; + IWL_DEBUG_MAC80211(priv, "enter\n"); mutex_lock(&priv->shrd->mutex); @@ -2898,6 +2901,9 @@ static void iwlagn_mac_finish_tx_sync(struct ieee80211_hw *hw, struct iwl_vif_priv *vif_priv = (void *)vif->drv_priv; struct iwl_rxon_context *ctx = vif_priv->ctx; + if (!vif->p2p) + return; + IWL_DEBUG_MAC80211(priv, "enter\n"); mutex_lock(&priv->shrd->mutex); -- 1.7.3.1 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: REGRESSION: v3.2-rcX: iwlagn refuses to associate with my AP's 2011-12-13 20:17 ` Ted Ts'o @ 2011-12-14 1:59 ` Ted Ts'o 2011-12-14 3:14 ` Guy, Wey-Yi 2011-12-21 21:12 ` Ted Ts'o 0 siblings, 2 replies; 11+ messages in thread From: Ted Ts'o @ 2011-12-14 1:59 UTC (permalink / raw) To: Johannes Berg, linux-kernel, ilw, linux-wireless On Tue, Dec 13, 2011 at 03:17:52PM -0500, Ted Ts'o wrote: > Well, this patch seems to fix things for the non-authenticated case. > I can now associate with the GoogleGuest SSID without any problems. > I'm still having problems associating with the EAP-TLS encrypted > network, but that looks like it's a different bug. (And that may > explain why I had so much trouble bisecting this; there are two issues > that have very similar symptoms.) ... and the second problem I had with associating with EAP-TLS encrypted SSID's was solved by Wey-Yi's patch: iwlwifi: allow to switch to HT40 if not associated yet ... found in the thread "iwlagn regression in v3.1.5" So with these two patches applied, things are now stable for me. One thing: out of curiosity, I assume there is a pretty good testing infrastructure at Intel --- how was it that this didn't caught earlier? Is it because different access points do things a little different? Would it be useful if I can find out the model of access point that we're using, so you could hopefully augment your library of test hardware? I'm asking out of purely selfish reasons, of course, since this took me the better part of a day to bisect each of these problems. - Ted ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: REGRESSION: v3.2-rcX: iwlagn refuses to associate with my AP's 2011-12-14 1:59 ` Ted Ts'o @ 2011-12-14 3:14 ` Guy, Wey-Yi 2011-12-21 21:12 ` Ted Ts'o 1 sibling, 0 replies; 11+ messages in thread From: Guy, Wey-Yi @ 2011-12-14 3:14 UTC (permalink / raw) To: Ted Ts'o Cc: Johannes Berg, linux-kernel@vger.kernel.org, ilw@linux.intel.com, linux-wireless@vger.kernel.org Hi Ted, On Tue, 2011-12-13 at 17:59 -0800, Ted Ts'o wrote: > On Tue, Dec 13, 2011 at 03:17:52PM -0500, Ted Ts'o wrote: > > Well, this patch seems to fix things for the non-authenticated case. > > I can now associate with the GoogleGuest SSID without any problems. > > I'm still having problems associating with the EAP-TLS encrypted > > network, but that looks like it's a different bug. (And that may > > explain why I had so much trouble bisecting this; there are two issues > > that have very similar symptoms.) > > ... and the second problem I had with associating with EAP-TLS > encrypted SSID's was solved by Wey-Yi's patch: > > iwlwifi: allow to switch to HT40 if not associated yet > > ... found in the thread "iwlagn regression in v3.1.5" > > So with these two patches applied, things are now stable for me. > > One thing: out of curiosity, I assume there is a pretty good testing > infrastructure at Intel --- how was it that this didn't caught > earlier? Is it because different access points do things a little > different? Would it be useful if I can find out the model of access > point that we're using, so you could hopefully augment your library of > test hardware? I'm asking out of purely selfish reasons, of course, > since this took me the better part of a day to bisect each of these > problems. You ask a very valid and good question, you are correct, we at Intel have a very good lab and great testing infrastructure. But at the same time, there are so many APs available on the market and each one could behave differently, also just like station, AP's software continue change and improve, and at the same time, bugs can be introduced. We try to do our best, but we can not cover everything and we truly hope the community can help us flush the corner cases and bugs we miss. Yes, if you can let us know your configuration and the AP information, it will be very helpful. But please do help us continue test our latest driver, so we can improve our driver quality and better serve the community. Thanks Wey ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: REGRESSION: v3.2-rcX: iwlagn refuses to associate with my AP's 2011-12-14 1:59 ` Ted Ts'o 2011-12-14 3:14 ` Guy, Wey-Yi @ 2011-12-21 21:12 ` Ted Ts'o 2011-12-21 21:16 ` David Miller 1 sibling, 1 reply; 11+ messages in thread From: Ted Ts'o @ 2011-12-21 21:12 UTC (permalink / raw) To: Johannes Berg, linux-kernel, ilw, linux-wireless On Tue, Dec 13, 2011 at 08:59:59PM -0500, Ted Ts'o wrote: > On Tue, Dec 13, 2011 at 03:17:52PM -0500, Ted Ts'o wrote: > > Well, this patch seems to fix things for the non-authenticated case. > > I can now associate with the GoogleGuest SSID without any problems. > > I'm still having problems associating with the EAP-TLS encrypted > > network, but that looks like it's a different bug. (And that may > > explain why I had so much trouble bisecting this; there are two issues > > that have very similar symptoms.) > > ... and the second problem I had with associating with EAP-TLS > encrypted SSID's was solved by Wey-Yi's patch: > > iwlwifi: allow to switch to HT40 if not associated yet > > ... found in the thread "iwlagn regression in v3.1.5" > > So with these two patches applied, things are now stable for me. It seems that fixes for these two issues haven't been pushed to Linus yet? It would be nice if they could get pushed to mainline before 3.2 ships, as opposed to being something that has to get fixed in the 3.2.X series.... - Ted ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: REGRESSION: v3.2-rcX: iwlagn refuses to associate with my AP's 2011-12-21 21:12 ` Ted Ts'o @ 2011-12-21 21:16 ` David Miller 2011-12-21 23:18 ` Ted Ts'o 0 siblings, 1 reply; 11+ messages in thread From: David Miller @ 2011-12-21 21:16 UTC (permalink / raw) To: tytso; +Cc: johannes, linux-kernel, ilw, linux-wireless From: "Ted Ts'o" <tytso@mit.edu> Date: Wed, 21 Dec 2011 16:12:13 -0500 > On Tue, Dec 13, 2011 at 08:59:59PM -0500, Ted Ts'o wrote: >> On Tue, Dec 13, 2011 at 03:17:52PM -0500, Ted Ts'o wrote: >> ... and the second problem I had with associating with EAP-TLS >> encrypted SSID's was solved by Wey-Yi's patch: >> >> iwlwifi: allow to switch to HT40 if not associated yet >> >> ... found in the thread "iwlagn regression in v3.1.5" >> >> So with these two patches applied, things are now stable for me. > > It seems that fixes for these two issues haven't been pushed to Linus > yet? It would be nice if they could get pushed to mainline before 3.2 > ships, as opposed to being something that has to get fixed in the > 3.2.X series.... It's in my queue to send to Linus. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: REGRESSION: v3.2-rcX: iwlagn refuses to associate with my AP's 2011-12-21 21:16 ` David Miller @ 2011-12-21 23:18 ` Ted Ts'o 0 siblings, 0 replies; 11+ messages in thread From: Ted Ts'o @ 2011-12-21 23:18 UTC (permalink / raw) To: David Miller; +Cc: johannes, linux-kernel, ilw, linux-wireless On Wed, Dec 21, 2011 at 04:16:07PM -0500, David Miller wrote: > > It seems that fixes for these two issues haven't been pushed to Linus > > yet? It would be nice if they could get pushed to mainline before 3.2 > > ships, as opposed to being something that has to get fixed in the > > 3.2.X series.... > > It's in my queue to send to Linus. Great, thanks!! - Ted ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2011-12-21 23:18 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-12-12 19:42 REGRESSION: v3.2-rcX: iwlagn refuses to associate with my AP's Theodore Ts'o 2011-12-13 17:26 ` Ted Ts'o 2011-12-13 17:54 ` [Ilw] " wwguy 2011-12-13 18:06 ` Johannes Berg 2011-12-13 18:22 ` Johannes Berg 2011-12-13 20:17 ` Ted Ts'o 2011-12-14 1:59 ` Ted Ts'o 2011-12-14 3:14 ` Guy, Wey-Yi 2011-12-21 21:12 ` Ted Ts'o 2011-12-21 21:16 ` David Miller 2011-12-21 23:18 ` Ted Ts'o
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).