* [PATCH] mac80211: disassociate when switching bands and not scanning @ 2009-06-10 20:35 Luis R. Rodriguez 2009-06-10 20:49 ` reinette chatre 0 siblings, 1 reply; 18+ messages in thread From: Luis R. Rodriguez @ 2009-06-10 20:35 UTC (permalink / raw) To: linville, johannes, j Cc: linux-wireless, ath9k-devel, Luis R. Rodriguez, Reinette Chatre, Zhu Yi, Mohamed Abbas, ipw3945-devel 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 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH] mac80211: disassociate when switching bands and not scanning 2009-06-10 20:35 [PATCH] mac80211: disassociate when switching bands and not scanning Luis R. Rodriguez @ 2009-06-10 20:49 ` reinette chatre 2009-06-10 20:49 ` Luis R. Rodriguez 0 siblings, 1 reply; 18+ messages in thread From: reinette chatre @ 2009-06-10 20:49 UTC (permalink / raw) To: Luis R. Rodriguez Cc: linville@tuxdriver.com, johannes@sipsolutions.net, j@w1.fi, linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org, Zhu, Yi, Abbas, Mohamed, ipw3945-devel@lists.sourceforge.net 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] mac80211: disassociate when switching bands and not scanning 2009-06-10 20:49 ` reinette chatre @ 2009-06-10 20:49 ` Luis R. Rodriguez 2009-06-10 21:03 ` reinette chatre 0 siblings, 1 reply; 18+ messages in thread From: Luis R. Rodriguez @ 2009-06-10 20:49 UTC (permalink / raw) To: reinette chatre Cc: linville@tuxdriver.com, johannes@sipsolutions.net, j@w1.fi, linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org, Zhu, Yi, Abbas, Mohamed, ipw3945-devel@lists.sourceforge.net 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] mac80211: disassociate when switching bands and not scanning 2009-06-10 20:49 ` Luis R. Rodriguez @ 2009-06-10 21:03 ` reinette chatre 2009-06-10 21:04 ` [ath9k-devel] " Luis R. Rodriguez 2009-06-10 21:06 ` Johannes Berg 0 siblings, 2 replies; 18+ messages in thread From: reinette chatre @ 2009-06-10 21:03 UTC (permalink / raw) To: Luis R. Rodriguez Cc: linville@tuxdriver.com, johannes@sipsolutions.net, j@w1.fi, linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org, Zhu, Yi, Abbas, Mohamed, ipw3945-devel@lists.sourceforge.net 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning 2009-06-10 21:03 ` reinette chatre @ 2009-06-10 21:04 ` Luis R. Rodriguez 2009-06-10 21:07 ` Johannes Berg 2009-06-10 21:06 ` Johannes Berg 1 sibling, 1 reply; 18+ messages in thread From: Luis R. Rodriguez @ 2009-06-10 21:04 UTC (permalink / raw) To: reinette chatre Cc: Zhu, Yi, j@w1.fi, linux-wireless@vger.kernel.org, linville@tuxdriver.com, ipw3945-devel@lists.sourceforge.net, Abbas, Mohamed, ath9k-devel@lists.ath9k.org, johannes@sipsolutions.net 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning 2009-06-10 21:04 ` [ath9k-devel] " Luis R. Rodriguez @ 2009-06-10 21:07 ` Johannes Berg 2009-06-10 22:42 ` Luis R. Rodriguez 0 siblings, 1 reply; 18+ messages in thread From: Johannes Berg @ 2009-06-10 21:07 UTC (permalink / raw) To: Luis R. Rodriguez Cc: reinette chatre, Zhu, Yi, j@w1.fi, linux-wireless@vger.kernel.org, linville@tuxdriver.com, ipw3945-devel@lists.sourceforge.net, Abbas, Mohamed, ath9k-devel@lists.ath9k.org [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning 2009-06-10 21:07 ` Johannes Berg @ 2009-06-10 22:42 ` Luis R. Rodriguez 2009-06-10 22:44 ` Luis R. Rodriguez 0 siblings, 1 reply; 18+ messages in thread From: Luis R. Rodriguez @ 2009-06-10 22:42 UTC (permalink / raw) To: Johannes Berg, Kalle Valo Cc: reinette chatre, Zhu, Yi, j@w1.fi, linux-wireless@vger.kernel.org, linville@tuxdriver.com, ipw3945-devel@lists.sourceforge.net, Abbas, Mohamed, ath9k-devel@lists.ath9k.org 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning 2009-06-10 22:42 ` Luis R. Rodriguez @ 2009-06-10 22:44 ` Luis R. Rodriguez 2009-06-11 19:04 ` Luis R. Rodriguez 0 siblings, 1 reply; 18+ messages in thread From: Luis R. Rodriguez @ 2009-06-10 22:44 UTC (permalink / raw) To: Johannes Berg, Kalle Valo Cc: reinette chatre, Zhu, Yi, j@w1.fi, linux-wireless@vger.kernel.org, linville@tuxdriver.com, ipw3945-devel@lists.sourceforge.net, Abbas, Mohamed, ath9k-devel@lists.ath9k.org 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 > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning 2009-06-10 22:44 ` Luis R. Rodriguez @ 2009-06-11 19:04 ` Luis R. Rodriguez 2009-06-11 19:10 ` Johannes Berg 2009-06-11 20:50 ` reinette chatre 0 siblings, 2 replies; 18+ messages in thread From: Luis R. Rodriguez @ 2009-06-11 19:04 UTC (permalink / raw) To: Johannes Berg, Kalle Valo Cc: reinette chatre, Zhu, Yi, j@w1.fi, linux-wireless@vger.kernel.org, linville@tuxdriver.com, ipw3945-devel@lists.sourceforge.net, Abbas, Mohamed, ath9k-devel@lists.ath9k.org 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning 2009-06-11 19:04 ` Luis R. Rodriguez @ 2009-06-11 19:10 ` Johannes Berg 2009-06-11 20:54 ` Luis R. Rodriguez 2009-06-11 20:50 ` reinette chatre 1 sibling, 1 reply; 18+ messages in thread From: Johannes Berg @ 2009-06-11 19:10 UTC (permalink / raw) To: Luis R. Rodriguez Cc: Kalle Valo, reinette chatre, Zhu, Yi, j@w1.fi, linux-wireless@vger.kernel.org, linville@tuxdriver.com, ipw3945-devel@lists.sourceforge.net, Abbas, Mohamed, ath9k-devel@lists.ath9k.org [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning 2009-06-11 19:10 ` Johannes Berg @ 2009-06-11 20:54 ` Luis R. Rodriguez 0 siblings, 0 replies; 18+ messages in thread From: Luis R. Rodriguez @ 2009-06-11 20:54 UTC (permalink / raw) To: Johannes Berg Cc: Kalle Valo, reinette chatre, Zhu, Yi, j@w1.fi, linux-wireless@vger.kernel.org, linville@tuxdriver.com, ipw3945-devel@lists.sourceforge.net, Abbas, Mohamed, ath9k-devel@lists.ath9k.org 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning 2009-06-11 19:04 ` Luis R. Rodriguez 2009-06-11 19:10 ` Johannes Berg @ 2009-06-11 20:50 ` reinette chatre 2009-06-18 15:01 ` John W. Linville 1 sibling, 1 reply; 18+ messages in thread From: reinette chatre @ 2009-06-11 20:50 UTC (permalink / raw) To: Luis R. Rodriguez Cc: Johannes Berg, Kalle Valo, Zhu, Yi, j@w1.fi, linux-wireless@vger.kernel.org, linville@tuxdriver.com, ipw3945-devel@lists.sourceforge.net, Abbas, Mohamed, ath9k-devel@lists.ath9k.org 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning 2009-06-11 20:50 ` reinette chatre @ 2009-06-18 15:01 ` John W. Linville 2009-06-18 15:47 ` reinette chatre 0 siblings, 1 reply; 18+ messages in thread From: John W. Linville @ 2009-06-18 15:01 UTC (permalink / raw) To: reinette chatre Cc: Luis R. Rodriguez, Johannes Berg, Kalle Valo, Zhu, Yi, j@w1.fi, linux-wireless@vger.kernel.org, ipw3945-devel@lists.sourceforge.net, Abbas, Mohamed, ath9k-devel@lists.ath9k.org 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning 2009-06-18 15:01 ` John W. Linville @ 2009-06-18 15:47 ` reinette chatre 2009-06-18 18:28 ` Luis R. Rodriguez 0 siblings, 1 reply; 18+ messages in thread From: reinette chatre @ 2009-06-18 15:47 UTC (permalink / raw) To: John W. Linville Cc: Luis R. Rodriguez, Johannes Berg, Kalle Valo, Zhu, Yi, j@w1.fi, linux-wireless@vger.kernel.org, ipw3945-devel@lists.sourceforge.net, Abbas, Mohamed, ath9k-devel@lists.ath9k.org 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning 2009-06-18 15:47 ` reinette chatre @ 2009-06-18 18:28 ` Luis R. Rodriguez 2009-06-18 18:44 ` reinette chatre 0 siblings, 1 reply; 18+ messages in thread From: Luis R. Rodriguez @ 2009-06-18 18:28 UTC (permalink / raw) To: reinette chatre Cc: John W. Linville, Luis Rodriguez, Johannes Berg, Kalle Valo, Zhu, Yi, j@w1.fi, linux-wireless@vger.kernel.org, ipw3945-devel@lists.sourceforge.net, Abbas, Mohamed, ath9k-devel@lists.ath9k.org 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning 2009-06-18 18:28 ` Luis R. Rodriguez @ 2009-06-18 18:44 ` reinette chatre 2009-06-18 18:42 ` Luis R. Rodriguez 0 siblings, 1 reply; 18+ messages in thread From: reinette chatre @ 2009-06-18 18:44 UTC (permalink / raw) To: Luis R. Rodriguez Cc: John W. Linville, Luis Rodriguez, Johannes Berg, Kalle Valo, Zhu, Yi, j@w1.fi, linux-wireless@vger.kernel.org, ipw3945-devel@lists.sourceforge.net, Abbas, Mohamed, ath9k-devel@lists.ath9k.org 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ath9k-devel] [PATCH] mac80211: disassociate when switching bands and not scanning 2009-06-18 18:44 ` reinette chatre @ 2009-06-18 18:42 ` Luis R. Rodriguez 0 siblings, 0 replies; 18+ messages in thread From: Luis R. Rodriguez @ 2009-06-18 18:42 UTC (permalink / raw) To: reinette chatre Cc: John W. Linville, Luis Rodriguez, Johannes Berg, Kalle Valo, Zhu, Yi, j@w1.fi, linux-wireless@vger.kernel.org, ipw3945-devel@lists.sourceforge.net, Abbas, Mohamed, ath9k-devel@lists.ath9k.org 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] mac80211: disassociate when switching bands and not scanning 2009-06-10 21:03 ` reinette chatre 2009-06-10 21:04 ` [ath9k-devel] " Luis R. Rodriguez @ 2009-06-10 21:06 ` Johannes Berg 1 sibling, 0 replies; 18+ messages in thread From: Johannes Berg @ 2009-06-10 21:06 UTC (permalink / raw) To: reinette chatre Cc: Luis R. Rodriguez, linville@tuxdriver.com, j@w1.fi, linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org, Zhu, Yi, Abbas, Mohamed, ipw3945-devel@lists.sourceforge.net [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2009-06-18 18:42 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-06-10 20:35 [PATCH] mac80211: disassociate when switching bands and not scanning Luis R. Rodriguez 2009-06-10 20:49 ` reinette chatre 2009-06-10 20:49 ` Luis R. Rodriguez 2009-06-10 21:03 ` reinette chatre 2009-06-10 21:04 ` [ath9k-devel] " Luis R. Rodriguez 2009-06-10 21:07 ` Johannes Berg 2009-06-10 22:42 ` Luis R. Rodriguez 2009-06-10 22:44 ` Luis R. Rodriguez 2009-06-11 19:04 ` Luis R. Rodriguez 2009-06-11 19:10 ` Johannes Berg 2009-06-11 20:54 ` Luis R. Rodriguez 2009-06-11 20:50 ` reinette chatre 2009-06-18 15:01 ` John W. Linville 2009-06-18 15:47 ` reinette chatre 2009-06-18 18:28 ` Luis R. Rodriguez 2009-06-18 18:44 ` reinette chatre 2009-06-18 18:42 ` Luis R. Rodriguez 2009-06-10 21:06 ` Johannes Berg
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).