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 <[email protected]>
Cc: Zhu Yi <[email protected]>
Cc: Mohamed Abbas <[email protected]>
Cc: [email protected]
Signed-off-by: Luis R. Rodriguez <[email protected]>
---
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
On Thu, Jun 11, 2009 at 12:10 PM, Johannes
Berg<[email protected]> 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
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
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<[email protected]> 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 <[email protected]>
> >> Cc: Zhu Yi <[email protected]>
> >> Cc: Mohamed Abbas <[email protected]>
> >> Cc: [email protected]
> >> Signed-off-by: Luis R. Rodriguez <[email protected]>
> >> ---
> >> 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
On Wed, Jun 10, 2009 at 2:03 PM, reinette
chatre<[email protected]> 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
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
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<[email protected]> wrote:
> > On Wed, Jun 10, 2009 at 3:42 PM, Luis R.
> > Rodriguez<[email protected]> wrote:
> >> On Wed, Jun 10, 2009 at 2:07 PM, Johannes Berg<[email protected]> 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<[email protected]> 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
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
On Wed, Jun 10, 2009 at 2:07 PM, Johannes Berg<[email protected]> 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<[email protected]> 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
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 <[email protected]>
> Cc: Zhu Yi <[email protected]>
> Cc: Mohamed Abbas <[email protected]>
> Cc: [email protected]
> Signed-off-by: Luis R. Rodriguez <[email protected]>
> ---
> 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
On Wed, 2009-06-10 at 14:04 -0700, Luis R. Rodriguez wrote:
> On Wed, Jun 10, 2009 at 2:03 PM, reinette
> chatre<[email protected]> 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
On Wed, Jun 10, 2009 at 3:44 PM, Luis R.
Rodriguez<[email protected]> wrote:
> On Wed, Jun 10, 2009 at 3:42 PM, Luis R.
> Rodriguez<[email protected]> wrote:
>> On Wed, Jun 10, 2009 at 2:07 PM, Johannes Berg<[email protected]> 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<[email protected]> 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
On Wed, Jun 10, 2009 at 3:42 PM, Luis R.
Rodriguez<[email protected]> wrote:
> On Wed, Jun 10, 2009 at 2:07 PM, Johannes Berg<[email protected]> 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<[email protected]> 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
>
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
On Wed, Jun 10, 2009 at 1:49 PM, reinette
chatre<[email protected]> 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 <[email protected]>
>> Cc: Zhu Yi <[email protected]>
>> Cc: Mohamed Abbas <[email protected]>
>> Cc: [email protected]
>> Signed-off-by: Luis R. Rodriguez <[email protected]>
>> ---
>> 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
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
[email protected] might be all we have. Be ready.
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
On Thu, Jun 18, 2009 at 11:44 AM, reinette
chatre<[email protected]> 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