Probe Timeouts with 47afbaf5af9454a7a1a64591e20cbfcc27ca67a8

Probe Timeouts with 47afbaf5af9454a7a1a64591e20cbfcc27ca67a8

[Parag Warudkar]

Hi Johannes,

Niel bisected the probe timeouts with iwlagn to your commit
47afbaf5af9454a7a1a64591e20cbfcc27ca67a8 .  I too was getting probe
timeouts but with ath9k and tried reverting the above commit which
made the problem disappear.

It is not yet reverted from mainline and compat-wireless - just wanted
to bring it to your notice that it impacts both iwlagn and ath9k.

Thanks
Parag

Re: Probe Timeouts with 47afbaf5af9454a7a1a64591e20cbfcc27ca67a8

[Johannes Berg]

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

Parag,

> Niel bisected the probe timeouts with iwlagn to your commit
> 47afbaf5af9454a7a1a64591e20cbfcc27ca67a8 .  I too was getting probe
> timeouts but with ath9k and tried reverting the above commit which
> made the problem disappear.

I know. There's a bug in that commit.

> It is not yet reverted from mainline and compat-wireless - just wanted
> to bring it to your notice that it impacts both iwlagn and ath9k.

I'm not sure what makes you think that it even _should_ be reverted.
Just to make that clear: it should _not_ be reverted. How did you check
that it isn't reverted in compat-wireless anyway? Must have been by code
inspection since if you had made an attempt to verify that the code in
there works, you would have found that indeed there's no reason to
revert this commit since the fix for it went in, and is literally a
single line.

johannes

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

Re: Probe Timeouts with 47afbaf5af9454a7a1a64591e20cbfcc27ca67a8

[Parag Warudkar]

On 5/1/09, Johannes Berg <johannes@sipsolutions.net> wrote:

> I'm not sure what makes you think that it even _should_ be reverted.
>  Just to make that clear: it should _not_ be reverted. How did you check
>  that it isn't reverted in compat-wireless anyway? Must have been by code
>  inspection since if you had made an attempt to verify that the code in
>  there works, you would have found that indeed there's no reason to
>  revert this commit since the fix for it went in, and is literally a
>  single line.

Well I have the 04-29 compat-wireless tree and it does not work - just
like mainline I get timeouts. I have not been able to download later
versions - clicking on the URL does nothing for some reason. (Besides
I do not normally track compat-wireless.)

So since I wasn't able to use the mainline for 2-3 days and I could
not find any regression/bug where it was mentioned the bug was fixed
in compat-wireless I thought it might be better to revert it until a
fix appears. (BTW, I just did a pull on Linus tree and the fix hasn't
made it there).

So unless I am being too unreasonable here I think reverting *was*
(not *is* of course now) the right thing to do based if nothing else,
on the fact that ath9k and iwlagn were unusable for 2+ days and not
everyone can be expected to run compat-wireless daily builds.

Any way now that we know there is a fix - I will wait for it to appear
in mainline.

Parag

Re: Probe Timeouts with 47afbaf5af9454a7a1a64591e20cbfcc27ca67a8

[Linus Torvalds]

On Fri, 1 May 2009, Parag Warudkar wrote:

> On 5/1/09, Johannes Berg <johannes@sipsolutions.net> wrote:
> 
> > I'm not sure what makes you think that it even _should_ be reverted.
> >  Just to make that clear: it should _not_ be reverted. How did you check
> >  that it isn't reverted in compat-wireless anyway? Must have been by code
> >  inspection since if you had made an attempt to verify that the code in
> >  there works, you would have found that indeed there's no reason to
> >  revert this commit since the fix for it went in, and is literally a
> >  single line.
> 
> Well I have the 04-29 compat-wireless tree and it does not work - just
> like mainline I get timeouts. I have not been able to download later
> versions - clicking on the URL does nothing for some reason. (Besides
> I do not normally track compat-wireless.)

Ok, it's -rc5, and apparently nothing has happened about this problem. 
Johannes has just been stone-walling and ignoring the reports, and 
claiming it's fixed when it clearly wasn't. 

I just verified on one of my older machines (running current fedora-11, 
with a 4965AGN rev=0x4) that the problem is real, and that reverting that 
commit does indeed seem to fix it.

So here goes: I'm going to revert that commit today or tomorrow, unless 
somebody sends me a fix that I can verify. I don't want any more excuses, 
I don't want to hear developers dismissing bug-reports, and I _can_ verify 
this problem myself. 

We do not fix bugs by introducing new regressions and then ignoring the 
reports. Especially since the bug that the commit in question fixes seems 
to be _way_ less important than the bug it then introduces.

		Linus

Re: Probe Timeouts with 47afbaf5af9454a7a1a64591e20cbfcc27ca67a8

[Linus Torvalds]

On Mon, 11 May 2009, Linus Torvalds wrote:
>
> .. and I _can_ verify this problem myself.

I take that back. It seems to come and go. After rebooting for a 
double-check I just connected fine without the revert, after earlier being 
unable to.

So in my case, it seems to be flakiness, and I can't actually confirm that 
it's due to the same issue.

I'll double- and triple-test some more, but won't revert unless I can 
confirm things better.

			Linus

Re: Probe Timeouts with 47afbaf5af9454a7a1a64591e20cbfcc27ca67a8

[Johannes Berg]

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

On Mon, 2009-05-11 at 10:57 -0700, Linus Torvalds wrote:

> Ok, it's -rc5, and apparently nothing has happened about this problem. 
> Johannes has just been stone-walling and ignoring the reports, and 
> claiming it's fixed when it clearly wasn't. 

?
I always only said it was fixed in wireless-testing and that the fix was
on the way upstream. I have no influence over more. And I worked with
Parag in the bugzilla bug to fix the other bug he was seeing on
wireless-testing-based wireless code up to where he could no longer
reproduce the issue.

> I just verified on one of my older machines (running current fedora-11, 
> with a 4965AGN rev=0x4) that the problem is real, and that reverting that 
> commit does indeed seem to fix it.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c428c89201a57a0ce24c37ed79e540d1f4101cf3

What does "older" mean here, and what kernel were you using?

> So here goes: I'm going to revert that commit today or tomorrow, unless 
> somebody sends me a fix that I can verify. I don't want any more excuses, 
> I don't want to hear developers dismissing bug-reports, and I _can_ verify 
> this problem myself.
> 
> We do not fix bugs by introducing new regressions and then ignoring the 
> reports. Especially since the bug that the commit in question fixes seems 
> to be _way_ less important than the bug it then introduces.

I never ignored the reports. I was a little mad at Parag because he was
reporting a bug that I had just fixed, and he had even seen the original
report. It turned out it wasn't his fault that he couldn't find the fix
from the original thread, and I suppose I could have handled the
duplicate report better even if Parag had known about the fix. I'm sorry
about that.

If you revert that commit (from subject), you're going to make it
default to transmit power -1 dBm if commit c428c892 is in your tree as
well. I have to wonder whether your testing included that commit,
because if reverting 47afbaf5 helped I would think it did not.

From my perspective the bug is dealt with since commit c428c892, if you
want to revert anything please revert _both_ c428c892 and 47afbaf5.

johannes


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

Re: Probe Timeouts with 47afbaf5af9454a7a1a64591e20cbfcc27ca67a8

[Linus Torvalds]

On Mon, 11 May 2009, Johannes Berg wrote:
>
> I always only said it was fixed in wireless-testing and that the fix was
> on the way upstream. I have no influence over more.

Well, since I can't seem to reproduce the problems I had, and since it's 
possible that it wasn't the revert as much as just the reboot itself that 
cleared things up for me, right now I can no longer check one way or the 
other. 

Earlier, it looked like just reverting that commit ended up fixing things, 
which made me very unhappy, since:

> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c428c89201a57a0ce24c37ed79e540d1f4101cf3
> 
> What does "older" mean here, and what kernel were you using?

"older" means a few years old. It's a compaq/hp 2510p that I've bug out in 
preparation for late-rc 2.6.30 testing to see that everything works fine.

And the kernel I'm using is top-of-git, so that fix was there.

Which was obviously exactly why I was so unhappy about this, since the 
revert seemed to fix problems for me _despite_ the fix.

But now that I can't re-create it, I must assume that it was some other 
random thing unrelated to the revert.

			Linus

Re: Probe Timeouts with 47afbaf5af9454a7a1a64591e20cbfcc27ca67a8

[Johannes Berg]

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

On Mon, 2009-05-11 at 11:33 -0700, Linus Torvalds wrote:

> And the kernel I'm using is top-of-git, so that fix was there.

Ok.

> Which was obviously exactly why I was so unhappy about this, since the 
> revert seemed to fix problems for me _despite_ the fix.

Curious really, since with that fix and a revert it would go to -1 dBm.
The only explanation I have is that then the Intel card defaults to some
safe value because it doesn't support values < 0.

johannes

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

Re: Probe Timeouts with 47afbaf5af9454a7a1a64591e20cbfcc27ca67a8

[Linus Torvalds]

On Mon, 11 May 2009, Johannes Berg wrote:
> 
> Curious really, since with that fix and a revert it would go to -1 dBm.
> The only explanation I have is that then the Intel card defaults to some
> safe value because it doesn't support values < 0.

Well, since I'm testing this laptop for any corner cases, the non-working 
case had actually been tested with things like multiple suspend-to-ram 
cycles (while doing accelerated 3D and sound at the same time), along with 
testing anything else I could think of. And everything worked, but 
wireless wouldn't associate.

Reverting and rebooting, and it worked. But then when I wanted to 
double-check (sadly _after_ having already sent out the complaint), I 
now cannot get it to not work even without the revert.

And I've re-done all the STR testing, and that isn't the cause of it.

Oh well.

I don't actually tend to _use_ that laptop, it gets dug out for release 
and distro testing and for some very occasional travel.  I've not had 
issues with wireless on that thing before (apart from any normal iwl 
issues), but maybe it just happened to take a really really long time to 
associate that one time.

				Linus

Re: Probe Timeouts with 47afbaf5af9454a7a1a64591e20cbfcc27ca67a8

[Frans Pop]

Linus Torvalds wrote:
> Well, since I'm testing this laptop for any corner cases, the
> non-working case had actually been tested with things like multiple
> suspend-to-ram cycles (while doing accelerated 3D and sound at the same
> time), along with testing anything else I could think of. And everything
> worked, but wireless wouldn't associate.

JFYI.

I also have a 2510p that I actually _do_ use - as my main workstation - 
both docked (mostly with wired net) and undocked with wireless, and 
between 1 and 4 suspend/resume (to RAM) cycles per day (frequently 
(un)docking while suspended).

I've been running 2.6.30-rc3 and later on it and have not seen any 
wireless (or other) problems. Distro is Debian Lenny.

Firmware in use is:
iwlagn 0000:10:00.0: firmware: requesting iwlwifi-4965-2.ucode
iwlagn 0000:10:00.0: loaded firmware version 228.57.2.23

Cheers,
FJP

Re: Probe Timeouts with 47afbaf5af9454a7a1a64591e20cbfcc27ca67a8

[Parag Warudkar]

On 5/1/09, Johannes Berg <johannes@sipsolutions.net> wrote:
>How did you check that it isn't reverted in compat-wireless anyway?
>[..] if you had made an attempt to verify that the code in
> there works, you would have found that indeed there's no reason to
> revert this commit since the fix for it went in, and is literally a
> single line.

Johannes,

Just got around to downloading today's compat-wireless and it doesn't
work for me - frequent disconnects this time with response timeouts -

 9731.902114] wlan1: RX ReassocResp from 00:1e:e5:6a:2c:c2
(capab=0x411 status=0 aid=1)
[ 9731.902117] wlan1: associated
[ 9886.744022] wlan1: no probe response from AP 00:1e:e5:6a:2c:c2 -
disassociating
[ 9887.594299] wlan1: authenticate with AP 00:1e:e5:6a:2c:c2
[ 9887.596953] wlan1: authenticated
[ 9887.596958] wlan1: associate with AP 00:1e:e5:6a:2c:c2
[ 9887.600997] wlan1: RX ReassocResp from 00:1e:e5:6a:2c:c2
(capab=0x411 status=0 aid=1)
[ 9887.601000] wlan1: associated
[ 9930.640019] wlan1: no probe response from AP 00:1e:e5:6a:2c:c2 -
disassociating

Of course mainline continues to work fine after reverting
47afbaf5af9454a7a1a64591e20cbfcc27ca67a8.


No offense, but that to me is yet another reason to either revert or
get a proper fix in mainline whichever is sooner. (Sorry but
non-working network is impossible to live with - especially so when I
have to rely on mainline to get a working network (compat-wireless
doesn't work and the distro kernel just freezes when connecting to the
network and there is no fix in sight yet [*] ) )

Thanks
Parag

[*] https://bugs.launchpad.net/bugs/364333

Re: Probe Timeouts with 47afbaf5af9454a7a1a64591e20cbfcc27ca67a8

[Johannes Berg]

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

Parag,

> Just got around to downloading today's compat-wireless and it doesn't
> work for me - frequent disconnects this time with response timeouts -
> 
>  9731.902114] wlan1: RX ReassocResp from 00:1e:e5:6a:2c:c2
> (capab=0x411 status=0 aid=1)
> [ 9731.902117] wlan1: associated
> [ 9886.744022] wlan1: no probe response from AP 00:1e:e5:6a:2c:c2 -
> disassociating
> [ 9887.594299] wlan1: authenticate with AP 00:1e:e5:6a:2c:c2
> [ 9887.596953] wlan1: authenticated
> [ 9887.596958] wlan1: associate with AP 00:1e:e5:6a:2c:c2
> [ 9887.600997] wlan1: RX ReassocResp from 00:1e:e5:6a:2c:c2
> (capab=0x411 status=0 aid=1)
> [ 9887.601000] wlan1: associated
> [ 9930.640019] wlan1: no probe response from AP 00:1e:e5:6a:2c:c2 -
> disassociating

This looks like something entirely different.

> Of course mainline continues to work fine after reverting
> 47afbaf5af9454a7a1a64591e20cbfcc27ca67a8.

Can you make sure the txpower is set correctly, on your compat? Just say
"iwconfig wlan0" or whatever _while_ associated -- and check that it
reports 15dBm or so.

johannes

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

Re: Probe Timeouts with 47afbaf5af9454a7a1a64591e20cbfcc27ca67a8

[Parag Warudkar]

On 5/2/09, Johannes Berg <johannes@sipsolutions.net> wrote:
> Parag,
>
>> Just got around to downloading today's compat-wireless and it doesn't
>> work for me - frequent disconnects this time with response timeouts -
>>
>>  9731.902114] wlan1: RX ReassocResp from 00:1e:e5:6a:2c:c2
>> (capab=0x411 status=0 aid=1)
>> [ 9731.902117] wlan1: associated
>> [ 9886.744022] wlan1: no probe response from AP 00:1e:e5:6a:2c:c2 -
>> disassociating
>> [ 9887.594299] wlan1: authenticate with AP 00:1e:e5:6a:2c:c2
>> [ 9887.596953] wlan1: authenticated
>> [ 9887.596958] wlan1: associate with AP 00:1e:e5:6a:2c:c2
>> [ 9887.600997] wlan1: RX ReassocResp from 00:1e:e5:6a:2c:c2
>> (capab=0x411 status=0 aid=1)
>> [ 9887.601000] wlan1: associated
>> [ 9930.640019] wlan1: no probe response from AP 00:1e:e5:6a:2c:c2 -
>> disassociating
>
> This looks like something entirely different.
>
>> Of course mainline continues to work fine after reverting
>> 47afbaf5af9454a7a1a64591e20cbfcc27ca67a8.
>
> Can you make sure the txpower is set correctly, on your compat? Just say
> "iwconfig wlan0" or whatever _while_ associated -- and check that it
> reports 15dBm or so.

It shows 27 dBm when associated - both for mainline and compat.
Still get the disassociated messages.

wlan1     IEEE 802.11bgn  ESSID:"pbwloft2"
          Mode:Managed  Frequency:2.447 GHz  Access Point: 00:1E:E5:6A:2C:C2
          Bit Rate=1 Mb/s   Tx-Power=27 dBm
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:21F9-23AF-AEBB-A427-4ADC-8596-C915-ADC8 [2]
Security mode:open
          Power Management:on
          Link Quality=38/70  Signal level=-72 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

Parag

Re: Probe Timeouts with 47afbaf5af9454a7a1a64591e20cbfcc27ca67a8

[Johannes Berg]

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

On Sat, 2009-05-02 at 07:20 -0400, Parag Warudkar wrote:

> > Can you make sure the txpower is set correctly, on your compat? Just say
> > "iwconfig wlan0" or whatever _while_ associated -- and check that it
> > reports 15dBm or so.
> 
> It shows 27 dBm when associated - both for mainline and compat.

Good.

> Still get the disassociated messages.

Right, different problem then. Can you put that into a kernel.org
bugzilla please?

johannes

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

Re: Probe Timeouts with 47afbaf5af9454a7a1a64591e20cbfcc27ca67a8

[Parag Warudkar]

On 5/2/09, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Sat, 2009-05-02 at 07:20 -0400, Parag Warudkar wrote:
>
>> > Can you make sure the txpower is set correctly, on your compat? Just say
>> > "iwconfig wlan0" or whatever _while_ associated -- and check that it
>> > reports 15dBm or so.
>>
>> It shows 27 dBm when associated - both for mainline and compat.
>
> Good.
>
>> Still get the disassociated messages.
>
> Right, different problem then. Can you put that into a kernel.org
> bugzilla please?
>

Done - http://bugzilla.kernel.org/show_bug.cgi?id=13223

Thanks
Parag