IWLWIFI - 3.18-stable

IWLWIFI - 3.18-stable

[Chris Clayton]

Hi Kalle,

Having recently bought a new laptop, I've just started using the iwlwifi driver for wireless networking. I found both
3.18.x and the current development tree to be very unreliable due to frequent disconnections from the router.

Before you merged them into your tree, I grabbed the latest fixes from iwlwifi-fixes tree and applied them to the
development kernel. Since I did that I've had no problems at all with dropped connections. I then looked at each patch
to see whether it might be applicable to 3.18 and found that two of them looked as if they should be useful. They are:

c93edc639392df733c7d72db4376a9add775d18a - iwlwifi: mvm: don't allow diversity if BT Coex / TT forbid it

a9dc5060bf3a32ac3dad472f15416054b92dc5b5 - iwlwifi: mvm: fix out of bounds access to tid_to_mac80211_ac

With those two applied, I've had stable wireless networking on 3.18.2 and, more recently, 3.18.2. Consequently, they
seem appropriate for tagging for 3.18-stable, but, as far as I can see, they haven't been tagged for stable. Apologies,
if I'm mistaken, but if I'm not, could you consider submitting the two patches for inclusion in 3.18, please? Of course,
they may be appropriate to earlier kernels too - I haven't looked.

Thanks

Chris

Re: IWLWIFI - 3.18-stable

[Chris Clayton]

Doh! Cut and paste error ...

On 01/11/15 12:56, Chris Clayton wrote:
> Hi Kalle,
> 
> Having recently bought a new laptop, I've just started using the iwlwifi driver for wireless networking. I found both
> 3.18.x and the current development tree to be very unreliable due to frequent disconnections from the router.
> 
> Before you merged them into your tree, I grabbed the latest fixes from iwlwifi-fixes tree and applied them to the
> development kernel. Since I did that I've had no problems at all with dropped connections. I then looked at each patch
> to see whether it might be applicable to 3.18 and found that two of them looked as if they should be useful. They are:
> 
> c93edc639392df733c7d72db4376a9add775d18a - iwlwifi: mvm: don't allow diversity if BT Coex / TT forbid it

The above should have been:

c93edc639392df733c7d72db4376a9add775d18a - iwlwifi: mvm: fix Rx with both chains

> 
> a9dc5060bf3a32ac3dad472f15416054b92dc5b5 - iwlwifi: mvm: fix out of bounds access to tid_to_mac80211_ac
> 
> With those two applied, I've had stable wireless networking on 3.18.2 and, more recently, 3.18.2. Consequently, they
> seem appropriate for tagging for 3.18-stable, but, as far as I can see, they haven't been tagged for stable. Apologies,
> if I'm mistaken, but if I'm not, could you consider submitting the two patches for inclusion in 3.18, please? Of course,
> they may be appropriate to earlier kernels too - I haven't looked.
> 
> Thanks
> 
> Chris
> 

Re: IWLWIFI - 3.18-stable

[Emmanuel Grumbach]

Hi Chris,

thank you for you analysis, it is very helpful

> Doh! Cut and paste error ...
>
> On 01/11/15 12:56, Chris Clayton wrote:
> > Hi Kalle,
> >
> > Having recently bought a new laptop, I've just started using the iwlwifi driver for wireless networking. I found both
> > 3.18.x and the current development tree to be very unreliable due to frequent disconnections from the router.
> >
> > Before you merged them into your tree, I grabbed the latest fixes from iwlwifi-fixes tree and applied them to the
> > development kernel. Since I did that I've had no problems at all with dropped connections. I then looked at each patch
> > to see whether it might be applicable to 3.18 and found that two of them looked as if they should be useful. They are:
> >
> > c93edc639392df733c7d72db4376a9add775d18a - iwlwifi: mvm: don't allow diversity if BT Coex / TT forbid it
>
> The above should have been:
>
> c93edc639392df733c7d72db4376a9add775d18a - iwlwifi: mvm: fix Rx with both chains
>
> >
> > a9dc5060bf3a32ac3dad472f15416054b92dc5b5 - iwlwifi: mvm: fix out of bounds access to tid_to_mac80211_ac
> >
> > With those two applied, I've had stable wireless networking on 3.18.2 and, more recently, 3.18.2. Consequently, they
> > seem appropriate for tagging for 3.18-stable, but, as far as I can see, they haven't been tagged for stable. Apologies,
> > if I'm mistaken, but if I'm not, could you consider submitting the two patches for inclusion in 3.18, please? Of course,
> > they may be appropriate to earlier kernels too - I haven't looked.
> >

The first one (c93edc639392df733c7d72db4376a9add775d18a) is tagged for stable.
Are you using bluetooth?
Are you able to tell me which of the two really helps?
Unless I am missing something, the first one
(c93edc639392df733c7d72db4376a9add775d18a) should help only if you
disabled power save. Is that the case?

Re: IWLWIFI - 3.18-stable

[Chris Clayton]

Thanks Emmanuel.

On 01/11/15 14:16, Emmanuel Grumbach wrote:
> Hi Chris,
> 
> thank you for you analysis, it is very helpful
> 

You're welcome.

>> Doh! Cut and paste error ...
>>
>> On 01/11/15 12:56, Chris Clayton wrote:
>>> Hi Kalle,
>>>
>>> Having recently bought a new laptop, I've just started using the iwlwifi driver for wireless networking. I found both
>>> 3.18.x and the current development tree to be very unreliable due to frequent disconnections from the router.
>>>
>>> Before you merged them into your tree, I grabbed the latest fixes from iwlwifi-fixes tree and applied them to the
>>> development kernel. Since I did that I've had no problems at all with dropped connections. I then looked at each patch
>>> to see whether it might be applicable to 3.18 and found that two of them looked as if they should be useful. They are:
>>>
>>> c93edc639392df733c7d72db4376a9add775d18a - iwlwifi: mvm: don't allow diversity if BT Coex / TT forbid it
>>
>> The above should have been:
>>
>> c93edc639392df733c7d72db4376a9add775d18a - iwlwifi: mvm: fix Rx with both chains
>>
>>>
>>> a9dc5060bf3a32ac3dad472f15416054b92dc5b5 - iwlwifi: mvm: fix out of bounds access to tid_to_mac80211_ac
>>>
>>> With those two applied, I've had stable wireless networking on 3.18.2 and, more recently, 3.18.2. Consequently, they
>>> seem appropriate for tagging for 3.18-stable, but, as far as I can see, they haven't been tagged for stable. Apologies,
>>> if I'm mistaken, but if I'm not, could you consider submitting the two patches for inclusion in 3.18, please? Of course,
>>> they may be appropriate to earlier kernels too - I haven't looked.
>>>
> 
> The first one (c93edc639392df733c7d72db4376a9add775d18a) is tagged for stable.

Ah, sorry I missed that.

> Are you using bluetooth?

Yes, I have a bluetooth mouse and use bluetooth for audio from time to time.

> Are you able to tell me which of the two really helps?

It's c93edc639392df733c7d72db4376a9add775d18a that helps. With that applied, I can set off a task which, in a loop,
continually copies a 180MB file from a server on my network. The network remained stable for over 30 minutes before I
killed the task. Without the patch, the network fails during the first iteration of copying the file.

a9dc5060bf3a32ac3dad472f15416054b92dc5b5 doesn't seem to have any effect on the instability.


> Unless I am missing something, the first one
> (c93edc639392df733c7d72db4376a9add775d18a) should help only if you
> disabled power save. Is that the case?

Not that I know of. The only power-related thing in my init scripts is echoing 5 to /proc/sys/vm/laptop_mode, which I
believe configures disk activity to save power. The mouse does have a power saving feature, however. According to the
manual, it reduces its power consumption in steps the longer it is inactive. As I frequently work in kde's konsole
terminal application, mouse inactivity is common.

Hope this helps and feel free to request additional information.

Chris
> 

Re: IWLWIFI - 3.18-stable

[Emmanuel Grumbach]

On Sun, Jan 11, 2015 at 10:23 PM, Chris Clayton
<chris2553@googlemail.com> wrote:
> Thanks Emmanuel.
>
> On 01/11/15 14:16, Emmanuel Grumbach wrote:
>> Hi Chris,
>>
>> thank you for you analysis, it is very helpful
>>
>
> You're welcome.
>
>>> Doh! Cut and paste error ...
>>>
>>> On 01/11/15 12:56, Chris Clayton wrote:
>>>> Hi Kalle,
>>>>
>>>> Having recently bought a new laptop, I've just started using the iwlwifi driver for wireless networking. I found both
>>>> 3.18.x and the current development tree to be very unreliable due to frequent disconnections from the router.
>>>>
>>>> Before you merged them into your tree, I grabbed the latest fixes from iwlwifi-fixes tree and applied them to the
>>>> development kernel. Since I did that I've had no problems at all with dropped connections. I then looked at each patch
>>>> to see whether it might be applicable to 3.18 and found that two of them looked as if they should be useful. They are:
>>>>
>>>> c93edc639392df733c7d72db4376a9add775d18a - iwlwifi: mvm: don't allow diversity if BT Coex / TT forbid it
>>>
>>> The above should have been:
>>>
>>> c93edc639392df733c7d72db4376a9add775d18a - iwlwifi: mvm: fix Rx with both chains
>>>
>>>>
>>>> a9dc5060bf3a32ac3dad472f15416054b92dc5b5 - iwlwifi: mvm: fix out of bounds access to tid_to_mac80211_ac
>>>>
>>>> With those two applied, I've had stable wireless networking on 3.18.2 and, more recently, 3.18.2. Consequently, they
>>>> seem appropriate for tagging for 3.18-stable, but, as far as I can see, they haven't been tagged for stable. Apologies,
>>>> if I'm mistaken, but if I'm not, could you consider submitting the two patches for inclusion in 3.18, please? Of course,
>>>> they may be appropriate to earlier kernels too - I haven't looked.
>>>>
>>
>> The first one (c93edc639392df733c7d72db4376a9add775d18a) is tagged for stable.
>
> Ah, sorry I missed that.
>
>> Are you using bluetooth?
>
> Yes, I have a bluetooth mouse and use bluetooth for audio from time to time.
>
>> Are you able to tell me which of the two really helps?
>
> It's c93edc639392df733c7d72db4376a9add775d18a that helps. With that applied, I can set off a task which, in a loop,
> continually copies a 180MB file from a server on my network. The network remained stable for over 30 minutes before I
> killed the task. Without the patch, the network fails during the first iteration of copying the file.
>
> a9dc5060bf3a32ac3dad472f15416054b92dc5b5 doesn't seem to have any effect on the instability.

Ok - I am not surprised - thanks.
c93edc... allows to use 2 antennas instead of one only. Technically,
one would be enough, but apparently, in your configuration, using 2
antennas allows to improve reliability.

>
>
>> Unless I am missing something, the first one
>> (c93edc639392df733c7d72db4376a9add775d18a) should help only if you
>> disabled power save. Is that the case?
>
> Not that I know of. The only power-related thing in my init scripts is echoing 5 to /proc/sys/vm/laptop_mode, which I
> believe configures disk activity to save power. The mouse does have a power saving feature, however. According to the
> manual, it reduces its power consumption in steps the longer it is inactive. As I frequently work in kde's konsole
> terminal application, mouse inactivity is common.
>
> Hope this helps and feel free to request additional information.

Ok - I checked the code and we enable the redundancy mentioned above
(2 antenna instead of 1) even if power save is enabled.
FWIW - this redundancy is also called "diversity".

Thanks.

>
> Chris
>>

Re: IWLWIFI - 3.18-stable

[Chris Clayton]

Thanks Emmanuel.

On 01/12/15 06:03, Emmanuel Grumbach wrote:
> On Sun, Jan 11, 2015 at 10:23 PM, Chris Clayton
> <chris2553@googlemail.com> wrote:

[snip]

>>>
>>> The first one (c93edc639392df733c7d72db4376a9add775d18a) is tagged for stable.
>>
>> Ah, sorry I missed that.
>>
>>> Are you using bluetooth?
>>
>> Yes, I have a bluetooth mouse and use bluetooth for audio from time to time.
>>
>>> Are you able to tell me which of the two really helps?
>>
>> It's c93edc639392df733c7d72db4376a9add775d18a that helps. With that applied, I can set off a task which, in a loop,
>> continually copies a 180MB file from a server on my network. The network remained stable for over 30 minutes before I
>> killed the task. Without the patch, the network fails during the first iteration of copying the file.
>>

Just by way of confirmation, I'm now running 3.19.0-rc4 with c93edc639392df733c7d72db4376a9add775d18a applied and my
network is stable. None of the other patches from iwlwifi-fixes that I was previously using are applied.

Thanks for your help.

>> a9dc5060bf3a32ac3dad472f15416054b92dc5b5 doesn't seem to have any effect on the instability.
> 
> Ok - I am not surprised - thanks.
> c93edc... allows to use 2 antennas instead of one only. Technically,
> one would be enough, but apparently, in your configuration, using 2
> antennas allows to improve reliability.
> 
>>
>>
>>> Unless I am missing something, the first one
>>> (c93edc639392df733c7d72db4376a9add775d18a) should help only if you
>>> disabled power save. Is that the case?
>>
>> Not that I know of. The only power-related thing in my init scripts is echoing 5 to /proc/sys/vm/laptop_mode, which I
>> believe configures disk activity to save power. The mouse does have a power saving feature, however. According to the
>> manual, it reduces its power consumption in steps the longer it is inactive. As I frequently work in kde's konsole
>> terminal application, mouse inactivity is common.
>>
>> Hope this helps and feel free to request additional information.
> 
> Ok - I checked the code and we enable the redundancy mentioned above
> (2 antenna instead of 1) even if power save is enabled.
> FWIW - this redundancy is also called "diversity".

<Smile>. Over 30 years working in the IT industry tells me that is a trick vendors have been using for a long time in
order to try and confuse customers into buying something they've already got! :-)
> 
> Thanks.
> 
>>
>> Chris
>>>

Re: IWLWIFI - 3.18-stable

[Emmanuel Grumbach]

> [snip]
>
>>>>
>>>> The first one (c93edc639392df733c7d72db4376a9add775d18a) is tagged for stable.
>>>
>>> Ah, sorry I missed that.
>>>
>>>> Are you using bluetooth?
>>>
>>> Yes, I have a bluetooth mouse and use bluetooth for audio from time to time.
>>>
>>>> Are you able to tell me which of the two really helps?
>>>
>>> It's c93edc639392df733c7d72db4376a9add775d18a that helps. With that applied, I can set off a task which, in a loop,
>>> continually copies a 180MB file from a server on my network. The network remained stable for over 30 minutes before I
>>> killed the task. Without the patch, the network fails during the first iteration of copying the file.
>>>
>
> Just by way of confirmation, I'm now running 3.19.0-rc4 with c93edc639392df733c7d72db4376a9add775d18a applied and my
> network is stable. None of the other patches from iwlwifi-fixes that I was previously using are applied.
>
> Thanks for your help.
>
>>> a9dc5060bf3a32ac3dad472f15416054b92dc5b5 doesn't seem to have any effect on the instability.
>>
>> Ok - I am not surprised - thanks.
>> c93edc... allows to use 2 antennas instead of one only. Technically,
>> one would be enough, but apparently, in your configuration, using 2
>> antennas allows to improve reliability.
>>
>>>
>>>
>>>> Unless I am missing something, the first one
>>>> (c93edc639392df733c7d72db4376a9add775d18a) should help only if you
>>>> disabled power save. Is that the case?
>>>
>>> Not that I know of. The only power-related thing in my init scripts is echoing 5 to /proc/sys/vm/laptop_mode, which I
>>> believe configures disk activity to save power. The mouse does have a power saving feature, however. According to the
>>> manual, it reduces its power consumption in steps the longer it is inactive. As I frequently work in kde's konsole
>>> terminal application, mouse inactivity is common.
>>>
>>> Hope this helps and feel free to request additional information.
>>
>> Ok - I checked the code and we enable the redundancy mentioned above
>> (2 antenna instead of 1) even if power save is enabled.
>> FWIW - this redundancy is also called "diversity".
>
> <Smile>. Over 30 years working in the IT industry tells me that is a trick vendors have been using for a long time in
> order to try and confuse customers into buying something they've already got! :-)
>>

Oh - we do that all the time, but this is something else :)
It is not very easy to take the good system decision: have the
antennas on all the time and you'll waste power, switch off antennas
and you will lose link quality.
The best would be to make it depend on the network as a whole. This is
what 11k is supposed to solve, but we don't really implement this.