IWLWIFI - 3.18-stable

DISCUSSION Chris Clayton 2 participants 7 messages Jan 11, 2015 – Jan 12, 2015

Share & tools

Chris Clayton

author

2015-01-11 12:56 UTC #0 lore raw

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

Chris Clayton

author

2015-01-11 13:00 UTC #1 lore raw

Doh! Cut and paste error ...

Quoted 10 lines · 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

The above should have been:

c93edc639392df733c7d72db4376a9add775d18a - iwlwifi: mvm: fix Rx with both chains

Quoted 12 lines

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

Emmanuel Grumbach

2015-01-11 14:16 UTC #2 lore raw

Hi Chris,

thank you for you analysis, it is very helpful

Quoted 12 lines

Doh! Cut and paste error ...
Quoted 9 lines · 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:

Quoted 14 lines

Quoted 1 line
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
Quoted 8 lines
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?

Chris Clayton

author

2015-01-11 20:23 UTC #3 lore raw

Thanks Emmanuel.

Quoted 4 lines · Emmanuel Grumbach

Hi Chris,
thank you for you analysis, it is very helpful

You're welcome.

Quoted 21 lines

Quoted 21 lines
Doh! Cut and paste error ...
Quoted 10 lines · 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
The above should have been:
c93edc639392df733c7d72db4376a9add775d18a - iwlwifi: mvm: fix Rx with both chains
Quoted 3 lines
a9dc5060bf3a32ac3dad472f15416054b92dc5b5 - iwlwifi: mvm: fix out of bounds access to tid_to_mac80211_ac

Quoted 7 lines

Quoted 5 lines
Quoted 5 lines
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.

Quoted 1 line

Are you using bluetooth?

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

Quoted 1 line

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.

Quoted 3 lines

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

Quoted 1 line

Emmanuel Grumbach

2015-01-12 06:03 UTC #4 lore raw

Quoted 45 lines · Chris Clayton

Thanks Emmanuel.
Quoted 4 lines · Emmanuel Grumbach
Hi Chris,
thank you for you analysis, it is very helpful
You're welcome.
Quoted 21 lines
Quoted 21 lines
Doh! Cut and paste error ...
Quoted 10 lines · 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
The above should have been:
c93edc639392df733c7d72db4376a9add775d18a - iwlwifi: mvm: fix Rx with both chains
Quoted 3 lines
a9dc5060bf3a32ac3dad472f15416054b92dc5b5 - iwlwifi: mvm: fix out of bounds access to tid_to_mac80211_ac
Quoted 7 lines
Quoted 5 lines
Quoted 5 lines
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.
Quoted 1 line
Are you using bluetooth?
Yes, I have a bluetooth mouse and use bluetooth for audio from time to time.

Quoted 7 lines

Quoted 1 line
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.

Quoted 6 lines

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

Quoted 6 lines

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.

Quoted 3 lines

Chris
Quoted 1 line

Chris Clayton

author

2015-01-12 11:51 UTC #5 lore raw

Thanks Emmanuel.

Quoted 2 lines · Emmanuel Grumbach

On Sun, Jan 11, 2015 at 10:23 PM, Chris Clayton
<[email protected]> wrote:

[snip]

Quoted 7 lines

Quoted 7 lines
Quoted 2 lines
The first one (c93edc639392df733c7d72db4376a9add775d18a) is tagged for stable.
Ah, sorry I missed that.
Quoted 1 line
Are you using bluetooth?

Quoted 8 lines

Quoted 8 lines
Yes, I have a bluetooth mouse and use bluetooth for audio from time to time.
Quoted 1 line
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.

Quoted 18 lines

Quoted 1 line
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.
Quoted 11 lines
Quoted 5 lines
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.

Quoted 5 lines

Quoted 1 line
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! :-)

Quoted 6 lines

Thanks.
Quoted 3 lines
Chris
Quoted 1 line

Emmanuel Grumbach

2015-01-12 12:20 UTC #6 lore raw

Quoted 41 lines

[snip]
Quoted 7 lines
Quoted 7 lines
Quoted 2 lines
The first one (c93edc639392df733c7d72db4376a9add775d18a) is tagged for stable.
Ah, sorry I missed that.
Quoted 1 line
Are you using bluetooth?
Quoted 8 lines
Quoted 8 lines
Yes, I have a bluetooth mouse and use bluetooth for audio from time to time.
Quoted 1 line
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.
Quoted 18 lines
Quoted 1 line
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.
Quoted 11 lines
Quoted 5 lines
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.

Quoted 9 lines

Quoted 5 lines
Quoted 1 line
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! :-)
Quoted 1 line

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.