[PATCH] mac80211: disassociate when switching bands and not scanning

[PATCH] mac80211: disassociate when switching bands and not scanning

[Luis R. Rodriguez]

If we're associated to an AP and we manually decide to switch
bands we have no guarantee we can communicate with that AP
on the new band and our current bss parameters may change
completely so disassociate.

This fixes this warning (which is not specific to iwlwifi!):

[25612.559460] ------------[ cut here ]------------
[25612.559500] WARNING: at include/net/mac80211.h:2127 rate_control_send_low+0xcf/0xe0 [mac80211]()
[25612.559508] Hardware name: VGN-N170G
[25612.559513] Modules linked in: ath9k ath mac80211 cfg80211 <bleh line cut>
[25612.559807] Pid: 14492, comm: iwconfig Not tainted 2.6.30-rc8-wl #11
[25612.559814] Call Trace:
[25612.559829]  [<c03b2cd9>] ? printk+0x18/0x1f
[25612.559865]  [<f831072f>] ? rate_control_send_low+0xcf/0xe0 [mac80211]
[25612.559878]  [<c0134f4c>] warn_slowpath_common+0x6c/0xc0
[25612.559912]  [<f831072f>] ? rate_control_send_low+0xcf/0xe0 [mac80211]
[25612.559923]  [<c0134fb5>] warn_slowpath_null+0x15/0x20
[25612.559957]  [<f831072f>] rate_control_send_low+0xcf/0xe0 [mac80211]
[25612.559985]  [<f84129c3>] ath_get_rate+0x33/0x520 [ath9k]
[25612.559998]  [<c015cb73>] ? mark_held_locks+0x63/0x80
[25612.560064]  [<f831057d>] rate_control_get_rate+0xbd/0xd0 [mac80211]
[25612.560102]  [<f8318b6f>] invoke_tx_handlers+0x5df/0xfa0 [mac80211]
[25612.560115]  [<c015cb73>] ? mark_held_locks+0x63/0x80
[25612.560152]  [<f8317854>] ? __ieee80211_tx_prepare+0x194/0x3b0 [mac80211]
[25612.560190]  [<f8319796>] ieee80211_tx+0xd6/0x280 [mac80211]
[25612.560227]  [<f831972f>] ? ieee80211_tx+0x6f/0x280 [mac80211]
[25612.560265]  [<f8319e39>] ieee80211_master_start_xmit+0x1f9/0x400 [mac80211]
[25612.560280]  [<c032347b>] dev_hard_start_xmit+0x2ab/0x340
[25612.560292]  [<c0323230>] ? dev_hard_start_xmit+0x60/0x340
[25612.560304]  [<c0335675>] __qdisc_run+0x1e5/0x240
[25612.560316]  [<c03245d7>] dev_queue_xmit+0x377/0x4e0
[25612.560328]  [<c0324298>] ? dev_queue_xmit+0x38/0x4e0
[25612.560365]  [<f831c1d2>] ieee80211_tx_skb+0x52/0x60 [mac80211]
[25612.560400]  [<f83079d0>] ieee80211_send_delba+0xf0/0x150 [mac80211]
[25612.560413]  [<c013f931>] ? del_timer_sync+0x81/0xb0
[25612.560447]  [<f830903a>] __ieee80211_stop_rx_ba_session+0xea/0x1d0 [mac80211]
[25612.560476]  [<f8409310>] ? ath9k_ampdu_action+0x0/0x130 [ath9k]
[25612.560511]  [<f8307a63>] ieee80211_sta_tear_down_BA_sessions+0x33/0x40 [mac80211]
[25612.560548]  [<f830afd8>] ieee80211_set_disassoc+0xc8/0x370 [mac80211]
[25612.560583]  [<f830af10>] ? ieee80211_set_disassoc+0x0/0x370 [mac80211]
[25612.560597]  [<c01ace6b>] ? might_fault+0x4b/0xa0
[25612.560632]  [<f830b580>] ieee80211_sta_req_auth+0xa0/0xc0 [mac80211]
[25612.560665]  [<f8303fde>] ieee80211_ioctl_siwessid+0xbe/0xd0 [mac80211]
[25612.560679]  [<c02749c5>] ? copy_from_user+0x35/0x130
[25612.560694]  [<c039d819>] ioctl_standard_call+0x199/0x3a0
[25612.560707]  [<c032358d>] ? __dev_get_by_name+0x7d/0xa0
[25612.560720]  [<c039d31f>] wext_handle_ioctl+0x14f/0x230
[25612.560753]  [<f8303f20>] ? ieee80211_ioctl_siwessid+0x0/0xd0 [mac80211]
[25612.560766]  [<c0324114>] dev_ioctl+0x474/0x540
[25612.560780]  [<c019f685>] ? __pagevec_free+0x25/0x30
[25612.560794]  [<c0312350>] ? sock_ioctl+0x0/0x270
[25612.560806]  [<c0312445>] sock_ioctl+0xf5/0x270
[25612.560817]  [<c0312350>] ? sock_ioctl+0x0/0x270
[25612.560831]  [<c01d9018>] vfs_ioctl+0x28/0x90
[25612.560843]  [<c01d90f2>] do_vfs_ioctl+0x72/0x590
[25612.560856]  [<c015ce8b>] ? trace_hardirqs_on+0xb/0x10
[25612.560868]  [<c01b2a16>] ? remove_vma+0x56/0x70
[25612.560879]  [<c01b2a16>] ? remove_vma+0x56/0x70
[25612.560890]  [<c01b38f7>] ? do_munmap+0x237/0x290
[25612.560902]  [<c0103021>] ? sysenter_exit+0xf/0x1a
[25612.560914]  [<c01d9673>] sys_ioctl+0x63/0x70
[25612.560925]  [<c0102fec>] sysenter_do_call+0x12/0x38
[25612.560934] ---[ end trace 05e1ecc810d6b568 ]---
[25612.561114] ------------[ cut here ]------------

Cc: Reinette Chatre <reinette.chatre@intel.com>
Cc: Zhu Yi <yi.zhu@intel.com>
Cc: Mohamed Abbas <mohamed.abbas@intel.com>
Cc: ipw3945-devel@lists.sourceforge.net
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 net/mac80211/util.c |   17 ++++++++++++++++-
 1 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 66ce96a..8e66556 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -791,9 +791,24 @@ int ieee80211_set_freq(struct ieee80211_sub_if_data *sdata, int freqMHz)
 
 		if (local->sw_scanning || local->hw_scanning)
 			ret = 0;
-		else
+		else {
+			struct ieee80211_channel *cur_chan;
+
+			cur_chan = local->hw.conf.channel;
+
+			/*
+			 * If we're switching bands and not scanning we
+			 * could potentially be moving to a band our AP
+			 * does not understand so give up on it
+			 */
+			if (sdata->vif.type == NL80211_IFTYPE_STATION &&
+			    (sdata->u.mgd.flags & IEEE80211_STA_ASSOCIATED) &&
+			    cur_chan->band != chan->band)
+				ieee80211_sta_deauthenticate(sdata,
+					WLAN_REASON_DEAUTH_LEAVING);
 			ret = ieee80211_hw_config(
 				local, IEEE80211_CONF_CHANGE_CHANNEL);
+		}
 	}
 
 	return ret;
-- 
1.5.6.3

[ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[Luis R. Rodriguez]

If we're associated to an AP and we manually decide to switch
bands we have no guarantee we can communicate with that AP
on the new band and our current bss parameters may change
completely so disassociate.

This fixes this warning (which is not specific to iwlwifi!):

[25612.559460] ------------[ cut here ]------------
[25612.559500] WARNING: at include/net/mac80211.h:2127 rate_control_send_low+0xcf/0xe0 [mac80211]()
[25612.559508] Hardware name: VGN-N170G
[25612.559513] Modules linked in: ath9k ath mac80211 cfg80211 <bleh line cut>
[25612.559807] Pid: 14492, comm: iwconfig Not tainted 2.6.30-rc8-wl #11
[25612.559814] Call Trace:
[25612.559829]  [<c03b2cd9>] ? printk+0x18/0x1f
[25612.559865]  [<f831072f>] ? rate_control_send_low+0xcf/0xe0 [mac80211]
[25612.559878]  [<c0134f4c>] warn_slowpath_common+0x6c/0xc0
[25612.559912]  [<f831072f>] ? rate_control_send_low+0xcf/0xe0 [mac80211]
[25612.559923]  [<c0134fb5>] warn_slowpath_null+0x15/0x20
[25612.559957]  [<f831072f>] rate_control_send_low+0xcf/0xe0 [mac80211]
[25612.559985]  [<f84129c3>] ath_get_rate+0x33/0x520 [ath9k]
[25612.559998]  [<c015cb73>] ? mark_held_locks+0x63/0x80
[25612.560064]  [<f831057d>] rate_control_get_rate+0xbd/0xd0 [mac80211]
[25612.560102]  [<f8318b6f>] invoke_tx_handlers+0x5df/0xfa0 [mac80211]
[25612.560115]  [<c015cb73>] ? mark_held_locks+0x63/0x80
[25612.560152]  [<f8317854>] ? __ieee80211_tx_prepare+0x194/0x3b0 [mac80211]
[25612.560190]  [<f8319796>] ieee80211_tx+0xd6/0x280 [mac80211]
[25612.560227]  [<f831972f>] ? ieee80211_tx+0x6f/0x280 [mac80211]
[25612.560265]  [<f8319e39>] ieee80211_master_start_xmit+0x1f9/0x400 [mac80211]
[25612.560280]  [<c032347b>] dev_hard_start_xmit+0x2ab/0x340
[25612.560292]  [<c0323230>] ? dev_hard_start_xmit+0x60/0x340
[25612.560304]  [<c0335675>] __qdisc_run+0x1e5/0x240
[25612.560316]  [<c03245d7>] dev_queue_xmit+0x377/0x4e0
[25612.560328]  [<c0324298>] ? dev_queue_xmit+0x38/0x4e0
[25612.560365]  [<f831c1d2>] ieee80211_tx_skb+0x52/0x60 [mac80211]
[25612.560400]  [<f83079d0>] ieee80211_send_delba+0xf0/0x150 [mac80211]
[25612.560413]  [<c013f931>] ? del_timer_sync+0x81/0xb0
[25612.560447]  [<f830903a>] __ieee80211_stop_rx_ba_session+0xea/0x1d0 [mac80211]
[25612.560476]  [<f8409310>] ? ath9k_ampdu_action+0x0/0x130 [ath9k]
[25612.560511]  [<f8307a63>] ieee80211_sta_tear_down_BA_sessions+0x33/0x40 [mac80211]
[25612.560548]  [<f830afd8>] ieee80211_set_disassoc+0xc8/0x370 [mac80211]
[25612.560583]  [<f830af10>] ? ieee80211_set_disassoc+0x0/0x370 [mac80211]
[25612.560597]  [<c01ace6b>] ? might_fault+0x4b/0xa0
[25612.560632]  [<f830b580>] ieee80211_sta_req_auth+0xa0/0xc0 [mac80211]
[25612.560665]  [<f8303fde>] ieee80211_ioctl_siwessid+0xbe/0xd0 [mac80211]
[25612.560679]  [<c02749c5>] ? copy_from_user+0x35/0x130
[25612.560694]  [<c039d819>] ioctl_standard_call+0x199/0x3a0
[25612.560707]  [<c032358d>] ? __dev_get_by_name+0x7d/0xa0
[25612.560720]  [<c039d31f>] wext_handle_ioctl+0x14f/0x230
[25612.560753]  [<f8303f20>] ? ieee80211_ioctl_siwessid+0x0/0xd0 [mac80211]
[25612.560766]  [<c0324114>] dev_ioctl+0x474/0x540
[25612.560780]  [<c019f685>] ? __pagevec_free+0x25/0x30
[25612.560794]  [<c0312350>] ? sock_ioctl+0x0/0x270
[25612.560806]  [<c0312445>] sock_ioctl+0xf5/0x270
[25612.560817]  [<c0312350>] ? sock_ioctl+0x0/0x270
[25612.560831]  [<c01d9018>] vfs_ioctl+0x28/0x90
[25612.560843]  [<c01d90f2>] do_vfs_ioctl+0x72/0x590
[25612.560856]  [<c015ce8b>] ? trace_hardirqs_on+0xb/0x10
[25612.560868]  [<c01b2a16>] ? remove_vma+0x56/0x70
[25612.560879]  [<c01b2a16>] ? remove_vma+0x56/0x70
[25612.560890]  [<c01b38f7>] ? do_munmap+0x237/0x290
[25612.560902]  [<c0103021>] ? sysenter_exit+0xf/0x1a
[25612.560914]  [<c01d9673>] sys_ioctl+0x63/0x70
[25612.560925]  [<c0102fec>] sysenter_do_call+0x12/0x38
[25612.560934] ---[ end trace 05e1ecc810d6b568 ]---
[25612.561114] ------------[ cut here ]------------

Cc: Reinette Chatre <reinette.chatre@intel.com>
Cc: Zhu Yi <yi.zhu@intel.com>
Cc: Mohamed Abbas <mohamed.abbas@intel.com>
Cc: ipw3945-devel at lists.sourceforge.net
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 net/mac80211/util.c |   17 ++++++++++++++++-
 1 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 66ce96a..8e66556 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -791,9 +791,24 @@ int ieee80211_set_freq(struct ieee80211_sub_if_data *sdata, int freqMHz)
 
 		if (local->sw_scanning || local->hw_scanning)
 			ret = 0;
-		else
+		else {
+			struct ieee80211_channel *cur_chan;
+
+			cur_chan = local->hw.conf.channel;
+
+			/*
+			 * If we're switching bands and not scanning we
+			 * could potentially be moving to a band our AP
+			 * does not understand so give up on it
+			 */
+			if (sdata->vif.type == NL80211_IFTYPE_STATION &&
+			    (sdata->u.mgd.flags & IEEE80211_STA_ASSOCIATED) &&
+			    cur_chan->band != chan->band)
+				ieee80211_sta_deauthenticate(sdata,
+					WLAN_REASON_DEAUTH_LEAVING);
 			ret = ieee80211_hw_config(
 				local, IEEE80211_CONF_CHANGE_CHANNEL);
+		}
 	}
 
 	return ret;
-- 
1.5.6.3

Re: [PATCH] mac80211: disassociate when switching bands and not scanning

[reinette chatre]

Hi Luis,

On Wed, 2009-06-10 at 13:35 -0700, Luis R. Rodriguez wrote:
> If we're associated to an AP and we manually decide to switch
> bands we have no guarantee we can communicate with that AP
> on the new band and our current bss parameters may change
> completely so disassociate.
> 
> This fixes this warning (which is not specific to iwlwifi!):
> 
> [25612.559460] ------------[ cut here ]------------
> [25612.559500] WARNING: at include/net/mac80211.h:2127 rate_control_send_low+0xcf/0xe0 [mac80211]()
> [25612.559508] Hardware name: VGN-N170G
> [25612.559513] Modules linked in: ath9k ath mac80211 cfg80211 <bleh line cut>
> [25612.559807] Pid: 14492, comm: iwconfig Not tainted 2.6.30-rc8-wl #11
> [25612.559814] Call Trace:
> [25612.559829]  [<c03b2cd9>] ? printk+0x18/0x1f
> [25612.559865]  [<f831072f>] ? rate_control_send_low+0xcf/0xe0 [mac80211]
> [25612.559878]  [<c0134f4c>] warn_slowpath_common+0x6c/0xc0
> [25612.559912]  [<f831072f>] ? rate_control_send_low+0xcf/0xe0 [mac80211]
> [25612.559923]  [<c0134fb5>] warn_slowpath_null+0x15/0x20
> [25612.559957]  [<f831072f>] rate_control_send_low+0xcf/0xe0 [mac80211]
> [25612.559985]  [<f84129c3>] ath_get_rate+0x33/0x520 [ath9k]
> [25612.559998]  [<c015cb73>] ? mark_held_locks+0x63/0x80
> [25612.560064]  [<f831057d>] rate_control_get_rate+0xbd/0xd0 [mac80211]
> [25612.560102]  [<f8318b6f>] invoke_tx_handlers+0x5df/0xfa0 [mac80211]
> [25612.560115]  [<c015cb73>] ? mark_held_locks+0x63/0x80
> [25612.560152]  [<f8317854>] ? __ieee80211_tx_prepare+0x194/0x3b0 [mac80211]
> [25612.560190]  [<f8319796>] ieee80211_tx+0xd6/0x280 [mac80211]
> [25612.560227]  [<f831972f>] ? ieee80211_tx+0x6f/0x280 [mac80211]
> [25612.560265]  [<f8319e39>] ieee80211_master_start_xmit+0x1f9/0x400 [mac80211]
> [25612.560280]  [<c032347b>] dev_hard_start_xmit+0x2ab/0x340
> [25612.560292]  [<c0323230>] ? dev_hard_start_xmit+0x60/0x340
> [25612.560304]  [<c0335675>] __qdisc_run+0x1e5/0x240
> [25612.560316]  [<c03245d7>] dev_queue_xmit+0x377/0x4e0
> [25612.560328]  [<c0324298>] ? dev_queue_xmit+0x38/0x4e0
> [25612.560365]  [<f831c1d2>] ieee80211_tx_skb+0x52/0x60 [mac80211]
> [25612.560400]  [<f83079d0>] ieee80211_send_delba+0xf0/0x150 [mac80211]
> [25612.560413]  [<c013f931>] ? del_timer_sync+0x81/0xb0
> [25612.560447]  [<f830903a>] __ieee80211_stop_rx_ba_session+0xea/0x1d0 [mac80211]
> [25612.560476]  [<f8409310>] ? ath9k_ampdu_action+0x0/0x130 [ath9k]
> [25612.560511]  [<f8307a63>] ieee80211_sta_tear_down_BA_sessions+0x33/0x40 [mac80211]
> [25612.560548]  [<f830afd8>] ieee80211_set_disassoc+0xc8/0x370 [mac80211]
> [25612.560583]  [<f830af10>] ? ieee80211_set_disassoc+0x0/0x370 [mac80211]
> [25612.560597]  [<c01ace6b>] ? might_fault+0x4b/0xa0
> [25612.560632]  [<f830b580>] ieee80211_sta_req_auth+0xa0/0xc0 [mac80211]
> [25612.560665]  [<f8303fde>] ieee80211_ioctl_siwessid+0xbe/0xd0 [mac80211]
> [25612.560679]  [<c02749c5>] ? copy_from_user+0x35/0x130
> [25612.560694]  [<c039d819>] ioctl_standard_call+0x199/0x3a0
> [25612.560707]  [<c032358d>] ? __dev_get_by_name+0x7d/0xa0
> [25612.560720]  [<c039d31f>] wext_handle_ioctl+0x14f/0x230
> [25612.560753]  [<f8303f20>] ? ieee80211_ioctl_siwessid+0x0/0xd0 [mac80211]
> [25612.560766]  [<c0324114>] dev_ioctl+0x474/0x540
> [25612.560780]  [<c019f685>] ? __pagevec_free+0x25/0x30
> [25612.560794]  [<c0312350>] ? sock_ioctl+0x0/0x270
> [25612.560806]  [<c0312445>] sock_ioctl+0xf5/0x270
> [25612.560817]  [<c0312350>] ? sock_ioctl+0x0/0x270
> [25612.560831]  [<c01d9018>] vfs_ioctl+0x28/0x90
> [25612.560843]  [<c01d90f2>] do_vfs_ioctl+0x72/0x590
> [25612.560856]  [<c015ce8b>] ? trace_hardirqs_on+0xb/0x10
> [25612.560868]  [<c01b2a16>] ? remove_vma+0x56/0x70
> [25612.560879]  [<c01b2a16>] ? remove_vma+0x56/0x70
> [25612.560890]  [<c01b38f7>] ? do_munmap+0x237/0x290
> [25612.560902]  [<c0103021>] ? sysenter_exit+0xf/0x1a
> [25612.560914]  [<c01d9673>] sys_ioctl+0x63/0x70
> [25612.560925]  [<c0102fec>] sysenter_do_call+0x12/0x38
> [25612.560934] ---[ end trace 05e1ecc810d6b568 ]---
> [25612.561114] ------------[ cut here ]------------
> 
> Cc: Reinette Chatre <reinette.chatre@intel.com>
> Cc: Zhu Yi <yi.zhu@intel.com>
> Cc: Mohamed Abbas <mohamed.abbas@intel.com>
> Cc: ipw3945-devel@lists.sourceforge.net
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
>  net/mac80211/util.c |   17 ++++++++++++++++-
>  1 files changed, 16 insertions(+), 1 deletions(-)
> 
> diff --git a/net/mac80211/util.c b/net/mac80211/util.c
> index 66ce96a..8e66556 100644
> --- a/net/mac80211/util.c
> +++ b/net/mac80211/util.c
> @@ -791,9 +791,24 @@ int ieee80211_set_freq(struct ieee80211_sub_if_data *sdata, int freqMHz)
>  
>  		if (local->sw_scanning || local->hw_scanning)
>  			ret = 0;
> -		else
> +		else {
> +			struct ieee80211_channel *cur_chan;
> +
> +			cur_chan = local->hw.conf.channel;
> +
> +			/*
> +			 * If we're switching bands and not scanning we
> +			 * could potentially be moving to a band our AP
> +			 * does not understand so give up on it
> +			 */
> +			if (sdata->vif.type == NL80211_IFTYPE_STATION &&
> +			    (sdata->u.mgd.flags & IEEE80211_STA_ASSOCIATED) &&
> +			    cur_chan->band != chan->band)
> +				ieee80211_sta_deauthenticate(sdata,
> +					WLAN_REASON_DEAUTH_LEAVING);
>  			ret = ieee80211_hw_config(
>  				local, IEEE80211_CONF_CHANGE_CHANNEL);
> +		}
>  	}
>  
>  	return ret;

This touches code targeted for removal in recent "mac80211: disconnect
when user changes channel" patch.

Reinette

[ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[reinette chatre]

Hi Luis,

On Wed, 2009-06-10 at 13:35 -0700, Luis R. Rodriguez wrote:
> If we're associated to an AP and we manually decide to switch
> bands we have no guarantee we can communicate with that AP
> on the new band and our current bss parameters may change
> completely so disassociate.
> 
> This fixes this warning (which is not specific to iwlwifi!):
> 
> [25612.559460] ------------[ cut here ]------------
> [25612.559500] WARNING: at include/net/mac80211.h:2127 rate_control_send_low+0xcf/0xe0 [mac80211]()
> [25612.559508] Hardware name: VGN-N170G
> [25612.559513] Modules linked in: ath9k ath mac80211 cfg80211 <bleh line cut>
> [25612.559807] Pid: 14492, comm: iwconfig Not tainted 2.6.30-rc8-wl #11
> [25612.559814] Call Trace:
> [25612.559829]  [<c03b2cd9>] ? printk+0x18/0x1f
> [25612.559865]  [<f831072f>] ? rate_control_send_low+0xcf/0xe0 [mac80211]
> [25612.559878]  [<c0134f4c>] warn_slowpath_common+0x6c/0xc0
> [25612.559912]  [<f831072f>] ? rate_control_send_low+0xcf/0xe0 [mac80211]
> [25612.559923]  [<c0134fb5>] warn_slowpath_null+0x15/0x20
> [25612.559957]  [<f831072f>] rate_control_send_low+0xcf/0xe0 [mac80211]
> [25612.559985]  [<f84129c3>] ath_get_rate+0x33/0x520 [ath9k]
> [25612.559998]  [<c015cb73>] ? mark_held_locks+0x63/0x80
> [25612.560064]  [<f831057d>] rate_control_get_rate+0xbd/0xd0 [mac80211]
> [25612.560102]  [<f8318b6f>] invoke_tx_handlers+0x5df/0xfa0 [mac80211]
> [25612.560115]  [<c015cb73>] ? mark_held_locks+0x63/0x80
> [25612.560152]  [<f8317854>] ? __ieee80211_tx_prepare+0x194/0x3b0 [mac80211]
> [25612.560190]  [<f8319796>] ieee80211_tx+0xd6/0x280 [mac80211]
> [25612.560227]  [<f831972f>] ? ieee80211_tx+0x6f/0x280 [mac80211]
> [25612.560265]  [<f8319e39>] ieee80211_master_start_xmit+0x1f9/0x400 [mac80211]
> [25612.560280]  [<c032347b>] dev_hard_start_xmit+0x2ab/0x340
> [25612.560292]  [<c0323230>] ? dev_hard_start_xmit+0x60/0x340
> [25612.560304]  [<c0335675>] __qdisc_run+0x1e5/0x240
> [25612.560316]  [<c03245d7>] dev_queue_xmit+0x377/0x4e0
> [25612.560328]  [<c0324298>] ? dev_queue_xmit+0x38/0x4e0
> [25612.560365]  [<f831c1d2>] ieee80211_tx_skb+0x52/0x60 [mac80211]
> [25612.560400]  [<f83079d0>] ieee80211_send_delba+0xf0/0x150 [mac80211]
> [25612.560413]  [<c013f931>] ? del_timer_sync+0x81/0xb0
> [25612.560447]  [<f830903a>] __ieee80211_stop_rx_ba_session+0xea/0x1d0 [mac80211]
> [25612.560476]  [<f8409310>] ? ath9k_ampdu_action+0x0/0x130 [ath9k]
> [25612.560511]  [<f8307a63>] ieee80211_sta_tear_down_BA_sessions+0x33/0x40 [mac80211]
> [25612.560548]  [<f830afd8>] ieee80211_set_disassoc+0xc8/0x370 [mac80211]
> [25612.560583]  [<f830af10>] ? ieee80211_set_disassoc+0x0/0x370 [mac80211]
> [25612.560597]  [<c01ace6b>] ? might_fault+0x4b/0xa0
> [25612.560632]  [<f830b580>] ieee80211_sta_req_auth+0xa0/0xc0 [mac80211]
> [25612.560665]  [<f8303fde>] ieee80211_ioctl_siwessid+0xbe/0xd0 [mac80211]
> [25612.560679]  [<c02749c5>] ? copy_from_user+0x35/0x130
> [25612.560694]  [<c039d819>] ioctl_standard_call+0x199/0x3a0
> [25612.560707]  [<c032358d>] ? __dev_get_by_name+0x7d/0xa0
> [25612.560720]  [<c039d31f>] wext_handle_ioctl+0x14f/0x230
> [25612.560753]  [<f8303f20>] ? ieee80211_ioctl_siwessid+0x0/0xd0 [mac80211]
> [25612.560766]  [<c0324114>] dev_ioctl+0x474/0x540
> [25612.560780]  [<c019f685>] ? __pagevec_free+0x25/0x30
> [25612.560794]  [<c0312350>] ? sock_ioctl+0x0/0x270
> [25612.560806]  [<c0312445>] sock_ioctl+0xf5/0x270
> [25612.560817]  [<c0312350>] ? sock_ioctl+0x0/0x270
> [25612.560831]  [<c01d9018>] vfs_ioctl+0x28/0x90
> [25612.560843]  [<c01d90f2>] do_vfs_ioctl+0x72/0x590
> [25612.560856]  [<c015ce8b>] ? trace_hardirqs_on+0xb/0x10
> [25612.560868]  [<c01b2a16>] ? remove_vma+0x56/0x70
> [25612.560879]  [<c01b2a16>] ? remove_vma+0x56/0x70
> [25612.560890]  [<c01b38f7>] ? do_munmap+0x237/0x290
> [25612.560902]  [<c0103021>] ? sysenter_exit+0xf/0x1a
> [25612.560914]  [<c01d9673>] sys_ioctl+0x63/0x70
> [25612.560925]  [<c0102fec>] sysenter_do_call+0x12/0x38
> [25612.560934] ---[ end trace 05e1ecc810d6b568 ]---
> [25612.561114] ------------[ cut here ]------------
> 
> Cc: Reinette Chatre <reinette.chatre@intel.com>
> Cc: Zhu Yi <yi.zhu@intel.com>
> Cc: Mohamed Abbas <mohamed.abbas@intel.com>
> Cc: ipw3945-devel at lists.sourceforge.net
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
>  net/mac80211/util.c |   17 ++++++++++++++++-
>  1 files changed, 16 insertions(+), 1 deletions(-)
> 
> diff --git a/net/mac80211/util.c b/net/mac80211/util.c
> index 66ce96a..8e66556 100644
> --- a/net/mac80211/util.c
> +++ b/net/mac80211/util.c
> @@ -791,9 +791,24 @@ int ieee80211_set_freq(struct ieee80211_sub_if_data *sdata, int freqMHz)
>  
>  		if (local->sw_scanning || local->hw_scanning)
>  			ret = 0;
> -		else
> +		else {
> +			struct ieee80211_channel *cur_chan;
> +
> +			cur_chan = local->hw.conf.channel;
> +
> +			/*
> +			 * If we're switching bands and not scanning we
> +			 * could potentially be moving to a band our AP
> +			 * does not understand so give up on it
> +			 */
> +			if (sdata->vif.type == NL80211_IFTYPE_STATION &&
> +			    (sdata->u.mgd.flags & IEEE80211_STA_ASSOCIATED) &&
> +			    cur_chan->band != chan->band)
> +				ieee80211_sta_deauthenticate(sdata,
> +					WLAN_REASON_DEAUTH_LEAVING);
>  			ret = ieee80211_hw_config(
>  				local, IEEE80211_CONF_CHANGE_CHANNEL);
> +		}
>  	}
>  
>  	return ret;

This touches code targeted for removal in recent "mac80211: disconnect
when user changes channel" patch.

Reinette

Re: [PATCH] mac80211: disassociate when switching bands and not scanning

[Luis R. Rodriguez]

On Wed, Jun 10, 2009 at 1:49 PM, reinette
chatre<reinette.chatre@intel.com> wrote:
> Hi Luis,
>
> On Wed, 2009-06-10 at 13:35 -0700, Luis R. Rodriguez wrote:
>> If we're associated to an AP and we manually decide to switch
>> bands we have no guarantee we can communicate with that AP
>> on the new band and our current bss parameters may change
>> completely so disassociate.
>>
>> This fixes this warning (which is not specific to iwlwifi!):
>>
>> [25612.559460] ------------[ cut here ]------------
>> [25612.559500] WARNING: at include/net/mac80211.h:2127 rate_control_send_low+0xcf/0xe0 [mac80211]()
>> [25612.559508] Hardware name: VGN-N170G
>> [25612.559513] Modules linked in: ath9k ath mac80211 cfg80211 <bleh line cut>
>> [25612.559807] Pid: 14492, comm: iwconfig Not tainted 2.6.30-rc8-wl #11
>> [25612.559814] Call Trace:
>> [25612.559829]  [<c03b2cd9>] ? printk+0x18/0x1f
>> [25612.559865]  [<f831072f>] ? rate_control_send_low+0xcf/0xe0 [mac80211]
>> [25612.559878]  [<c0134f4c>] warn_slowpath_common+0x6c/0xc0
>> [25612.559912]  [<f831072f>] ? rate_control_send_low+0xcf/0xe0 [mac80211]
>> [25612.559923]  [<c0134fb5>] warn_slowpath_null+0x15/0x20
>> [25612.559957]  [<f831072f>] rate_control_send_low+0xcf/0xe0 [mac80211]
>> [25612.559985]  [<f84129c3>] ath_get_rate+0x33/0x520 [ath9k]
>> [25612.559998]  [<c015cb73>] ? mark_held_locks+0x63/0x80
>> [25612.560064]  [<f831057d>] rate_control_get_rate+0xbd/0xd0 [mac80211]
>> [25612.560102]  [<f8318b6f>] invoke_tx_handlers+0x5df/0xfa0 [mac80211]
>> [25612.560115]  [<c015cb73>] ? mark_held_locks+0x63/0x80
>> [25612.560152]  [<f8317854>] ? __ieee80211_tx_prepare+0x194/0x3b0 [mac80211]
>> [25612.560190]  [<f8319796>] ieee80211_tx+0xd6/0x280 [mac80211]
>> [25612.560227]  [<f831972f>] ? ieee80211_tx+0x6f/0x280 [mac80211]
>> [25612.560265]  [<f8319e39>] ieee80211_master_start_xmit+0x1f9/0x400 [mac80211]
>> [25612.560280]  [<c032347b>] dev_hard_start_xmit+0x2ab/0x340
>> [25612.560292]  [<c0323230>] ? dev_hard_start_xmit+0x60/0x340
>> [25612.560304]  [<c0335675>] __qdisc_run+0x1e5/0x240
>> [25612.560316]  [<c03245d7>] dev_queue_xmit+0x377/0x4e0
>> [25612.560328]  [<c0324298>] ? dev_queue_xmit+0x38/0x4e0
>> [25612.560365]  [<f831c1d2>] ieee80211_tx_skb+0x52/0x60 [mac80211]
>> [25612.560400]  [<f83079d0>] ieee80211_send_delba+0xf0/0x150 [mac80211]
>> [25612.560413]  [<c013f931>] ? del_timer_sync+0x81/0xb0
>> [25612.560447]  [<f830903a>] __ieee80211_stop_rx_ba_session+0xea/0x1d0 [mac80211]
>> [25612.560476]  [<f8409310>] ? ath9k_ampdu_action+0x0/0x130 [ath9k]
>> [25612.560511]  [<f8307a63>] ieee80211_sta_tear_down_BA_sessions+0x33/0x40 [mac80211]
>> [25612.560548]  [<f830afd8>] ieee80211_set_disassoc+0xc8/0x370 [mac80211]
>> [25612.560583]  [<f830af10>] ? ieee80211_set_disassoc+0x0/0x370 [mac80211]
>> [25612.560597]  [<c01ace6b>] ? might_fault+0x4b/0xa0
>> [25612.560632]  [<f830b580>] ieee80211_sta_req_auth+0xa0/0xc0 [mac80211]
>> [25612.560665]  [<f8303fde>] ieee80211_ioctl_siwessid+0xbe/0xd0 [mac80211]
>> [25612.560679]  [<c02749c5>] ? copy_from_user+0x35/0x130
>> [25612.560694]  [<c039d819>] ioctl_standard_call+0x199/0x3a0
>> [25612.560707]  [<c032358d>] ? __dev_get_by_name+0x7d/0xa0
>> [25612.560720]  [<c039d31f>] wext_handle_ioctl+0x14f/0x230
>> [25612.560753]  [<f8303f20>] ? ieee80211_ioctl_siwessid+0x0/0xd0 [mac80211]
>> [25612.560766]  [<c0324114>] dev_ioctl+0x474/0x540
>> [25612.560780]  [<c019f685>] ? __pagevec_free+0x25/0x30
>> [25612.560794]  [<c0312350>] ? sock_ioctl+0x0/0x270
>> [25612.560806]  [<c0312445>] sock_ioctl+0xf5/0x270
>> [25612.560817]  [<c0312350>] ? sock_ioctl+0x0/0x270
>> [25612.560831]  [<c01d9018>] vfs_ioctl+0x28/0x90
>> [25612.560843]  [<c01d90f2>] do_vfs_ioctl+0x72/0x590
>> [25612.560856]  [<c015ce8b>] ? trace_hardirqs_on+0xb/0x10
>> [25612.560868]  [<c01b2a16>] ? remove_vma+0x56/0x70
>> [25612.560879]  [<c01b2a16>] ? remove_vma+0x56/0x70
>> [25612.560890]  [<c01b38f7>] ? do_munmap+0x237/0x290
>> [25612.560902]  [<c0103021>] ? sysenter_exit+0xf/0x1a
>> [25612.560914]  [<c01d9673>] sys_ioctl+0x63/0x70
>> [25612.560925]  [<c0102fec>] sysenter_do_call+0x12/0x38
>> [25612.560934] ---[ end trace 05e1ecc810d6b568 ]---
>> [25612.561114] ------------[ cut here ]------------
>>
>> Cc: Reinette Chatre <reinette.chatre@intel.com>
>> Cc: Zhu Yi <yi.zhu@intel.com>
>> Cc: Mohamed Abbas <mohamed.abbas@intel.com>
>> Cc: ipw3945-devel@lists.sourceforge.net
>> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>> ---
>>  net/mac80211/util.c |   17 ++++++++++++++++-
>>  1 files changed, 16 insertions(+), 1 deletions(-)
>>
>> diff --git a/net/mac80211/util.c b/net/mac80211/util.c
>> index 66ce96a..8e66556 100644
>> --- a/net/mac80211/util.c
>> +++ b/net/mac80211/util.c
>> @@ -791,9 +791,24 @@ int ieee80211_set_freq(struct ieee80211_sub_if_data *sdata, int freqMHz)
>>
>>               if (local->sw_scanning || local->hw_scanning)
>>                       ret = 0;
>> -             else
>> +             else {
>> +                     struct ieee80211_channel *cur_chan;
>> +
>> +                     cur_chan = local->hw.conf.channel;
>> +
>> +                     /*
>> +                      * If we're switching bands and not scanning we
>> +                      * could potentially be moving to a band our AP
>> +                      * does not understand so give up on it
>> +                      */
>> +                     if (sdata->vif.type == NL80211_IFTYPE_STATION &&
>> +                         (sdata->u.mgd.flags & IEEE80211_STA_ASSOCIATED) &&
>> +                         cur_chan->band != chan->band)
>> +                             ieee80211_sta_deauthenticate(sdata,
>> +                                     WLAN_REASON_DEAUTH_LEAVING);
>>                       ret = ieee80211_hw_config(
>>                               local, IEEE80211_CONF_CHANGE_CHANNEL);
>> +             }
>>       }
>>
>>       return ret;
>
> This touches code targeted for removal in recent "mac80211: disconnect
> when user changes channel" patch.

Heh I don't see that patch yet but if it exists that should fix this
too unless that patch didn't deauth/disassoc. Did you try with it
applied by any chance? I can't seem to find that patch on the list.

  Luis

[ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[Luis R. Rodriguez]

On Wed, Jun 10, 2009 at 1:49 PM, reinette
chatre<reinette.chatre@intel.com> wrote:
> Hi Luis,
>
> On Wed, 2009-06-10 at 13:35 -0700, Luis R. Rodriguez wrote:
>> If we're associated to an AP and we manually decide to switch
>> bands we have no guarantee we can communicate with that AP
>> on the new band and our current bss parameters may change
>> completely so disassociate.
>>
>> This fixes this warning (which is not specific to iwlwifi!):
>>
>> [25612.559460] ------------[ cut here ]------------
>> [25612.559500] WARNING: at include/net/mac80211.h:2127 rate_control_send_low+0xcf/0xe0 [mac80211]()
>> [25612.559508] Hardware name: VGN-N170G
>> [25612.559513] Modules linked in: ath9k ath mac80211 cfg80211 <bleh line cut>
>> [25612.559807] Pid: 14492, comm: iwconfig Not tainted 2.6.30-rc8-wl #11
>> [25612.559814] Call Trace:
>> [25612.559829] ?[<c03b2cd9>] ? printk+0x18/0x1f
>> [25612.559865] ?[<f831072f>] ? rate_control_send_low+0xcf/0xe0 [mac80211]
>> [25612.559878] ?[<c0134f4c>] warn_slowpath_common+0x6c/0xc0
>> [25612.559912] ?[<f831072f>] ? rate_control_send_low+0xcf/0xe0 [mac80211]
>> [25612.559923] ?[<c0134fb5>] warn_slowpath_null+0x15/0x20
>> [25612.559957] ?[<f831072f>] rate_control_send_low+0xcf/0xe0 [mac80211]
>> [25612.559985] ?[<f84129c3>] ath_get_rate+0x33/0x520 [ath9k]
>> [25612.559998] ?[<c015cb73>] ? mark_held_locks+0x63/0x80
>> [25612.560064] ?[<f831057d>] rate_control_get_rate+0xbd/0xd0 [mac80211]
>> [25612.560102] ?[<f8318b6f>] invoke_tx_handlers+0x5df/0xfa0 [mac80211]
>> [25612.560115] ?[<c015cb73>] ? mark_held_locks+0x63/0x80
>> [25612.560152] ?[<f8317854>] ? __ieee80211_tx_prepare+0x194/0x3b0 [mac80211]
>> [25612.560190] ?[<f8319796>] ieee80211_tx+0xd6/0x280 [mac80211]
>> [25612.560227] ?[<f831972f>] ? ieee80211_tx+0x6f/0x280 [mac80211]
>> [25612.560265] ?[<f8319e39>] ieee80211_master_start_xmit+0x1f9/0x400 [mac80211]
>> [25612.560280] ?[<c032347b>] dev_hard_start_xmit+0x2ab/0x340
>> [25612.560292] ?[<c0323230>] ? dev_hard_start_xmit+0x60/0x340
>> [25612.560304] ?[<c0335675>] __qdisc_run+0x1e5/0x240
>> [25612.560316] ?[<c03245d7>] dev_queue_xmit+0x377/0x4e0
>> [25612.560328] ?[<c0324298>] ? dev_queue_xmit+0x38/0x4e0
>> [25612.560365] ?[<f831c1d2>] ieee80211_tx_skb+0x52/0x60 [mac80211]
>> [25612.560400] ?[<f83079d0>] ieee80211_send_delba+0xf0/0x150 [mac80211]
>> [25612.560413] ?[<c013f931>] ? del_timer_sync+0x81/0xb0
>> [25612.560447] ?[<f830903a>] __ieee80211_stop_rx_ba_session+0xea/0x1d0 [mac80211]
>> [25612.560476] ?[<f8409310>] ? ath9k_ampdu_action+0x0/0x130 [ath9k]
>> [25612.560511] ?[<f8307a63>] ieee80211_sta_tear_down_BA_sessions+0x33/0x40 [mac80211]
>> [25612.560548] ?[<f830afd8>] ieee80211_set_disassoc+0xc8/0x370 [mac80211]
>> [25612.560583] ?[<f830af10>] ? ieee80211_set_disassoc+0x0/0x370 [mac80211]
>> [25612.560597] ?[<c01ace6b>] ? might_fault+0x4b/0xa0
>> [25612.560632] ?[<f830b580>] ieee80211_sta_req_auth+0xa0/0xc0 [mac80211]
>> [25612.560665] ?[<f8303fde>] ieee80211_ioctl_siwessid+0xbe/0xd0 [mac80211]
>> [25612.560679] ?[<c02749c5>] ? copy_from_user+0x35/0x130
>> [25612.560694] ?[<c039d819>] ioctl_standard_call+0x199/0x3a0
>> [25612.560707] ?[<c032358d>] ? __dev_get_by_name+0x7d/0xa0
>> [25612.560720] ?[<c039d31f>] wext_handle_ioctl+0x14f/0x230
>> [25612.560753] ?[<f8303f20>] ? ieee80211_ioctl_siwessid+0x0/0xd0 [mac80211]
>> [25612.560766] ?[<c0324114>] dev_ioctl+0x474/0x540
>> [25612.560780] ?[<c019f685>] ? __pagevec_free+0x25/0x30
>> [25612.560794] ?[<c0312350>] ? sock_ioctl+0x0/0x270
>> [25612.560806] ?[<c0312445>] sock_ioctl+0xf5/0x270
>> [25612.560817] ?[<c0312350>] ? sock_ioctl+0x0/0x270
>> [25612.560831] ?[<c01d9018>] vfs_ioctl+0x28/0x90
>> [25612.560843] ?[<c01d90f2>] do_vfs_ioctl+0x72/0x590
>> [25612.560856] ?[<c015ce8b>] ? trace_hardirqs_on+0xb/0x10
>> [25612.560868] ?[<c01b2a16>] ? remove_vma+0x56/0x70
>> [25612.560879] ?[<c01b2a16>] ? remove_vma+0x56/0x70
>> [25612.560890] ?[<c01b38f7>] ? do_munmap+0x237/0x290
>> [25612.560902] ?[<c0103021>] ? sysenter_exit+0xf/0x1a
>> [25612.560914] ?[<c01d9673>] sys_ioctl+0x63/0x70
>> [25612.560925] ?[<c0102fec>] sysenter_do_call+0x12/0x38
>> [25612.560934] ---[ end trace 05e1ecc810d6b568 ]---
>> [25612.561114] ------------[ cut here ]------------
>>
>> Cc: Reinette Chatre <reinette.chatre@intel.com>
>> Cc: Zhu Yi <yi.zhu@intel.com>
>> Cc: Mohamed Abbas <mohamed.abbas@intel.com>
>> Cc: ipw3945-devel at lists.sourceforge.net
>> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>> ---
>> ?net/mac80211/util.c | ? 17 ++++++++++++++++-
>> ?1 files changed, 16 insertions(+), 1 deletions(-)
>>
>> diff --git a/net/mac80211/util.c b/net/mac80211/util.c
>> index 66ce96a..8e66556 100644
>> --- a/net/mac80211/util.c
>> +++ b/net/mac80211/util.c
>> @@ -791,9 +791,24 @@ int ieee80211_set_freq(struct ieee80211_sub_if_data *sdata, int freqMHz)
>>
>> ? ? ? ? ? ? ? if (local->sw_scanning || local->hw_scanning)
>> ? ? ? ? ? ? ? ? ? ? ? ret = 0;
>> - ? ? ? ? ? ? else
>> + ? ? ? ? ? ? else {
>> + ? ? ? ? ? ? ? ? ? ? struct ieee80211_channel *cur_chan;
>> +
>> + ? ? ? ? ? ? ? ? ? ? cur_chan = local->hw.conf.channel;
>> +
>> + ? ? ? ? ? ? ? ? ? ? /*
>> + ? ? ? ? ? ? ? ? ? ? ?* If we're switching bands and not scanning we
>> + ? ? ? ? ? ? ? ? ? ? ?* could potentially be moving to a band our AP
>> + ? ? ? ? ? ? ? ? ? ? ?* does not understand so give up on it
>> + ? ? ? ? ? ? ? ? ? ? ?*/
>> + ? ? ? ? ? ? ? ? ? ? if (sdata->vif.type == NL80211_IFTYPE_STATION &&
>> + ? ? ? ? ? ? ? ? ? ? ? ? (sdata->u.mgd.flags & IEEE80211_STA_ASSOCIATED) &&
>> + ? ? ? ? ? ? ? ? ? ? ? ? cur_chan->band != chan->band)
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ieee80211_sta_deauthenticate(sdata,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? WLAN_REASON_DEAUTH_LEAVING);
>> ? ? ? ? ? ? ? ? ? ? ? ret = ieee80211_hw_config(
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? local, IEEE80211_CONF_CHANGE_CHANNEL);
>> + ? ? ? ? ? ? }
>> ? ? ? }
>>
>> ? ? ? return ret;
>
> This touches code targeted for removal in recent "mac80211: disconnect
> when user changes channel" patch.

Heh I don't see that patch yet but if it exists that should fix this
too unless that patch didn't deauth/disassoc. Did you try with it
applied by any chance? I can't seem to find that patch on the list.

  Luis

Re: [PATCH] mac80211: disassociate when switching bands and not scanning

[reinette chatre]

Hi Luis,

On Wed, 2009-06-10 at 13:49 -0700, Luis R. Rodriguez wrote:
> On Wed, Jun 10, 2009 at 1:49 PM, reinette
> chatre<reinette.chatre@intel.com> wrote:
> > Hi Luis,
> >
> > On Wed, 2009-06-10 at 13:35 -0700, Luis R. Rodriguez wrote:
> >> If we're associated to an AP and we manually decide to switch
> >> bands we have no guarantee we can communicate with that AP
> >> on the new band and our current bss parameters may change
> >> completely so disassociate.
> >>
> >> This fixes this warning (which is not specific to iwlwifi!):
> >>
> >> [25612.559460] ------------[ cut here ]------------
> >> [25612.559500] WARNING: at include/net/mac80211.h:2127 rate_control_send_low+0xcf/0xe0 [mac80211]()
> >> [25612.559508] Hardware name: VGN-N170G
> >> [25612.559513] Modules linked in: ath9k ath mac80211 cfg80211 <bleh line cut>
> >> [25612.559807] Pid: 14492, comm: iwconfig Not tainted 2.6.30-rc8-wl #11
> >> [25612.559814] Call Trace:
> >> [25612.559829]  [<c03b2cd9>] ? printk+0x18/0x1f
> >> [25612.559865]  [<f831072f>] ? rate_control_send_low+0xcf/0xe0 [mac80211]
> >> [25612.559878]  [<c0134f4c>] warn_slowpath_common+0x6c/0xc0
> >> [25612.559912]  [<f831072f>] ? rate_control_send_low+0xcf/0xe0 [mac80211]
> >> [25612.559923]  [<c0134fb5>] warn_slowpath_null+0x15/0x20
> >> [25612.559957]  [<f831072f>] rate_control_send_low+0xcf/0xe0 [mac80211]
> >> [25612.559985]  [<f84129c3>] ath_get_rate+0x33/0x520 [ath9k]
> >> [25612.559998]  [<c015cb73>] ? mark_held_locks+0x63/0x80
> >> [25612.560064]  [<f831057d>] rate_control_get_rate+0xbd/0xd0 [mac80211]
> >> [25612.560102]  [<f8318b6f>] invoke_tx_handlers+0x5df/0xfa0 [mac80211]
> >> [25612.560115]  [<c015cb73>] ? mark_held_locks+0x63/0x80
> >> [25612.560152]  [<f8317854>] ? __ieee80211_tx_prepare+0x194/0x3b0 [mac80211]
> >> [25612.560190]  [<f8319796>] ieee80211_tx+0xd6/0x280 [mac80211]
> >> [25612.560227]  [<f831972f>] ? ieee80211_tx+0x6f/0x280 [mac80211]
> >> [25612.560265]  [<f8319e39>] ieee80211_master_start_xmit+0x1f9/0x400 [mac80211]
> >> [25612.560280]  [<c032347b>] dev_hard_start_xmit+0x2ab/0x340
> >> [25612.560292]  [<c0323230>] ? dev_hard_start_xmit+0x60/0x340
> >> [25612.560304]  [<c0335675>] __qdisc_run+0x1e5/0x240
> >> [25612.560316]  [<c03245d7>] dev_queue_xmit+0x377/0x4e0
> >> [25612.560328]  [<c0324298>] ? dev_queue_xmit+0x38/0x4e0
> >> [25612.560365]  [<f831c1d2>] ieee80211_tx_skb+0x52/0x60 [mac80211]
> >> [25612.560400]  [<f83079d0>] ieee80211_send_delba+0xf0/0x150 [mac80211]
> >> [25612.560413]  [<c013f931>] ? del_timer_sync+0x81/0xb0
> >> [25612.560447]  [<f830903a>] __ieee80211_stop_rx_ba_session+0xea/0x1d0 [mac80211]
> >> [25612.560476]  [<f8409310>] ? ath9k_ampdu_action+0x0/0x130 [ath9k]
> >> [25612.560511]  [<f8307a63>] ieee80211_sta_tear_down_BA_sessions+0x33/0x40 [mac80211]
> >> [25612.560548]  [<f830afd8>] ieee80211_set_disassoc+0xc8/0x370 [mac80211]
> >> [25612.560583]  [<f830af10>] ? ieee80211_set_disassoc+0x0/0x370 [mac80211]
> >> [25612.560597]  [<c01ace6b>] ? might_fault+0x4b/0xa0
> >> [25612.560632]  [<f830b580>] ieee80211_sta_req_auth+0xa0/0xc0 [mac80211]
> >> [25612.560665]  [<f8303fde>] ieee80211_ioctl_siwessid+0xbe/0xd0 [mac80211]
> >> [25612.560679]  [<c02749c5>] ? copy_from_user+0x35/0x130
> >> [25612.560694]  [<c039d819>] ioctl_standard_call+0x199/0x3a0
> >> [25612.560707]  [<c032358d>] ? __dev_get_by_name+0x7d/0xa0
> >> [25612.560720]  [<c039d31f>] wext_handle_ioctl+0x14f/0x230
> >> [25612.560753]  [<f8303f20>] ? ieee80211_ioctl_siwessid+0x0/0xd0 [mac80211]
> >> [25612.560766]  [<c0324114>] dev_ioctl+0x474/0x540
> >> [25612.560780]  [<c019f685>] ? __pagevec_free+0x25/0x30
> >> [25612.560794]  [<c0312350>] ? sock_ioctl+0x0/0x270
> >> [25612.560806]  [<c0312445>] sock_ioctl+0xf5/0x270
> >> [25612.560817]  [<c0312350>] ? sock_ioctl+0x0/0x270
> >> [25612.560831]  [<c01d9018>] vfs_ioctl+0x28/0x90
> >> [25612.560843]  [<c01d90f2>] do_vfs_ioctl+0x72/0x590
> >> [25612.560856]  [<c015ce8b>] ? trace_hardirqs_on+0xb/0x10
> >> [25612.560868]  [<c01b2a16>] ? remove_vma+0x56/0x70
> >> [25612.560879]  [<c01b2a16>] ? remove_vma+0x56/0x70
> >> [25612.560890]  [<c01b38f7>] ? do_munmap+0x237/0x290
> >> [25612.560902]  [<c0103021>] ? sysenter_exit+0xf/0x1a
> >> [25612.560914]  [<c01d9673>] sys_ioctl+0x63/0x70
> >> [25612.560925]  [<c0102fec>] sysenter_do_call+0x12/0x38
> >> [25612.560934] ---[ end trace 05e1ecc810d6b568 ]---
> >> [25612.561114] ------------[ cut here ]------------
> >>
> >> Cc: Reinette Chatre <reinette.chatre@intel.com>
> >> Cc: Zhu Yi <yi.zhu@intel.com>
> >> Cc: Mohamed Abbas <mohamed.abbas@intel.com>
> >> Cc: ipw3945-devel@lists.sourceforge.net
> >> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> >> ---
> >>  net/mac80211/util.c |   17 ++++++++++++++++-
> >>  1 files changed, 16 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/net/mac80211/util.c b/net/mac80211/util.c
> >> index 66ce96a..8e66556 100644
> >> --- a/net/mac80211/util.c
> >> +++ b/net/mac80211/util.c
> >> @@ -791,9 +791,24 @@ int ieee80211_set_freq(struct ieee80211_sub_if_data *sdata, int freqMHz)
> >>
> >>               if (local->sw_scanning || local->hw_scanning)
> >>                       ret = 0;
> >> -             else
> >> +             else {
> >> +                     struct ieee80211_channel *cur_chan;
> >> +
> >> +                     cur_chan = local->hw.conf.channel;
> >> +
> >> +                     /*
> >> +                      * If we're switching bands and not scanning we
> >> +                      * could potentially be moving to a band our AP
> >> +                      * does not understand so give up on it
> >> +                      */
> >> +                     if (sdata->vif.type == NL80211_IFTYPE_STATION &&
> >> +                         (sdata->u.mgd.flags & IEEE80211_STA_ASSOCIATED) &&
> >> +                         cur_chan->band != chan->band)
> >> +                             ieee80211_sta_deauthenticate(sdata,
> >> +                                     WLAN_REASON_DEAUTH_LEAVING);
> >>                       ret = ieee80211_hw_config(
> >>                               local, IEEE80211_CONF_CHANGE_CHANNEL);
> >> +             }
> >>       }
> >>
> >>       return ret;
> >
> > This touches code targeted for removal in recent "mac80211: disconnect
> > when user changes channel" patch.
> 
> Heh I don't see that patch yet but if it exists that should fix this
> too unless that patch didn't deauth/disassoc. Did you try with it
> applied by any chance? I can't seem to find that patch on the list.

That patch does seem to have same intention as yours. It is still RFC so
I am not sure about its status. I did not test with it, but will do so.
The patch can be found at
http://marc.info/?l=linux-wireless&m=124458448631186&w=2

Reinette

[ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[reinette chatre]

Hi Luis,

On Wed, 2009-06-10 at 13:49 -0700, Luis R. Rodriguez wrote:
> On Wed, Jun 10, 2009 at 1:49 PM, reinette
> chatre<reinette.chatre@intel.com> wrote:
> > Hi Luis,
> >
> > On Wed, 2009-06-10 at 13:35 -0700, Luis R. Rodriguez wrote:
> >> If we're associated to an AP and we manually decide to switch
> >> bands we have no guarantee we can communicate with that AP
> >> on the new band and our current bss parameters may change
> >> completely so disassociate.
> >>
> >> This fixes this warning (which is not specific to iwlwifi!):
> >>
> >> [25612.559460] ------------[ cut here ]------------
> >> [25612.559500] WARNING: at include/net/mac80211.h:2127 rate_control_send_low+0xcf/0xe0 [mac80211]()
> >> [25612.559508] Hardware name: VGN-N170G
> >> [25612.559513] Modules linked in: ath9k ath mac80211 cfg80211 <bleh line cut>
> >> [25612.559807] Pid: 14492, comm: iwconfig Not tainted 2.6.30-rc8-wl #11
> >> [25612.559814] Call Trace:
> >> [25612.559829]  [<c03b2cd9>] ? printk+0x18/0x1f
> >> [25612.559865]  [<f831072f>] ? rate_control_send_low+0xcf/0xe0 [mac80211]
> >> [25612.559878]  [<c0134f4c>] warn_slowpath_common+0x6c/0xc0
> >> [25612.559912]  [<f831072f>] ? rate_control_send_low+0xcf/0xe0 [mac80211]
> >> [25612.559923]  [<c0134fb5>] warn_slowpath_null+0x15/0x20
> >> [25612.559957]  [<f831072f>] rate_control_send_low+0xcf/0xe0 [mac80211]
> >> [25612.559985]  [<f84129c3>] ath_get_rate+0x33/0x520 [ath9k]
> >> [25612.559998]  [<c015cb73>] ? mark_held_locks+0x63/0x80
> >> [25612.560064]  [<f831057d>] rate_control_get_rate+0xbd/0xd0 [mac80211]
> >> [25612.560102]  [<f8318b6f>] invoke_tx_handlers+0x5df/0xfa0 [mac80211]
> >> [25612.560115]  [<c015cb73>] ? mark_held_locks+0x63/0x80
> >> [25612.560152]  [<f8317854>] ? __ieee80211_tx_prepare+0x194/0x3b0 [mac80211]
> >> [25612.560190]  [<f8319796>] ieee80211_tx+0xd6/0x280 [mac80211]
> >> [25612.560227]  [<f831972f>] ? ieee80211_tx+0x6f/0x280 [mac80211]
> >> [25612.560265]  [<f8319e39>] ieee80211_master_start_xmit+0x1f9/0x400 [mac80211]
> >> [25612.560280]  [<c032347b>] dev_hard_start_xmit+0x2ab/0x340
> >> [25612.560292]  [<c0323230>] ? dev_hard_start_xmit+0x60/0x340
> >> [25612.560304]  [<c0335675>] __qdisc_run+0x1e5/0x240
> >> [25612.560316]  [<c03245d7>] dev_queue_xmit+0x377/0x4e0
> >> [25612.560328]  [<c0324298>] ? dev_queue_xmit+0x38/0x4e0
> >> [25612.560365]  [<f831c1d2>] ieee80211_tx_skb+0x52/0x60 [mac80211]
> >> [25612.560400]  [<f83079d0>] ieee80211_send_delba+0xf0/0x150 [mac80211]
> >> [25612.560413]  [<c013f931>] ? del_timer_sync+0x81/0xb0
> >> [25612.560447]  [<f830903a>] __ieee80211_stop_rx_ba_session+0xea/0x1d0 [mac80211]
> >> [25612.560476]  [<f8409310>] ? ath9k_ampdu_action+0x0/0x130 [ath9k]
> >> [25612.560511]  [<f8307a63>] ieee80211_sta_tear_down_BA_sessions+0x33/0x40 [mac80211]
> >> [25612.560548]  [<f830afd8>] ieee80211_set_disassoc+0xc8/0x370 [mac80211]
> >> [25612.560583]  [<f830af10>] ? ieee80211_set_disassoc+0x0/0x370 [mac80211]
> >> [25612.560597]  [<c01ace6b>] ? might_fault+0x4b/0xa0
> >> [25612.560632]  [<f830b580>] ieee80211_sta_req_auth+0xa0/0xc0 [mac80211]
> >> [25612.560665]  [<f8303fde>] ieee80211_ioctl_siwessid+0xbe/0xd0 [mac80211]
> >> [25612.560679]  [<c02749c5>] ? copy_from_user+0x35/0x130
> >> [25612.560694]  [<c039d819>] ioctl_standard_call+0x199/0x3a0
> >> [25612.560707]  [<c032358d>] ? __dev_get_by_name+0x7d/0xa0
> >> [25612.560720]  [<c039d31f>] wext_handle_ioctl+0x14f/0x230
> >> [25612.560753]  [<f8303f20>] ? ieee80211_ioctl_siwessid+0x0/0xd0 [mac80211]
> >> [25612.560766]  [<c0324114>] dev_ioctl+0x474/0x540
> >> [25612.560780]  [<c019f685>] ? __pagevec_free+0x25/0x30
> >> [25612.560794]  [<c0312350>] ? sock_ioctl+0x0/0x270
> >> [25612.560806]  [<c0312445>] sock_ioctl+0xf5/0x270
> >> [25612.560817]  [<c0312350>] ? sock_ioctl+0x0/0x270
> >> [25612.560831]  [<c01d9018>] vfs_ioctl+0x28/0x90
> >> [25612.560843]  [<c01d90f2>] do_vfs_ioctl+0x72/0x590
> >> [25612.560856]  [<c015ce8b>] ? trace_hardirqs_on+0xb/0x10
> >> [25612.560868]  [<c01b2a16>] ? remove_vma+0x56/0x70
> >> [25612.560879]  [<c01b2a16>] ? remove_vma+0x56/0x70
> >> [25612.560890]  [<c01b38f7>] ? do_munmap+0x237/0x290
> >> [25612.560902]  [<c0103021>] ? sysenter_exit+0xf/0x1a
> >> [25612.560914]  [<c01d9673>] sys_ioctl+0x63/0x70
> >> [25612.560925]  [<c0102fec>] sysenter_do_call+0x12/0x38
> >> [25612.560934] ---[ end trace 05e1ecc810d6b568 ]---
> >> [25612.561114] ------------[ cut here ]------------
> >>
> >> Cc: Reinette Chatre <reinette.chatre@intel.com>
> >> Cc: Zhu Yi <yi.zhu@intel.com>
> >> Cc: Mohamed Abbas <mohamed.abbas@intel.com>
> >> Cc: ipw3945-devel at lists.sourceforge.net
> >> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> >> ---
> >>  net/mac80211/util.c |   17 ++++++++++++++++-
> >>  1 files changed, 16 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/net/mac80211/util.c b/net/mac80211/util.c
> >> index 66ce96a..8e66556 100644
> >> --- a/net/mac80211/util.c
> >> +++ b/net/mac80211/util.c
> >> @@ -791,9 +791,24 @@ int ieee80211_set_freq(struct ieee80211_sub_if_data *sdata, int freqMHz)
> >>
> >>               if (local->sw_scanning || local->hw_scanning)
> >>                       ret = 0;
> >> -             else
> >> +             else {
> >> +                     struct ieee80211_channel *cur_chan;
> >> +
> >> +                     cur_chan = local->hw.conf.channel;
> >> +
> >> +                     /*
> >> +                      * If we're switching bands and not scanning we
> >> +                      * could potentially be moving to a band our AP
> >> +                      * does not understand so give up on it
> >> +                      */
> >> +                     if (sdata->vif.type == NL80211_IFTYPE_STATION &&
> >> +                         (sdata->u.mgd.flags & IEEE80211_STA_ASSOCIATED) &&
> >> +                         cur_chan->band != chan->band)
> >> +                             ieee80211_sta_deauthenticate(sdata,
> >> +                                     WLAN_REASON_DEAUTH_LEAVING);
> >>                       ret = ieee80211_hw_config(
> >>                               local, IEEE80211_CONF_CHANGE_CHANNEL);
> >> +             }
> >>       }
> >>
> >>       return ret;
> >
> > This touches code targeted for removal in recent "mac80211: disconnect
> > when user changes channel" patch.
> 
> Heh I don't see that patch yet but if it exists that should fix this
> too unless that patch didn't deauth/disassoc. Did you try with it
> applied by any chance? I can't seem to find that patch on the list.

That patch does seem to have same intention as yours. It is still RFC so
I am not sure about its status. I did not test with it, but will do so.
The patch can be found at
http://marc.info/?l=linux-wireless&m=124458448631186&w=2

Reinette

Re: [ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[Luis R. Rodriguez]

On Wed, Jun 10, 2009 at 2:03 PM, reinette
chatre<reinette.chatre@intel.com> wrote:

>> > This touches code targeted for removal in recent "mac80211: disconnect
>> > when user changes channel" patch.
>>
>> Heh I don't see that patch yet but if it exists that should fix this
>> too unless that patch didn't deauth/disassoc. Did you try with it
>> applied by any chance? I can't seem to find that patch on the list.
>
> That patch does seem to have same intention as yours. It is still RFC so
> I am not sure about its status. I did not test with it, but will do so.
> The patch can be found at
> http://marc.info/?l=linux-wireless&m=124458448631186&w=2

Thanks yes, I see, yup I think that should fix it, we need a fix for
stable though. Not sure how John or Johannes want to handle this.

  Luis

[ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[Luis R. Rodriguez]

On Wed, Jun 10, 2009 at 2:03 PM, reinette
chatre<reinette.chatre@intel.com> wrote:

>> > This touches code targeted for removal in recent "mac80211: disconnect
>> > when user changes channel" patch.
>>
>> Heh I don't see that patch yet but if it exists that should fix this
>> too unless that patch didn't deauth/disassoc. Did you try with it
>> applied by any chance? I can't seem to find that patch on the list.
>
> That patch does seem to have same intention as yours. It is still RFC so
> I am not sure about its status. I did not test with it, but will do so.
> The patch can be found at
> http://marc.info/?l=linux-wireless&m=124458448631186&w=2

Thanks yes, I see, yup I think that should fix it, we need a fix for
stable though. Not sure how John or Johannes want to handle this.

  Luis

Re: [PATCH] mac80211: disassociate when switching bands and not scanning

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]

On Wed, 2009-06-10 at 14:03 -0700, reinette chatre wrote:

> > > This touches code targeted for removal in recent "mac80211: disconnect
> > > when user changes channel" patch.
> > 
> > Heh I don't see that patch yet but if it exists that should fix this
> > too unless that patch didn't deauth/disassoc. Did you try with it
> > applied by any chance? I can't seem to find that patch on the list.
> 
> That patch does seem to have same intention as yours. It is still RFC so
> I am not sure about its status. I did not test with it, but will do so.
> The patch can be found at
> http://marc.info/?l=linux-wireless&m=124458448631186&w=2

I'm waiting for a reply on the bug report (2015). Unfortunately, the bug
report is complicated by the hang issue so I'm not sure, will probably
post this patch for inclusion soon unless somebody objects.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[Johannes Berg]

On Wed, 2009-06-10 at 14:03 -0700, reinette chatre wrote:

> > > This touches code targeted for removal in recent "mac80211: disconnect
> > > when user changes channel" patch.
> > 
> > Heh I don't see that patch yet but if it exists that should fix this
> > too unless that patch didn't deauth/disassoc. Did you try with it
> > applied by any chance? I can't seem to find that patch on the list.
> 
> That patch does seem to have same intention as yours. It is still RFC so
> I am not sure about its status. I did not test with it, but will do so.
> The patch can be found at
> http://marc.info/?l=linux-wireless&m=124458448631186&w=2

I'm waiting for a reply on the bug report (2015). Unfortunately, the bug
report is complicated by the hang issue so I'm not sure, will probably
post this patch for inclusion soon unless somebody objects.

johannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20090610/5150806c/attachment.pgp 

Re: [ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 984 bytes --]

On Wed, 2009-06-10 at 14:04 -0700, Luis R. Rodriguez wrote:
> On Wed, Jun 10, 2009 at 2:03 PM, reinette
> chatre<reinette.chatre@intel.com> wrote:
> 
> >> > This touches code targeted for removal in recent "mac80211: disconnect
> >> > when user changes channel" patch.
> >>
> >> Heh I don't see that patch yet but if it exists that should fix this
> >> too unless that patch didn't deauth/disassoc. Did you try with it
> >> applied by any chance? I can't seem to find that patch on the list.
> >
> > That patch does seem to have same intention as yours. It is still RFC so
> > I am not sure about its status. I did not test with it, but will do so.
> > The patch can be found at
> > http://marc.info/?l=linux-wireless&m=124458448631186&w=2
> 
> Thanks yes, I see, yup I think that should fix it, we need a fix for
> stable though. Not sure how John or Johannes want to handle this.

*scratches head*
are you advocating those rate cleanups for stable?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[Johannes Berg]

On Wed, 2009-06-10 at 14:04 -0700, Luis R. Rodriguez wrote:
> On Wed, Jun 10, 2009 at 2:03 PM, reinette
> chatre<reinette.chatre@intel.com> wrote:
> 
> >> > This touches code targeted for removal in recent "mac80211: disconnect
> >> > when user changes channel" patch.
> >>
> >> Heh I don't see that patch yet but if it exists that should fix this
> >> too unless that patch didn't deauth/disassoc. Did you try with it
> >> applied by any chance? I can't seem to find that patch on the list.
> >
> > That patch does seem to have same intention as yours. It is still RFC so
> > I am not sure about its status. I did not test with it, but will do so.
> > The patch can be found at
> > http://marc.info/?l=linux-wireless&m=124458448631186&w=2
> 
> Thanks yes, I see, yup I think that should fix it, we need a fix for
> stable though. Not sure how John or Johannes want to handle this.

*scratches head*
are you advocating those rate cleanups for stable?

johannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20090610/1e43e422/attachment.pgp 

[ath9k-devel] My TL-WN821N - 802.11n

[Enrique Layme Bedregal]

Hi

 

I don't have happen with this board(TL-WN821N atk9), i have installed the .tar files in my box, but anything happens.

Somebody can help me with some instructions.

 

My Linux is Fedora 10 ( Kernel >2.6)

 

 

Thanks a lot

_________________________________________________________________
See how Windows? connects the people, information, and fun that are part of your life
http://clk.atdmt.com/MRT/go/119463819/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20090610/6a3a5fac/attachment-0001.htm 

Re: [ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[Luis R. Rodriguez]

On Wed, Jun 10, 2009 at 2:07 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Wed, 2009-06-10 at 14:04 -0700, Luis R. Rodriguez wrote:
>> On Wed, Jun 10, 2009 at 2:03 PM, reinette
>> chatre<reinette.chatre@intel.com> wrote:
>>
>> >> > This touches code targeted for removal in recent "mac80211: disconnect
>> >> > when user changes channel" patch.
>> >>
>> >> Heh I don't see that patch yet but if it exists that should fix this
>> >> too unless that patch didn't deauth/disassoc. Did you try with it
>> >> applied by any chance? I can't seem to find that patch on the list.
>> >
>> > That patch does seem to have same intention as yours. It is still RFC so
>> > I am not sure about its status. I did not test with it, but will do so.
>> > The patch can be found at
>> > http://marc.info/?l=linux-wireless&m=124458448631186&w=2
>>
>> Thanks yes, I see, yup I think that should fix it, we need a fix for
>> stable though. Not sure how John or Johannes want to handle this.
>
> *scratches head*
> are you advocating those rate cleanups for stable?

No, a few fixes are needed for stable (now 2.6.30) though. For example
the assert downgrade patch can be used but most likely that'll just be
doing something completely wrong, so we do need to ensure the dynamic
ps stuff does not trigger when scanning and I do consider that a
proper fix for stable. I forget when ps stuff when in.

The issue here is this *is* a bug not only for iwlwifi. iwlwifi
currently gets no warning because of a work around in the driver's
rate control algorithm as it is in stable. I haven't tried running
this band change with ath9k but I might bet here that we'll hit the
same assert, in that case (which is very likely) we'll need a proper
respective fix for stable for this issue as not all drivers have a
rate control algorithm work around for this condition.

 Luis

[ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[Luis R. Rodriguez]

On Wed, Jun 10, 2009 at 2:07 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Wed, 2009-06-10 at 14:04 -0700, Luis R. Rodriguez wrote:
>> On Wed, Jun 10, 2009 at 2:03 PM, reinette
>> chatre<reinette.chatre@intel.com> wrote:
>>
>> >> > This touches code targeted for removal in recent "mac80211: disconnect
>> >> > when user changes channel" patch.
>> >>
>> >> Heh I don't see that patch yet but if it exists that should fix this
>> >> too unless that patch didn't deauth/disassoc. Did you try with it
>> >> applied by any chance? I can't seem to find that patch on the list.
>> >
>> > That patch does seem to have same intention as yours. It is still RFC so
>> > I am not sure about its status. I did not test with it, but will do so.
>> > The patch can be found at
>> > http://marc.info/?l=linux-wireless&m=124458448631186&w=2
>>
>> Thanks yes, I see, yup I think that should fix it, we need a fix for
>> stable though. Not sure how John or Johannes want to handle this.
>
> *scratches head*
> are you advocating those rate cleanups for stable?

No, a few fixes are needed for stable (now 2.6.30) though. For example
the assert downgrade patch can be used but most likely that'll just be
doing something completely wrong, so we do need to ensure the dynamic
ps stuff does not trigger when scanning and I do consider that a
proper fix for stable. I forget when ps stuff when in.

The issue here is this *is* a bug not only for iwlwifi. iwlwifi
currently gets no warning because of a work around in the driver's
rate control algorithm as it is in stable. I haven't tried running
this band change with ath9k but I might bet here that we'll hit the
same assert, in that case (which is very likely) we'll need a proper
respective fix for stable for this issue as not all drivers have a
rate control algorithm work around for this condition.

 Luis

Re: [ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[Luis R. Rodriguez]

On Wed, Jun 10, 2009 at 3:42 PM, Luis R.
Rodriguez<lrodriguez@atheros.com> wrote:
> On Wed, Jun 10, 2009 at 2:07 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
>> On Wed, 2009-06-10 at 14:04 -0700, Luis R. Rodriguez wrote:
>>> On Wed, Jun 10, 2009 at 2:03 PM, reinette
>>> chatre<reinette.chatre@intel.com> wrote:
>>>
>>> >> > This touches code targeted for removal in recent "mac80211: disconnect
>>> >> > when user changes channel" patch.
>>> >>
>>> >> Heh I don't see that patch yet but if it exists that should fix this
>>> >> too unless that patch didn't deauth/disassoc. Did you try with it
>>> >> applied by any chance? I can't seem to find that patch on the list.
>>> >
>>> > That patch does seem to have same intention as yours. It is still RFC so
>>> > I am not sure about its status. I did not test with it, but will do so.
>>> > The patch can be found at
>>> > http://marc.info/?l=linux-wireless&m=124458448631186&w=2
>>>
>>> Thanks yes, I see, yup I think that should fix it, we need a fix for
>>> stable though. Not sure how John or Johannes want to handle this.
>>
>> *scratches head*
>> are you advocating those rate cleanups for stable?
>
> No, a few fixes are needed for stable (now 2.6.30) though. For example
> the assert downgrade patch can be used but most likely that'll just be
> doing something completely wrong, so we do need to ensure the dynamic
> ps stuff does not trigger when scanning and I do consider that a
> proper fix for stable. I forget when ps stuff when in.
>
> The issue here is this *is* a bug not only for iwlwifi. iwlwifi
> currently gets no warning because of a work around in the driver's
> rate control algorithm as it is in stable. I haven't tried running
> this band change with ath9k

Just to clarify -- I did run this with the patches I posted and I did
hit the warning, but I did not try this without the patches I posted.
Chances that will cause the kernel to commit suicide and oops.

> but I might bet here that we'll hit the
> same assert, in that case (which is very likely) we'll need a proper
> respective fix for stable for this issue as not all drivers have a
> rate control algorithm work around for this condition.
>
>  Luis
>

[ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[Luis R. Rodriguez]

On Wed, Jun 10, 2009 at 3:42 PM, Luis R.
Rodriguez<lrodriguez@atheros.com> wrote:
> On Wed, Jun 10, 2009 at 2:07 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
>> On Wed, 2009-06-10 at 14:04 -0700, Luis R. Rodriguez wrote:
>>> On Wed, Jun 10, 2009 at 2:03 PM, reinette
>>> chatre<reinette.chatre@intel.com> wrote:
>>>
>>> >> > This touches code targeted for removal in recent "mac80211: disconnect
>>> >> > when user changes channel" patch.
>>> >>
>>> >> Heh I don't see that patch yet but if it exists that should fix this
>>> >> too unless that patch didn't deauth/disassoc. Did you try with it
>>> >> applied by any chance? I can't seem to find that patch on the list.
>>> >
>>> > That patch does seem to have same intention as yours. It is still RFC so
>>> > I am not sure about its status. I did not test with it, but will do so.
>>> > The patch can be found at
>>> > http://marc.info/?l=linux-wireless&m=124458448631186&w=2
>>>
>>> Thanks yes, I see, yup I think that should fix it, we need a fix for
>>> stable though. Not sure how John or Johannes want to handle this.
>>
>> *scratches head*
>> are you advocating those rate cleanups for stable?
>
> No, a few fixes are needed for stable (now 2.6.30) though. For example
> the assert downgrade patch can be used but most likely that'll just be
> doing something completely wrong, so we do need to ensure the dynamic
> ps stuff does not trigger when scanning and I do consider that a
> proper fix for stable. I forget when ps stuff when in.
>
> The issue here is this *is* a bug not only for iwlwifi. iwlwifi
> currently gets no warning because of a work around in the driver's
> rate control algorithm as it is in stable. I haven't tried running
> this band change with ath9k

Just to clarify -- I did run this with the patches I posted and I did
hit the warning, but I did not try this without the patches I posted.
Chances that will cause the kernel to commit suicide and oops.

> but I might bet here that we'll hit the
> same assert, in that case (which is very likely) we'll need a proper
> respective fix for stable for this issue as not all drivers have a
> rate control algorithm work around for this condition.
>
> ?Luis
>

Re: [ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[Luis R. Rodriguez]

On Wed, Jun 10, 2009 at 3:44 PM, Luis R.
Rodriguez<lrodriguez@atheros.com> wrote:
> On Wed, Jun 10, 2009 at 3:42 PM, Luis R.
> Rodriguez<lrodriguez@atheros.com> wrote:
>> On Wed, Jun 10, 2009 at 2:07 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
>>> On Wed, 2009-06-10 at 14:04 -0700, Luis R. Rodriguez wrote:
>>>> On Wed, Jun 10, 2009 at 2:03 PM, reinette
>>>> chatre<reinette.chatre@intel.com> wrote:
>>>>
>>>> >> > This touches code targeted for removal in recent "mac80211: disconnect
>>>> >> > when user changes channel" patch.
>>>> >>
>>>> >> Heh I don't see that patch yet but if it exists that should fix this
>>>> >> too unless that patch didn't deauth/disassoc. Did you try with it
>>>> >> applied by any chance? I can't seem to find that patch on the list.
>>>> >
>>>> > That patch does seem to have same intention as yours. It is still RFC so
>>>> > I am not sure about its status. I did not test with it, but will do so.
>>>> > The patch can be found at
>>>> > http://marc.info/?l=linux-wireless&m=124458448631186&w=2
>>>>
>>>> Thanks yes, I see, yup I think that should fix it, we need a fix for
>>>> stable though. Not sure how John or Johannes want to handle this.
>>>
>>> *scratches head*
>>> are you advocating those rate cleanups for stable?
>>
>> No, a few fixes are needed for stable (now 2.6.30) though. For example
>> the assert downgrade patch can be used but most likely that'll just be
>> doing something completely wrong, so we do need to ensure the dynamic
>> ps stuff does not trigger when scanning and I do consider that a
>> proper fix for stable. I forget when ps stuff when in.
>>
>> The issue here is this *is* a bug not only for iwlwifi. iwlwifi
>> currently gets no warning because of a work around in the driver's
>> rate control algorithm as it is in stable. I haven't tried running
>> this band change with ath9k
>
> Just to clarify -- I did run this with the patches I posted and I did
> hit the warning, but I did not try this without the patches I posted.
> Chances that will cause the kernel to commit suicide and oops.

As expected I was able to reproduce the warning with atht5k and ath9k
on 2.6.30. I did not get a crash with ath9k though, which is good. But
the warning is still present.

Do we want to fix this for stable? If so is the patch I posted reasonable?

  Luis

[ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[Luis R. Rodriguez]

On Wed, Jun 10, 2009 at 3:44 PM, Luis R.
Rodriguez<lrodriguez@atheros.com> wrote:
> On Wed, Jun 10, 2009 at 3:42 PM, Luis R.
> Rodriguez<lrodriguez@atheros.com> wrote:
>> On Wed, Jun 10, 2009 at 2:07 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
>>> On Wed, 2009-06-10 at 14:04 -0700, Luis R. Rodriguez wrote:
>>>> On Wed, Jun 10, 2009 at 2:03 PM, reinette
>>>> chatre<reinette.chatre@intel.com> wrote:
>>>>
>>>> >> > This touches code targeted for removal in recent "mac80211: disconnect
>>>> >> > when user changes channel" patch.
>>>> >>
>>>> >> Heh I don't see that patch yet but if it exists that should fix this
>>>> >> too unless that patch didn't deauth/disassoc. Did you try with it
>>>> >> applied by any chance? I can't seem to find that patch on the list.
>>>> >
>>>> > That patch does seem to have same intention as yours. It is still RFC so
>>>> > I am not sure about its status. I did not test with it, but will do so.
>>>> > The patch can be found at
>>>> > http://marc.info/?l=linux-wireless&m=124458448631186&w=2
>>>>
>>>> Thanks yes, I see, yup I think that should fix it, we need a fix for
>>>> stable though. Not sure how John or Johannes want to handle this.
>>>
>>> *scratches head*
>>> are you advocating those rate cleanups for stable?
>>
>> No, a few fixes are needed for stable (now 2.6.30) though. For example
>> the assert downgrade patch can be used but most likely that'll just be
>> doing something completely wrong, so we do need to ensure the dynamic
>> ps stuff does not trigger when scanning and I do consider that a
>> proper fix for stable. I forget when ps stuff when in.
>>
>> The issue here is this *is* a bug not only for iwlwifi. iwlwifi
>> currently gets no warning because of a work around in the driver's
>> rate control algorithm as it is in stable. I haven't tried running
>> this band change with ath9k
>
> Just to clarify -- I did run this with the patches I posted and I did
> hit the warning, but I did not try this without the patches I posted.
> Chances that will cause the kernel to commit suicide and oops.

As expected I was able to reproduce the warning with atht5k and ath9k
on 2.6.30. I did not get a crash with ath9k though, which is good. But
the warning is still present.

Do we want to fix this for stable? If so is the patch I posted reasonable?

  Luis

Re: [ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 519 bytes --]

On Thu, 2009-06-11 at 12:04 -0700, Luis R. Rodriguez wrote:

> As expected I was able to reproduce the warning with atht5k and ath9k
> on 2.6.30. I did not get a crash with ath9k though, which is good. But
> the warning is still present.
> 
> Do we want to fix this for stable? If so is the patch I posted reasonable?

Which patch are you talking about now? This disassociate one? If yes, I
think I'd prefer to have mine so we don't diverge much and I can still
remember what's going on where :)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[Johannes Berg]

On Thu, 2009-06-11 at 12:04 -0700, Luis R. Rodriguez wrote:

> As expected I was able to reproduce the warning with atht5k and ath9k
> on 2.6.30. I did not get a crash with ath9k though, which is good. But
> the warning is still present.
> 
> Do we want to fix this for stable? If so is the patch I posted reasonable?

Which patch are you talking about now? This disassociate one? If yes, I
think I'd prefer to have mine so we don't diverge much and I can still
remember what's going on where :)

johannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20090611/fe9fab2d/attachment.pgp 

Re: [ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[reinette chatre]

Hi Luis,

On Thu, 2009-06-11 at 12:04 -0700, Luis R. Rodriguez wrote:
> On Wed, Jun 10, 2009 at 3:44 PM, Luis R.
> Rodriguez<lrodriguez@atheros.com> wrote:
> > On Wed, Jun 10, 2009 at 3:42 PM, Luis R.
> > Rodriguez<lrodriguez@atheros.com> wrote:
> >> On Wed, Jun 10, 2009 at 2:07 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
> >>> On Wed, 2009-06-10 at 14:04 -0700, Luis R. Rodriguez wrote:
> >>>> On Wed, Jun 10, 2009 at 2:03 PM, reinette
> >>>> chatre<reinette.chatre@intel.com> wrote:
> >>>>
> >>>> >> > This touches code targeted for removal in recent "mac80211: disconnect
> >>>> >> > when user changes channel" patch.
> >>>> >>
> >>>> >> Heh I don't see that patch yet but if it exists that should fix this
> >>>> >> too unless that patch didn't deauth/disassoc. Did you try with it
> >>>> >> applied by any chance? I can't seem to find that patch on the list.
> >>>> >
> >>>> > That patch does seem to have same intention as yours. It is still RFC so
> >>>> > I am not sure about its status. I did not test with it, but will do so.
> >>>> > The patch can be found at
> >>>> > http://marc.info/?l=linux-wireless&m=124458448631186&w=2
> >>>>
> >>>> Thanks yes, I see, yup I think that should fix it, we need a fix for
> >>>> stable though. Not sure how John or Johannes want to handle this.
> >>>
> >>> *scratches head*
> >>> are you advocating those rate cleanups for stable?
> >>
> >> No, a few fixes are needed for stable (now 2.6.30) though. For example
> >> the assert downgrade patch can be used but most likely that'll just be
> >> doing something completely wrong, so we do need to ensure the dynamic
> >> ps stuff does not trigger when scanning and I do consider that a
> >> proper fix for stable. I forget when ps stuff when in.
> >>
> >> The issue here is this *is* a bug not only for iwlwifi. iwlwifi
> >> currently gets no warning because of a work around in the driver's
> >> rate control algorithm as it is in stable. I haven't tried running
> >> this band change with ath9k
> >
> > Just to clarify -- I did run this with the patches I posted and I did
> > hit the warning, but I did not try this without the patches I posted.
> > Chances that will cause the kernel to commit suicide and oops.
> 
> As expected I was able to reproduce the warning with atht5k and ath9k
> on 2.6.30. I did not get a crash with ath9k though, which is good. But
> the warning is still present.
> 
> Do we want to fix this for stable? If so is the patch I posted reasonable?

I ran the steps to reproduce on a kernel that is the latest
wireless-testing + "mac80211: disconnect when user changes channel" +
"iwlwifi: remove rs_get_rate workaround". Unfortunately I still get the
rs_get_rate warning. 

Reinette

[ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[reinette chatre]

Hi Luis,

On Thu, 2009-06-11 at 12:04 -0700, Luis R. Rodriguez wrote:
> On Wed, Jun 10, 2009 at 3:44 PM, Luis R.
> Rodriguez<lrodriguez@atheros.com> wrote:
> > On Wed, Jun 10, 2009 at 3:42 PM, Luis R.
> > Rodriguez<lrodriguez@atheros.com> wrote:
> >> On Wed, Jun 10, 2009 at 2:07 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
> >>> On Wed, 2009-06-10 at 14:04 -0700, Luis R. Rodriguez wrote:
> >>>> On Wed, Jun 10, 2009 at 2:03 PM, reinette
> >>>> chatre<reinette.chatre@intel.com> wrote:
> >>>>
> >>>> >> > This touches code targeted for removal in recent "mac80211: disconnect
> >>>> >> > when user changes channel" patch.
> >>>> >>
> >>>> >> Heh I don't see that patch yet but if it exists that should fix this
> >>>> >> too unless that patch didn't deauth/disassoc. Did you try with it
> >>>> >> applied by any chance? I can't seem to find that patch on the list.
> >>>> >
> >>>> > That patch does seem to have same intention as yours. It is still RFC so
> >>>> > I am not sure about its status. I did not test with it, but will do so.
> >>>> > The patch can be found at
> >>>> > http://marc.info/?l=linux-wireless&m=124458448631186&w=2
> >>>>
> >>>> Thanks yes, I see, yup I think that should fix it, we need a fix for
> >>>> stable though. Not sure how John or Johannes want to handle this.
> >>>
> >>> *scratches head*
> >>> are you advocating those rate cleanups for stable?
> >>
> >> No, a few fixes are needed for stable (now 2.6.30) though. For example
> >> the assert downgrade patch can be used but most likely that'll just be
> >> doing something completely wrong, so we do need to ensure the dynamic
> >> ps stuff does not trigger when scanning and I do consider that a
> >> proper fix for stable. I forget when ps stuff when in.
> >>
> >> The issue here is this *is* a bug not only for iwlwifi. iwlwifi
> >> currently gets no warning because of a work around in the driver's
> >> rate control algorithm as it is in stable. I haven't tried running
> >> this band change with ath9k
> >
> > Just to clarify -- I did run this with the patches I posted and I did
> > hit the warning, but I did not try this without the patches I posted.
> > Chances that will cause the kernel to commit suicide and oops.
> 
> As expected I was able to reproduce the warning with atht5k and ath9k
> on 2.6.30. I did not get a crash with ath9k though, which is good. But
> the warning is still present.
> 
> Do we want to fix this for stable? If so is the patch I posted reasonable?

I ran the steps to reproduce on a kernel that is the latest
wireless-testing + "mac80211: disconnect when user changes channel" +
"iwlwifi: remove rs_get_rate workaround". Unfortunately I still get the
rs_get_rate warning. 

Reinette

Re: [ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[Luis R. Rodriguez]

On Thu, Jun 11, 2009 at 12:10 PM, Johannes
Berg<johannes@sipsolutions.net> wrote:
> On Thu, 2009-06-11 at 12:04 -0700, Luis R. Rodriguez wrote:
>
>> As expected I was able to reproduce the warning with atht5k and ath9k
>> on 2.6.30. I did not get a crash with ath9k though, which is good. But
>> the warning is still present.
>>
>> Do we want to fix this for stable? If so is the patch I posted reasonable?
>
> Which patch are you talking about now? This disassociate one?

Yes. But I also think this is stable candidates:

mac80211: disable moving between PS modes during scan

This patch would fix the assert we hit in ath9k.

The patch "mac80211: disable PS while probing AP" may also be a stable
candidate but I am not aware of open issues which it fixes so not
sure.

> If yes, I
> think I'd prefer to have mine so we don't diverge much and I can still
> remember what's going on where :)

Works with me -- it seems its missing something as per reinette's testing.

  Luis

[ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[Luis R. Rodriguez]

On Thu, Jun 11, 2009 at 12:10 PM, Johannes
Berg<johannes@sipsolutions.net> wrote:
> On Thu, 2009-06-11 at 12:04 -0700, Luis R. Rodriguez wrote:
>
>> As expected I was able to reproduce the warning with atht5k and ath9k
>> on 2.6.30. I did not get a crash with ath9k though, which is good. But
>> the warning is still present.
>>
>> Do we want to fix this for stable? If so is the patch I posted reasonable?
>
> Which patch are you talking about now? This disassociate one?

Yes. But I also think this is stable candidates:

mac80211: disable moving between PS modes during scan

This patch would fix the assert we hit in ath9k.

The patch "mac80211: disable PS while probing AP" may also be a stable
candidate but I am not aware of open issues which it fixes so not
sure.

> If yes, I
> think I'd prefer to have mine so we don't diverge much and I can still
> remember what's going on where :)

Works with me -- it seems its missing something as per reinette's testing.

  Luis

Re: [ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[John W. Linville]

On Thu, Jun 11, 2009 at 01:50:07PM -0700, reinette chatre wrote:

> I ran the steps to reproduce on a kernel that is the latest
> wireless-testing + "mac80211: disconnect when user changes channel" +
> "iwlwifi: remove rs_get_rate workaround". Unfortunately I still get the
> rs_get_rate warning. 

Should I merge the ath9k rate series w/o "iwlwifi: remove rs_get_rate
workaround"?

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

[ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[John W. Linville]

On Thu, Jun 11, 2009 at 01:50:07PM -0700, reinette chatre wrote:

> I ran the steps to reproduce on a kernel that is the latest
> wireless-testing + "mac80211: disconnect when user changes channel" +
> "iwlwifi: remove rs_get_rate workaround". Unfortunately I still get the
> rs_get_rate warning. 

Should I merge the ath9k rate series w/o "iwlwifi: remove rs_get_rate
workaround"?

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.

Re: [ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[reinette chatre]

Hi John,

On Thu, 2009-06-18 at 08:01 -0700, John W. Linville wrote:
> On Thu, Jun 11, 2009 at 01:50:07PM -0700, reinette chatre wrote:
> 
> > I ran the steps to reproduce on a kernel that is the latest
> > wireless-testing + "mac80211: disconnect when user changes channel" +
> > "iwlwifi: remove rs_get_rate workaround". Unfortunately I still get the
> > rs_get_rate warning. 
> 
> Should I merge the ath9k rate series w/o "iwlwifi: remove rs_get_rate
> workaround"?

The later patch "mac80211: add helper for management / no-ack frame rate
decision" also touches iwlwifi and assumes that "iwlwifi: remove
rs_get_rate workaround" has been applied. 

I do not know if Luis would want that patch to go in because the warning
we get may not be specific to iwlwifi. If you do want that to go in then
please remove the iwlwifi bits.

Reinette

[ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[reinette chatre]

Hi John,

On Thu, 2009-06-18 at 08:01 -0700, John W. Linville wrote:
> On Thu, Jun 11, 2009 at 01:50:07PM -0700, reinette chatre wrote:
> 
> > I ran the steps to reproduce on a kernel that is the latest
> > wireless-testing + "mac80211: disconnect when user changes channel" +
> > "iwlwifi: remove rs_get_rate workaround". Unfortunately I still get the
> > rs_get_rate warning. 
> 
> Should I merge the ath9k rate series w/o "iwlwifi: remove rs_get_rate
> workaround"?

The later patch "mac80211: add helper for management / no-ack frame rate
decision" also touches iwlwifi and assumes that "iwlwifi: remove
rs_get_rate workaround" has been applied. 

I do not know if Luis would want that patch to go in because the warning
we get may not be specific to iwlwifi. If you do want that to go in then
please remove the iwlwifi bits.

Reinette

Re: [ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[Luis R. Rodriguez]

On Thu, Jun 18, 2009 at 08:47:01AM -0700, reinette chatre wrote:
> Hi John,
> 
> On Thu, 2009-06-18 at 08:01 -0700, John W. Linville wrote:
> > On Thu, Jun 11, 2009 at 01:50:07PM -0700, reinette chatre wrote:
> >
> > > I ran the steps to reproduce on a kernel that is the latest
> > > wireless-testing + "mac80211: disconnect when user changes channel" +
> > > "iwlwifi: remove rs_get_rate workaround". Unfortunately I still get the
> > > rs_get_rate warning.
> >
> > Should I merge the ath9k rate series w/o "iwlwifi: remove rs_get_rate
> > workaround"?
> 
> The later patch "mac80211: add helper for management / no-ack frame rate
> decision" also touches iwlwifi and assumes that "iwlwifi: remove
> rs_get_rate workaround" has been applied.
> 
> I do not know if Luis would want that patch to go in because the warning
> we get may not be specific to iwlwifi. If you do want that to go in then
> please remove the iwlwifi bits.

I don't believe the warning you got were iwlwifi specific, I confirmed it and
I was able to reproduce with ath9k and I also sent a patch to correct it. I'd hate
to see a work around be kept for them and the issue not addressed properly,
which is what this has been trying to address.

Mind you the patch I sent conflicts with johills patch but I figured we can
just implement a proper patch to fix that warning afterwards.

  Luis

[ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[Luis R. Rodriguez]

On Thu, Jun 18, 2009 at 08:47:01AM -0700, reinette chatre wrote:
> Hi John,
> 
> On Thu, 2009-06-18 at 08:01 -0700, John W. Linville wrote:
> > On Thu, Jun 11, 2009 at 01:50:07PM -0700, reinette chatre wrote:
> >
> > > I ran the steps to reproduce on a kernel that is the latest
> > > wireless-testing + "mac80211: disconnect when user changes channel" +
> > > "iwlwifi: remove rs_get_rate workaround". Unfortunately I still get the
> > > rs_get_rate warning.
> >
> > Should I merge the ath9k rate series w/o "iwlwifi: remove rs_get_rate
> > workaround"?
> 
> The later patch "mac80211: add helper for management / no-ack frame rate
> decision" also touches iwlwifi and assumes that "iwlwifi: remove
> rs_get_rate workaround" has been applied.
> 
> I do not know if Luis would want that patch to go in because the warning
> we get may not be specific to iwlwifi. If you do want that to go in then
> please remove the iwlwifi bits.

I don't believe the warning you got were iwlwifi specific, I confirmed it and
I was able to reproduce with ath9k and I also sent a patch to correct it. I'd hate
to see a work around be kept for them and the issue not addressed properly,
which is what this has been trying to address.

Mind you the patch I sent conflicts with johills patch but I figured we can
just implement a proper patch to fix that warning afterwards.

  Luis

Re: [ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[Luis R. Rodriguez]

On Thu, Jun 18, 2009 at 11:44 AM, reinette
chatre<reinette.chatre@intel.com> wrote:
> Hi Luis,
>
> On Thu, 2009-06-18 at 11:28 -0700, Luis R. Rodriguez wrote:
>> On Thu, Jun 18, 2009 at 08:47:01AM -0700, reinette chatre wrote:
>> > Hi John,
>> >
>> > On Thu, 2009-06-18 at 08:01 -0700, John W. Linville wrote:
>> > > On Thu, Jun 11, 2009 at 01:50:07PM -0700, reinette chatre wrote:
>> > >
>> > > > I ran the steps to reproduce on a kernel that is the latest
>> > > > wireless-testing + "mac80211: disconnect when user changes channel" +
>> > > > "iwlwifi: remove rs_get_rate workaround". Unfortunately I still get the
>> > > > rs_get_rate warning.
>> > >
>> > > Should I merge the ath9k rate series w/o "iwlwifi: remove rs_get_rate
>> > > workaround"?
>> >
>> > The later patch "mac80211: add helper for management / no-ack frame rate
>> > decision" also touches iwlwifi and assumes that "iwlwifi: remove
>> > rs_get_rate workaround" has been applied.
>> >
>> > I do not know if Luis would want that patch to go in because the warning
>> > we get may not be specific to iwlwifi. If you do want that to go in then
>> > please remove the iwlwifi bits.
>>
>> I don't believe the warning you got were iwlwifi specific, I confirmed it and
>> I was able to reproduce with ath9k and I also sent a patch to correct it. I'd hate
>> to see a work around be kept for them and the issue not addressed properly,
>> which is what this has been trying to address.
>
> I assumed that your fix had the same intention as the patch from
> Johannes that I tested. This did not resolve the problem.

It seems like it didn't.

  Luis

[ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[Luis R. Rodriguez]

On Thu, Jun 18, 2009 at 11:44 AM, reinette
chatre<reinette.chatre@intel.com> wrote:
> Hi Luis,
>
> On Thu, 2009-06-18 at 11:28 -0700, Luis R. Rodriguez wrote:
>> On Thu, Jun 18, 2009 at 08:47:01AM -0700, reinette chatre wrote:
>> > Hi John,
>> >
>> > On Thu, 2009-06-18 at 08:01 -0700, John W. Linville wrote:
>> > > On Thu, Jun 11, 2009 at 01:50:07PM -0700, reinette chatre wrote:
>> > >
>> > > > I ran the steps to reproduce on a kernel that is the latest
>> > > > wireless-testing + "mac80211: disconnect when user changes channel" +
>> > > > "iwlwifi: remove rs_get_rate workaround". Unfortunately I still get the
>> > > > rs_get_rate warning.
>> > >
>> > > Should I merge the ath9k rate series w/o "iwlwifi: remove rs_get_rate
>> > > workaround"?
>> >
>> > The later patch "mac80211: add helper for management / no-ack frame rate
>> > decision" also touches iwlwifi and assumes that "iwlwifi: remove
>> > rs_get_rate workaround" has been applied.
>> >
>> > I do not know if Luis would want that patch to go in because the warning
>> > we get may not be specific to iwlwifi. If you do want that to go in then
>> > please remove the iwlwifi bits.
>>
>> I don't believe the warning you got were iwlwifi specific, I confirmed it and
>> I was able to reproduce with ath9k and I also sent a patch to correct it. I'd hate
>> to see a work around be kept for them and the issue not addressed properly,
>> which is what this has been trying to address.
>
> I assumed that your fix had the same intention as the patch from
> Johannes that I tested. This did not resolve the problem.

It seems like it didn't.

  Luis

Re: [ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[reinette chatre]

Hi Luis,

On Thu, 2009-06-18 at 11:28 -0700, Luis R. Rodriguez wrote:
> On Thu, Jun 18, 2009 at 08:47:01AM -0700, reinette chatre wrote:
> > Hi John,
> > 
> > On Thu, 2009-06-18 at 08:01 -0700, John W. Linville wrote:
> > > On Thu, Jun 11, 2009 at 01:50:07PM -0700, reinette chatre wrote:
> > >
> > > > I ran the steps to reproduce on a kernel that is the latest
> > > > wireless-testing + "mac80211: disconnect when user changes channel" +
> > > > "iwlwifi: remove rs_get_rate workaround". Unfortunately I still get the
> > > > rs_get_rate warning.
> > >
> > > Should I merge the ath9k rate series w/o "iwlwifi: remove rs_get_rate
> > > workaround"?
> > 
> > The later patch "mac80211: add helper for management / no-ack frame rate
> > decision" also touches iwlwifi and assumes that "iwlwifi: remove
> > rs_get_rate workaround" has been applied.
> > 
> > I do not know if Luis would want that patch to go in because the warning
> > we get may not be specific to iwlwifi. If you do want that to go in then
> > please remove the iwlwifi bits.
> 
> I don't believe the warning you got were iwlwifi specific, I confirmed it and
> I was able to reproduce with ath9k and I also sent a patch to correct it. I'd hate
> to see a work around be kept for them and the issue not addressed properly,
> which is what this has been trying to address.

I assumed that your fix had the same intention as the patch from
Johannes that I tested. This did not resolve the problem. 

> 
> Mind you the patch I sent conflicts with johills patch but I figured we can
> just implement a proper patch to fix that warning afterwards.



Reinette

[ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning

[reinette chatre]

Hi Luis,

On Thu, 2009-06-18 at 11:28 -0700, Luis R. Rodriguez wrote:
> On Thu, Jun 18, 2009 at 08:47:01AM -0700, reinette chatre wrote:
> > Hi John,
> > 
> > On Thu, 2009-06-18 at 08:01 -0700, John W. Linville wrote:
> > > On Thu, Jun 11, 2009 at 01:50:07PM -0700, reinette chatre wrote:
> > >
> > > > I ran the steps to reproduce on a kernel that is the latest
> > > > wireless-testing + "mac80211: disconnect when user changes channel" +
> > > > "iwlwifi: remove rs_get_rate workaround". Unfortunately I still get the
> > > > rs_get_rate warning.
> > >
> > > Should I merge the ath9k rate series w/o "iwlwifi: remove rs_get_rate
> > > workaround"?
> > 
> > The later patch "mac80211: add helper for management / no-ack frame rate
> > decision" also touches iwlwifi and assumes that "iwlwifi: remove
> > rs_get_rate workaround" has been applied.
> > 
> > I do not know if Luis would want that patch to go in because the warning
> > we get may not be specific to iwlwifi. If you do want that to go in then
> > please remove the iwlwifi bits.
> 
> I don't believe the warning you got were iwlwifi specific, I confirmed it and
> I was able to reproduce with ath9k and I also sent a patch to correct it. I'd hate
> to see a work around be kept for them and the issue not addressed properly,
> which is what this has been trying to address.

I assumed that your fix had the same intention as the patch from
Johannes that I tested. This did not resolve the problem. 

> 
> Mind you the patch I sent conflicts with johills patch but I figured we can
> just implement a proper patch to fix that warning afterwards.



Reinette