iwlwifi-7260-8.ucode causes network disconnections problems

[Barry]

Running 14.04 (beta) with Kernel 3.13.0-17-generic

I've encountered a strange and reproducible error with the iwlwifi-7260-8.ucode firmware.

This laptop is a Dell XPS 12 (haswell). With the -8 firmware, it will connect fine to wifi for 30 or 40 mins at a time, then will start dropping connections repeatedly. Even modprobe -r unloading and reloading doesn't fix the issue, only a reboot will temporarily solve it for 40 mins at a time.

Moreover, here is what's strange, is during these episodes of disconnection it seems to affect the actual router (2Wire), as the other devices in the house will also start to have issues (very slow connections, limited range,etc). Once I reboot this laptop everything and all devices will return to normal.

This issue has been fixed by me manually removing the -8 firware from /lib/firmware and letting the -7 firmware load instead. Since that has been done there has not been a single issue of this happening (now going on 4 days).

let me know if there is any other information you would like me to provide.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: linux-firmware 1.126
ProcVersionSignature: Ubuntu 3.13.0-17.37-generic 3.13.6
Uname: Linux 3.13.0-17-generic x86_64
ApportVersion: 2.13.3-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Mon Mar 17 08:13:25 2014
Dependencies:

EcryptfsInUse: Yes
InstallationDate: Installed on 2014-03-07 (9 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140307)
PackageArchitecture: all
SourcePackage: linux-firmware
UpgradeStatus: No upgrade log present (probably fresh install)

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.14 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14-rc7-trusty/

[Barry (barry-magicrd)]

Joseph.

I have tested using the upstream kernel you recommended (3.14.0-031400rc7-generic #201403162235), however same problem persist.

Strangely the error seems to always materialize at the 20 - 25 min mark from boot. Then sometimes it will reconnect, sometimes not - but never for more than 5 mins successfully at a time.

Further, just like in previous kernel, problem is aleviated by moving to -7 firmware.

Lastly, your post mentioned adding a tag of 'kernel-bug-exists-upstream', however I don't seem to see a way to do that? Sorry about that, newbie here.

Please advise.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Taylan Tatlı (taylantatli)]

same thing with iwlwifi and kernel 3.13 and 3.14 on arch linux. So i tired of it and tried ubuntu 14.04 but same thing was there. Now i'm on arch linux again and waiting for an solution. :/

[dnsem (dnsem)]

I have the same problem with Dell XPS 13 running Ubuntu 14.04.

[Thibauld (thibauld)]

Same here with a freshly installed Ubuntu 14.04 running kernel 3.13.0-24-generic #46-Ubuntu SMP
I am using this wireless card :
http://www.intel.com/content/www/us/en/wireless-products/dual-band-wireless-ac-7260-bluetooth.html

Right after installation, wifi was extremely slow (to the point where browsing the web was not possible).

I found a workaround that fixed the issue following the instructions given here:
http://zeroset.mnim.org/2014/04/22/unstable-wifi-connection-on-ubuntu-14-04-trusty-tahr-ctrl-event-disconnected-reason4-locally_generated1/

[Thibauld (thibauld)]

I just got a disconnection, here is what syslog has to say about it:

Apr 30 12:53:06 thibauld-desktop wpa_supplicant[815]: message repeated 47 times: [ wlan0: CTRL-EVENT-SCAN-STARTED ]
Apr 30 12:54:54 thibauld-desktop wpa_supplicant[815]: wlan0: CTRL-EVENT-DISCONNECTED bssid=cc:35:40:57:80:e1 reason=4 locally_generated=1
Apr 30 12:54:54 thibauld-desktop NetworkManager[699]: <warn> Connection disconnected (reason -4)
Apr 30 12:54:54 thibauld-desktop kernel: [14259.692842] cfg80211: Calling CRDA to update world regulatory domain
Apr 30 12:54:54 thibauld-desktop kernel: [14259.695285] cfg80211: World regulatory domain updated:
Apr 30 12:54:54 thibauld-desktop kernel: [14259.695288] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Apr 30 12:54:54 thibauld-desktop kernel: [14259.695290] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Apr 30 12:54:54 thibauld-desktop kernel: [14259.695292] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Apr 30 12:54:54 thibauld-desktop kernel: [14259.695293] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Apr 30 12:54:54 thibauld-desktop kernel: [14259.695294] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Apr 30 12:54:54 thibauld-desktop kernel: [14259.695295] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Apr 30 12:54:54 thibauld-desktop NetworkManager[699]: <info> (wlan0): supplicant interface state: completed -> disconnected
Apr 30 12:54:54 thibauld-desktop wpa_supplicant[815]: wlan0: CTRL-EVENT-SCAN-STARTED
Apr 30 12:54:54 thibauld-desktop NetworkManager[699]: <info> (wlan0): supplicant interface state: disconnected -> scanning
Apr 30 12:54:58 thibauld-desktop wpa_supplicant[815]: wlan0: SME: Trying to authenticate with cc:35:40:57:80:e1 (SSID='Math Network' freq=2462 MHz)
Apr 30 12:54:58 thibauld-desktop kernel: [14263.454497] wlan0: authenticate with cc:35:40:57:80:e1
Apr 30 12:54:58 thibauld-desktop kernel: [14263.456106] wlan0: send auth to cc:35:40:57:80:e1 (try 1/3)
Apr 30 12:54:58 thibauld-desktop NetworkManager[699]: <info> (wlan0): supplicant interface state: scanning -> authenticating
Apr 30 12:54:58 thibauld-desktop wpa_supplicant[815]: wlan0: Trying to associate with cc:35:40:57:80:e1 (SSID='Math Network' freq=2462 MHz)
Apr 30 12:54:58 thibauld-desktop kernel: [14263.460143] wlan0: authenticated
Apr 30 12:54:58 thibauld-desktop kernel: [14263.463419] wlan0: associate with cc:35:40:57:80:e1 (try 1/3)
Apr 30 12:54:58 thibauld-desktop kernel: [14263.466334] wlan0: RX AssocResp from cc:35:40:57:80:e1 (capab=0x411 status=0 aid=5)
Apr 30 12:54:58 thibauld-desktop kernel: [14263.467056] wlan0: associated
Apr 30 12:54:58 thibauld-desktop NetworkManager[699]: <info> (wlan0): supplicant interface state: authenticating -> associating
Apr 30 12:54:58 thibauld-desktop wpa_supplicant[815]: wlan0: Associated with cc:35:40:57:80:e1
Apr 30 12:54:58 thibauld-desktop NetworkManager[699]: <info> (wlan0): supplicant interface state: associating -> associated
Apr 30 12:54:58 thibauld-desktop NetworkManager[699]: <info> (wlan0): supplicant interface state: associate...

[Emmanuel Grumbach (egrumbach)]

can you try to re-enabled 11n and disable powersave:

sudo iw wlan0 set power_save off?

thanks

[Thibauld (thibauld)]

I just tried by doing the following:
1. re-enabling 11n
2. rebooting
3. disabling powersave
=> does not work

The PC looks connected to the AP but even google.com will time-out after some time (DNS_PROBE_FINISHED_NO_INTERNET).
Tried another website (http://test.com). Very slow connection. After a while, part of the website displays but lots of elements in the page don't show. A look at the console log shows that the browser got a net::ERR_NAME_RESOLUTION_FAILED for the elements in the page that do not show.

Let me know if I can help more.
The best I could do so far was installing mainline kernel 3.14.1 as well as the related firmware microcode from:
http://wireless.kernel.org/en/users/Drivers/iwlwifi

But even with this setup, I would still need to disable 11n to get wifi working. So in the end, I wonder if installing the new kernel really had any impact at all. I am not quite sure.

[decoder (decoder-ubuntu)]

I can fully confirm the original reporter's observations. I have a 2nd generation Thinkpad X1 Carbon here with the same wireless card and I had exactly the same symptoms:

* Connectivity losses
* Bad performance
* Once the device uses wireless (e.g. a download), all other devices in the same wireless network experience problems (e.g. very high latency with spikes up to 2000ms).

I've disabled the -8 firmware as described in comment 0 and so far, all issues are gone.

[Ted Gould (ted)]

My wireless (XPS13 Hashwell) was basically useless as it was crashing. Followed the advice here and switched to the -7 firmware and have had wireless all day. I'm free from the Ethernet! And it's spring so going outside is important!

[Emmanuel Grumbach (egrumbach)]

can someone have a sniffer capture of this? This would be very useful.
One more point - if you can increase the debug level of the supplicant, this would be nice.
Also, there are 2 -8 firmware. One is 22.15.8.0, the other one is 22.24.8.0. Can you please let me know which one you are using?
The version appear at load time.
I also would like to know what is the AP you are using.

I know we have bugs with uAPSD (that are fixed in -9 firmware) - but uAPSD is disabled on your kernel (thanks Seth).
I have another report about this very same behavior on kernel.org (https://bugzilla.kernel.org/show_bug.cgi?id=74311).

thank you.

[Seth Forshee (sforshee)]

On Sun, May 04, 2014 at 03:52:02PM -0000, Emmanuel Grumbach wrote:
> can someone have a sniffer capture of this? This would be very useful.
> One more point - if you can increase the debug level of the supplicant, this would be nice.

If anyone wants to try this, I have a script which might help. It can be
downloaded from http://people.canonical.com/~sforshee/wifi-debug. After
downloading you need to do the following in a terminal after changing to
the directory where you donwloaded the file:

  sudo apt-get install iw tshark
  chmod +x wifi-debug
  sudo ./wifi-debug -p

Wait for the problem to occur, then press Ctrl-C and wait for the script
to finish. After it completes you will have a file named
wifi-debug-files.tar.gz with the requested data.

Note that this file will be large (potentially very large if it runs for
a long time) and may contain some private information, though WPA/WEP
keys should not be present and data sent on an encrypted network will be
encrypted. However you still may want to share the file in a less public
way, e.g. upload it to dropbox or similar and send Emmanuel or me a
link.

And if anyone has the know-how to capture a sniff using a monitor
interface on a separate machine, that would be preferable to the method
used in the script.

Thanks!

> Also, there are 2 -8 firmware. One is 22.15.8.0, the other one is 22.24.8.0. Can you please let me know which one you are using?
> The version appear at load time.

Emmanuel: The firmware version in our linux-firmware package is
22.24.8.0.

[Daniel Manrique (roadmr)]

I'm on a Dell XPS 13 with Ubuntu 14.04 with kernel 3.13.0-24 and I'm not affected by this problem. I checked and, even though the -8 firmware exists in /lib/firmware, my iwlwifi module is only loading the -7 firmware.

If this can help in any way (i.e. why is my laptop loading the -7 module while other presumably identical ones aren't) please let me know, I can provide any details or diagnostic information needed.

[Seth Forshee (sforshee)]

On Mon, May 05, 2014 at 02:52:41PM -0000, Daniel Manrique wrote:
> I'm on a Dell XPS 13 with Ubuntu 14.04 with kernel 3.13.0-24 and I'm not
> affected by this problem. I checked and, even though the -8 firmware
> exists in /lib/firmware, my iwlwifi module is only loading the -7
> firmware.
>
> If this can help in any way (i.e. why is my laptop loading the -7 module
> while other presumably identical ones aren't) please let me know, I can
> provide any details or diagnostic information needed.

Are you sure that it loads -7? Beware, modinfo seems to be lying (well,
actually iwlwifi is lying and modinfo just repeats the lie).

What does 'dmesg | grep "iwlwifi .* loaded firmware version"' say?

[Tim Gardner (timg-tpi)]

Emmanuel - The issue with modinfo is that IWL7260_UCODE_API_MAX is never referenced in a MODULE_FIRMWARE() macro.

drivers/net/wireless/iwlwifi/iwl-7000.c:
MODULE_FIRMWARE(IWL7260_MODULE_FIRMWARE(IWL7260_UCODE_API_OK));
MODULE_FIRMWARE(IWL3160_MODULE_FIRMWARE(IWL3160_UCODE_API_OK));

It appears that this -8 firmware is causal on Haswell, so I'm going to remove it from our stable releases (Precise/Trusty) until it gets sorted.

[Seth Forshee (sforshee)]

On Mon, May 05, 2014 at 04:21:02PM -0000, Emmanuel Grumbach wrote:
> any suggestions to fix the lie are welcome :)

I guess lie was a bit strong, how about half-truth ;-)

I don't know if it's something which needs a fix, I just wanted to warn
that what modinfo says in this case doesn't indicate which firmware is
actually used.

> The thing is that MODULE_FIRMWARE can't really check what firmware has
> been loaded.

Right, the point is to declare what firmware the driver can use, not
what it is using right now. This probably isn't the right forum to hash
this out, so if I decide we need to fix it I'll send you a patch.

[Adam Conrad (adconrad)]

Hello Barry, or anyone else affected,

Accepted linux-firmware into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/linux-firmware/1.79.14 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Adam Conrad (adconrad)]

Hello Barry, or anyone else affected,

Accepted linux-firmware into trusty-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/linux-firmware/1.127.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Daniel Manrique (roadmr)]

@Seth:

Right, lsmod is lying:

[ 9.237101] iwlwifi 0000:02:00.0: loaded firmware version 22.24.8.0 op_mode iwlmvm

Still, I don't get the disconnections and failures reported in this bug... strange!

[Emmanuel Grumbach (egrumbach)]

No it is not strange.
This bug affects a few users only. I bet it is related to the AP model.

Can the people who suffer from the bug send the details of their AP ?

[Daniel Manrique (roadmr)]

Maybe it's related to the band in use?

The syslog from comment #8 shows a 2.4GHz AP:

(SSID='Math Network' freq=2462 MHz)

Both of the ones I use (without any problems so far) are 5GHz 802.11n. I don't think I've ever used a 2.4GHz Ap with this laptop. One is an Asus RT-N66U, the other is some enterprisey Cisco model.

[Emmanuel Grumbach (egrumbach)]

Daniel, if you don't have issues, this is not very useful...

[Seth Forshee (sforshee)]

Daniel: I've tested various APs in my possession on both 2.4 and 5 GHz and don't see these problems either, so as far as I can tell it is not related to the frequency band.

And to everyone affected, please respond to Emmanuel's requests for information. He's the maintainer of the iwlwifi driver, so helping him is the best way to help get this problem fixed.

[Barry (barry-magicrd)]

Hi Emmanuel.

Original submitter here:

Unfortunately I haven't had time to try to capture packets during failure, but I'm open to doing that (hopefully today or tomorrow).

Here are the details for my AP:

Overview: This is one of the standard ATT Uverse Modems. No specific config changes (besides password), otherwise stock standard.
Manufacturer: Pace Plc
Model: 3800HGV-B
Software Version: 6.9.1.42-plus.tm
Wireless Mode: 802.11b/g
Auth Type: WPA-PSK (TKIP) and WPA2-PSK (AES)
DTIM Period: 1
Rate: 54Mbps

Others in thread who are affected, please post an overview of your AP so that a profile can be built.

Regards,
Barry

On May 6, 2014, at 12:00 PM, Emmanuel Grumbach <email address hidden> wrote:

> Daniel, if you don't have issues, this is not very useful...
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1293569
>
> Title:
> iwlwifi-7260-8.ucode causes network disconnections problems
>
> Status in “linux-firmware” package in Ubuntu:
> Confirmed
> Status in “linux-firmware” source package in Precise:
> Fix Committed
> Status in “linux-firmware” source package in Trusty:
> Fix Committed
>
> Bug description:
> Running 14.04 (beta) with Kernel 3.13.0-17-generic
>
> I've encountered a strange and reproducible error with the
> iwlwifi-7260-8.ucode firmware.
>
> This laptop is a Dell XPS 12 (haswell). With the -8 firmware, it will
> connect fine to wifi for 30 or 40 mins at a time, then will start
> dropping connections repeatedly. Even modprobe -r unloading and
> reloading doesn't fix the issue, only a reboot will temporarily solve
> it for 40 mins at a time.
>
> Moreover, here is what's strange, is during these episodes of
> disconnection it seems to affect the actual router (2Wire), as the
> other devices in the house will also start to have issues (very slow
> connections, limited range,etc). Once I reboot this laptop everything
> and all devices will return to normal.
>
> This issue has been fixed by me manually removing the -8 firware from
> /lib/firmware and letting the -7 firmware load instead. Since that has
> been done there has not been a single issue of this happening (now
> going on 4 days).
>
> let me know if there is any other information you would like me to
> provide.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 14.04
> Package: linux-firmware 1.126
> ProcVersionSignature: Ubuntu 3.13.0-17.37-generic 3.13.6
> Uname: Linux 3.13.0-17-generic x86_64
> ApportVersion: 2.13.3-0ubuntu1
> Architecture: amd64
> CurrentDesktop: Unity
> Date: Mon Mar 17 08:13:25 2014
> Dependencies:
>
> EcryptfsInUse: Yes
> InstallationDate: Installed on 2014-03-07 (9 days ago)
> InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140307)
> PackageArchitecture: all
> SourcePackage: linux-firmware
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1293569/+subscriptions

[Sam Lin (itrs-lin)]

same issue, my AP:

ASUS, RT-N12HP

use 802.11g/n mode, 2.4G channels
2014/5/7 上午1:55 於 "Barry" <email address hidden> 寫道：

> Hi Emmanuel.
>
> Original submitter here:
>
> Unfortunately I haven't had time to try to capture packets during
> failure, but I'm open to doing that (hopefully today or tomorrow).
>
> Here are the details for my AP:
>
> Overview: This is one of the standard ATT Uverse Modems. No
> specific config changes (besides password), otherwise stock standard.
> Manufacturer: Pace Plc
> Model: 3800HGV-B
> Software Version: 6.9.1.42-plus.tm
> Wireless Mode: 802.11b/g
> Auth Type: WPA-PSK (TKIP) and WPA2-PSK (AES)
> DTIM Period: 1
> Rate: 54Mbps
>
> Others in thread who are affected, please post an overview of your AP so
> that a profile can be built.
>
> Regards,
> Barry
>
> On May 6, 2014, at 12:00 PM, Emmanuel Grumbach <email address hidden>
> wrote:
>
> > Daniel, if you don't have issues, this is not very useful...
> >
> > --
> > You received this bug notification because you are subscribed to the bug
> > report.
> > https://bugs.launchpad.net/bugs/1293569
> >
> > Title:
> > iwlwifi-7260-8.ucode causes network disconnections problems
> >
> > Status in “linux-firmware” package in Ubuntu:
> > Confirmed
> > Status in “linux-firmware” source package in Precise:
> > Fix Committed
> > Status in “linux-firmware” source package in Trusty:
> > Fix Committed
> >
> > Bug description:
> > Running 14.04 (beta) with Kernel 3.13.0-17-generic
> >
> > I've encountered a strange and reproducible error with the
> > iwlwifi-7260-8.ucode firmware.
> >
> > This laptop is a Dell XPS 12 (haswell). With the -8 firmware, it will
> > connect fine to wifi for 30 or 40 mins at a time, then will start
> > dropping connections repeatedly. Even modprobe -r unloading and
> > reloading doesn't fix the issue, only a reboot will temporarily solve
> > it for 40 mins at a time.
> >
> > Moreover, here is what's strange, is during these episodes of
> > disconnection it seems to affect the actual router (2Wire), as the
> > other devices in the house will also start to have issues (very slow
> > connections, limited range,etc). Once I reboot this laptop everything
> > and all devices will return to normal.
> >
> > This issue has been fixed by me manually removing the -8 firware from
> > /lib/firmware and letting the -7 firmware load instead. Since that has
> > been done there has not been a single issue of this happening (now
> > going on 4 days).
> >
> > let me know if there is any other information you would like me to
> > provide.
> >
> > ProblemType: Bug
> > DistroRelease: Ubuntu 14.04
> > Package: linux-firmware 1.126
> > ProcVersionSignature: Ubuntu 3.13.0-17.37-generic 3.13.6
> > Uname: Linux 3.13.0-17-generic x86_64
> > ApportVersion: 2.13.3-0ubuntu1
> > Architecture: amd64
> > CurrentDesktop: Unity
> > Date: Mon Mar 17 08:13:25 2014
> > Dependencies:
> >
> > EcryptfsInUse: Yes
> > InstallationDate: Installed on 2014-03-07 (9 days ago)
> > InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64
> (20140307)
> > PackageA...

[Emmanuel Grumbach (egrumbach)]

Ok - I'd like to see the dmesg output of someone who has the uAPSD fix.

If possible, I'd like to test this:

diff --git a/drivers/net/wireless/iwlwifi/mvm/power.c b/drivers/net/wireless/iwlwifi/mvm/power.c
index 550824a..07b8653 100644
--- a/drivers/net/wireless/iwlwifi/mvm/power.c
+++ b/drivers/net/wireless/iwlwifi/mvm/power.c
@@ -610,6 +610,7 @@ int iwl_mvm_enable_beacon_filter(struct iwl_mvm *mvm,
            vif->type != NL80211_IFTYPE_STATION || vif->p2p)
                return 0;

+ return 0;
        iwl_mvm_beacon_filter_set_cqm_params(mvm, vif, &cmd);
        iwl_mvm_beacon_filter_debugfs_parameters(vif, &cmd);
        ret = iwl_mvm_beacon_filter_send_cmd(mvm, &cmd);

Can someone test this?
We are having trouble to reproduce here.

[Seth Forshee (sforshee)]

I made a build for testing the change in comment #29, which is available at http://people.canonical.com/~sforshee/lp1293569/linux-3.13.0-26.48+lp1293569v201405121159/.

Emmanuel: I assume the dmesg need to be from a device experiencing problems? If not I can get one for you.

[Adam Conrad (adconrad)]

The verification of the Stable Release Update for linux-firmware has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux-firmware - 1.127.2

---------------
linux-firmware (1.127.2) trusty; urgency=medium

  * UBUNTU: Remove iwlwifi-7260-8.ucode for regression
    -LP: #1293569

linux-firmware (1.127.1) trusty; urgency=medium

  * Add firmware file to support Intel 7265 (Stone Peak) for linux v3.13+
    http://wireless.kernel.org/en/users/Drivers/iwlwifi?action=AttachFile&do=get&target=iwlwifi-7265-ucode-22.24.8.0.tgz
    -LP: #1188092
 -- Tim Gardner <email address hidden> Mon, 05 May 2014 15:00:39 -0600

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux-firmware - 1.79.14

---------------
linux-firmware (1.79.14) precise; urgency=medium

  * Remove iwlwifi-7260-8.ucode for regression
    The -8 API appears to cause regression on Haswell.
    -LP: #1293569

linux-firmware (1.79.13) precise; urgency=medium

  * Add firmware file to support Intel 7265 (Stone Peak) for linux v3.13+ (linux-lts-trusty)
    http://wireless.kernel.org/en/users/Drivers/iwlwifi?action=AttachFile&do=get&target=iwlwifi-7265-ucode-22.24.8.0.tgz
    -LP: #1188092
 -- Tim Gardner <email address hidden> Mon, 05 May 2014 14:46:02 -0600

[Emmanuel Grumbach (egrumbach)]

Yes Seth - I was meaning the dmesg output from a machine experiencing the problem.

[Simone Bordet (simone-bordet)]

I wanted to confirm that I was suffering of this bug, but reverting to the -7 (22.1.7.0) firmware solved the issue for me on AC 7260.

When I was experiencing the problem the firmware in use was 22.24.8.0, and my dmesg reported what reported in message #8 above. Turning off power save did not make any difference.

My AP is a Netgear DGN 3500 on channel 11, 2.4 GHz, configured with "Up to 300 Mbps" mode, so 802.11n.

[Emmanuel Grumbach (egrumbach)]

I have collected all the APs' reference and communicated them to our testing team. We will try to reproduce internally.

[Emmanuel Grumbach (egrumbach)]

Can someone tell me what are the IWLWIFI related CONFIG options enabled?

I'd like to make sure that IWLWIFI_BCAST_FILTERING is not enabled.

[Emmanuel Grumbach (egrumbach)]

I just checked here: http://kernel.ubuntu.com/~kernel-ppa/configs/trusty/i386-config.flavour.generic

seems ok

[Arthur Zalevsky (aozalevsky)]

I'm also affected by this bug:

[ 3.252469] iwlwifi 0000:02:00.0: loaded firmware version 22.24.8.0 op_mode iwlmvm

Sent debug information collected by wifi-debug to Seth Forshee.

Additional information about my AP:

TP-Link TL1043WND with OpenWRT
Mode: Master | SSID: xxx
BSSID: XX:XX:XX:XX:XX:XX | Encryption: WPA2 PSK (CCMP)
Channel: 5 (2.432 GHz) | Tx-Power: 20 dBm
Signal: -48 dBm | Noise: -95 dBm
Bitrate: 48.7 Mbit/s | Country: RU

Mode 802.11g+n
HT mode 40MHz 2nd channel above

[Emmanuel Grumbach (egrumbach)]

So I was wrong - 3.13 can get -9.ucode. I though 3.13 was too old, but it is ok and I touch tested it.

Can someone check this?

Just need to update the iwl-7000.c and update the firmware.

[Emmanuel Grumbach (egrumbach)]

Note also this similar bug: https://bugzilla.redhat.com/show_bug.cgi?id=1087717

[Jason Gerard DeRose (jderose)]

Emmanuel,

I'll test the -9.ucode ASAP. Are there any bits from 3.14 or 3.15 that should be backported in order for the Ubuntu 3.13 kernel to work best with the -9.ucode?

System76 customers are experiencing a lot of problems with 7260/3160 cards, and so we're keen on getting -9.ucode in a linux-firmare SRU, assuming that's the correct fix.

Interestingly, -8 seemed to work much better on our products than -7 does, which I guess could be related to a lot of factors (different antenna designs, different card revisions, different APs, etc). For us, reverting to -7 seems to create problems similar to those that people are here attributing to -8.

FWIW, on this 7260 (rev 73) I'm testing:

Device: 04:00.0
Class: Network controller [0280]
Vendor: Intel Corporation [8086]
Device: Wireless 7260 [08b1]
SVendor: Intel Corporation [8086]
SDevice: Dual Band Wireless-AC 7260 [4070]
Rev: 73

I'm frequently getting disconnects like this, on both the G and AC routers I test with regularly:

[ 4917.138750] wlan0: deauthenticated from 00:21:29:71:0a:c1 (Reason: 7)
[ 4917.154768] cfg80211: Calling CRDA to update world regulatory domain
[ 4917.155185] wlan0: authenticate with 00:21:29:71:0a:c1
[ 4917.156421] wlan0: send auth to 00:21:29:71:0a:c1 (try 1/3)
[ 4917.158939] wlan0: authenticated
[ 4917.159211] iwlwifi 0000:04:00.0 wlan0: disabling HT as WMM/QoS is not supported by the AP
[ 4917.159220] iwlwifi 0000:04:00.0 wlan0: disabling VHT as WMM/QoS is not supported by the AP
[ 4917.161249] cfg80211: World regulatory domain updated:
[ 4917.161256] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 4917.161261] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 4917.161265] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 4917.161269] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 4917.161272] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 4917.161275] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 4917.162508] wlan0: associate with 00:21:29:71:0a:c1 (try 1/3)
[ 4917.166334] wlan0: RX AssocResp from 00:21:29:71:0a:c1 (capab=0x411 status=0 aid=4)
[ 4917.167410] wlan0: associated
[18596.000601] cfg80211: Calling CRDA to update world regulatory domain
[18596.007368] cfg80211: World regulatory domain updated:
[18596.007375] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[18596.007380] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[18596.007385] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[18596.007388] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[18596.007391] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[18596.007395] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[18599.790518] wlan0: authenticate with 00:21:29:71:0a:c1
[18599.791521] wlan0: send auth to 00:21:29:71:0a:c1 (try 1/3)
[18599.844059] wlan0: send auth to 00:21:29:71:0a:c1 (try 2/3)
[18599.899353] wlan0: send auth to 00:21:29:71:0a:c1 (try 3/3)
[18599.954640] wlan0: authenticat...

[Seth Forshee (sforshee)]

Emmanuel: I can do a test build if you let me know exactly what needs to be changed. Is it just bumping IWL7260_UCODE_API_MAX to 9?

[Jason Gerard DeRose (jderose)]

Seth,

Just finish building. All I did was bump IWL7260_UCODE_API_MAX, IWL3160_UCODE_API_MAX to 9.

Loaded -9 firmware correctly, seems to be working fine so far:

[ 2.936156] iwlwifi 0000:04:00.0: loaded firmware version 23.214.9.0 op_mode

[Seth Forshee (sforshee)]

On Fri, May 16, 2014 at 06:06:02PM -0000, Jason Gerard DeRose wrote:
> Seth,
>
> Just finish building. All I did was bump IWL7260_UCODE_API_MAX,
> IWL3160_UCODE_API_MAX to 9.
>
> Loaded -9 firmware correctly, seems to be working fine so far:
>
> [ 2.936156] iwlwifi 0000:04:00.0: loaded firmware version 23.214.9.0
> op_mode

Yeah, that's all I figure is needed, but I wanted to get Emmanuel's
confirmation.

I did go ahead and make a build though, so if anyone wants to go ahead
and try it you can get it here:

 http://people.canonical.com/~sforshee/lp1293569/linux-3.13.0-27.50+lp1293569v201405151213/

You'll also need to grab iwlwifi-7260-9.ucode (from the same location)
and copy it to /lib/firmware. I'll want to have as much testing as
possible before really considering bringing this into trusty though,
both hardware which did have problems with -8 and hardware which did
not.

[Emmanuel Grumbach (egrumbach)]

Ok I think I have an idea of what is going on now:

Seth, can we have a build with this:

diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
index cd6ea2e..17c097d 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
@@ -619,7 +619,7 @@ static int iwl_mvm_mac_add_interface(struct ieee80211_hw *hw,
        if (ret)
                goto out_remove_mac;

- if (!mvm->bf_allowed_vif &&
+ if (!mvm->bf_allowed_vif && false &&
            vif->type == NL80211_IFTYPE_STATION && !vif->p2p &&
            mvm->fw->ucode_capa.flags & IWL_UCODE_TLV_FLAGS_BF_UPDATED){
                mvm->bf_allowed_vif = mvmvif;

thanks

[Emmanuel Grumbach (egrumbach)]

Seth,

I think the patch above is safe for 3.13. I don't know how to upstream that since it is fixed in 3.15 and this basically means that I need a patch in 3.13 / 3.14 which won't be in Linus's tree ever... But that's just a dev process issue. From a technical POV, this patch should go in 3.13.

It explains why -7.ucode works I haven't checked, but I guess that -7.ucode doesn't support the feature I disable in my patch. This code (power code) has been heavily reworked in 3.15 and other users reported that the issue doesn't reproduce on 3.15 even with 22.24.8.0 firmware. So, I'd say that I think I'd like to have the -9.ucode patch and the patch from comment $47.

As for your comment #45 (why launchpad doesn't have a reply button :)) - yes you are right. You only need to change the define.

I hope we'll be able to get some testing... I really want to solve / close / forget this issue :)

[Seth Forshee (sforshee)]

I've prepared a test build with the patch from comment #47, available at the link below:

http://people.canonical.com/~sforshee/lp1293569/linux-3.13.0-27.50+lp1293569v201405190854/

Please be sure to test this with the -8 firmware. I've placed a copy of the file (iwlwifi-7260-8.ucode) at the same location for any who may no longer have it. This file needs to be saved to the /lib/firmware directory. Thanks!

[Emmanuel Grumbach (egrumbach)]

Patch has been sent to stable and Greg said he would pick it up:

http://www.spinics.net/lists/stable/msg46075.html

I have other reports saying that the patch doesn't all the issues, but it should clean quite a few problems.
Seth - what supplicant do we have in 14.04?
There might be supplicant issues too.

[Seth Forshee (sforshee)]

On Mon, May 19, 2014 at 08:54:02PM -0000, Emmanuel Grumbach wrote:
> Patch has been sent to stable and Greg said he would pick it up:
>
> http://www.spinics.net/lists/stable/msg46075.html

Thanks. The 3.13 maintainer should pick it up too in that case, though
I'll give him a poke to make sure.

> I have other reports saying that the patch doesn't all the issues, but it should clean quite a few problems.
> Seth - what supplicant do we have in 14.04?

$ wpa_supplicant -v
wpa_supplicant v2.1

[Emmanuel Grumbach (egrumbach)]

I know there are tons of issues with this supplicant. These issues were fixed by a bunch of people.
Please consider downgrading the supplicant or taking the latest

[Jason Gerard DeRose (jderose)]

Emmanuel, maybe I'm missing something obvious, but isn't wpasupplicant 2.1 already the newest version?

http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=blob_plain;f=wpa_supplicant/ChangeLog

[Jason Gerard DeRose (jderose)]

Scott,

I've been testing your kernel build with the iwlwifi-7260-8.ucode firmware (22.24.8.0), and so far so good. Although the particular problem I've been encountering sometimes takes a day or two to occur, so I'll let you know how it fairs after a few more days of use.

However, I have confirmed that my disconnect problem still occurs with the -8 and -9 firmware, when nothing else is changed in the Ubuntu 3.13 kernel (except for the max API version when testing -9). So hopefully disabling the beacon filtering will do the trick.

Thanks for the build!

[Emmanuel Grumbach (egrumbach)]

Good.
Thank you for testing.

@Seth - I think you should take

commit 12d423e816c69b0b4457bc047dda9a0a1c1a53c1
Author: Ilan Peer <email address hidden>
Date: Tue Dec 24 22:08:14 2013 +0200

    iwlwifi: mvm: Add a missed beacons threshold

in 3.13.

[Seth Forshee (sforshee)]

I've made sure that "iwlwifi: mvm: disable beacon filtering" will be included in the next 3.13.x.y release. Since we've already reverted the firmware as a workaround I'll just wait for that to arrive in trusty from 3.13.x.y.

Emmanuel: can you describe specifically what problem "iwlwifi: mvm: Add a missed beacons threshold" fixes? The rules are the same as for any other stable kernel, including the "it must fix a real bug that bothers people" part. While I understand what the patch is doing, the changelog doesn't really answer the question of what user-visible problem it fixes. Thanks!

[Jason Gerard DeRose (jderose)]

Seth,

Progress report from testing your patched 3.13.0-27 build... I made it through almost 5 days of continuous use without a disconnect. Even though I did eventually get a disconnect, it seems to happen far less frequently with the -8 firmware when combined with the disabled beacon filtering.

Now that I'm running the official 3.13.0-29 build, I'm getting very frequent disconnects again. Often times I can't make it more than a half hour without a disconnect. So your proposed build definitely makes a difference, at least with the 7260 and the two WiFi routers I test against.

Also, apologies for mistyping your name earlier. Was flipping back and forth between multiple bug reports, one where a "Scott" was commenting :)

[Emmanuel Grumbach (egrumbach)]

@Seth,

This patch adds a grace period before disconnecting from the AP if we didn't hear the beacons. This problem (not hearing beacons) was critical in our tests in P2P Client flows, less in BSS, but still.
It avoids disconnections by giving the firmware more change to catch up on beacons before it tells us (driver) to disconnect.

[Jason Gerard DeRose (jderose)]

Seth, I noticed that the linux-firmware package in proposed (1.127.3) doesn't have the 7260 -8 firmware, but does have the 3160 -8 firmware? Is this intentional?

$ dpkg -L linux-firmware | egrep "7260|3160"
/lib/firmware/iwlwifi-3160-8.ucode
/lib/firmware/iwlwifi-7260-7.ucode
/lib/firmware/iwlwifi-7260-9.ucode
/lib/firmware/iwlwifi-3160-9.ucode
/lib/firmware/iwlwifi-3160-7.ucode

Also, IWL7260_UCODE_API_MAX seems to still be set at 8 as the -9 firmware

[ 3.170224] iwlwifi 0000:04:00.0: loaded firmware version 22.1.7.0 op_mode iwlmvm

[Seth Forshee (sforshee)]

On Thu, Jun 19, 2014 at 03:23:44PM -0000, Jason Gerard DeRose wrote:
> Seth, I noticed that the linux-firmware package in proposed (1.127.3)
> doesn't have the 7260 -8 firmware, but does have the 3160 -8 firmware?
> Is this intentional?
>
> $ dpkg -L linux-firmware | egrep "7260|3160"
> /lib/firmware/iwlwifi-3160-8.ucode
> /lib/firmware/iwlwifi-7260-7.ucode
> /lib/firmware/iwlwifi-7260-9.ucode
> /lib/firmware/iwlwifi-3160-9.ucode
> /lib/firmware/iwlwifi-3160-7.ucode

I didn't think that there were any reports of issues with 3160, but now
I see that you did mention it in comment #42. At this point we've
already queued up the patch to disable beacon filtering in 3.13, so I'm
not sure that it makes sense to pull out the -8 firmware for 3160 at
this point.

Also just a note that we do plan to reintroduce the -8 firmare for 7260
once the kernel with the beacon filtering patch gets relesed.

> Also, IWL7260_UCODE_API_MAX seems to still be set at 8 as the -9
> firmware

Yep. Right now we aren't planning to bump 3.13 to use -9, but in the
future we'll have HWE kernels which will use it, so Tim went ahead and
included it when he updated linux-firmware recently.

[[e-mail] (mike-papersolve)]

Is this patch in the most recent -30 kernel? If not when might it make it in?

[JaSauders (jasauders)]

I mirror Mike's question. As far as I can understand, I'm on the 7 firmware and fully updated as of today July 2nd. Yet I've had about 12 disconnects today, two of which took place as I read through this lengthy bug report.

jason@JSXPS:~$ dmesg | grep "iwlwifi .* loaded firmware version"
[ 4.427618] iwlwifi 0000:02:00.0: loaded firmware version 22.1.7.0 op_mode iwlmvm

jason@JSXPS:~$ uname -r
3.13.0-30-generic

Running a one month old Dell XPS 13 with Ubuntu 14.04.

Was this fixed and released and I somehow missed it via Software Updater?

[Luis Henriques (henrix)]

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-trusty' to 'verification-done-trusty'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

[Seth Forshee (sforshee)]

To clarify: the kernel in -proposed contains the changes which should fix the problems with the -8 firmware. So please test that kernel with the -8 firmware and verify that the problems previously seen with the -8 firmware are fixed. Thanks!

[Jason Gerard DeRose (jderose)]

I've been testing the proposed trusty kernel (3.13.0-32.56) with the iwlwifi-7260-8.ucode firmware, and so far so good:

$ dmesg | grep 22.24.8.0
[ 2.840202] iwlwifi 0000:04:00.0: loaded firmware version 22.24.8.0 op_mode iwlmvm

Experience is similar to when I was testing Seth's patched kernel from a while back: disconnects happen far, far less frequently, and overall performance and stability seem improved.

Assuming no one finds any problems, will a new linux-firmware package containing iwlwifi-7260-8.ucode land at the same time as the 3.13.0-32 kernel?

[Jason Gerard DeRose (jderose)]

@jasauders: you'll need to download iwlwifi-7260-ucode-22.24.8.0.tgz from here:

http://wireless.kernel.org/en/users/Drivers/iwlwifi

Extract the tarball, then copy iwlwifi-7260-8.ucode into /lib/firmware, then reboot, check dmesg to make sure it loaded the correct version:

$ dmesg | grep iwlwifi

The current linux-firmware package doesn't include the iwlwifi-7260-8.ucode.

[Jason Gerard DeRose (jderose)]

I put 3.13.0-32.56 with the iwlwifi-7260-8.ucode through around 32 hours of continuous testing on a 7260 WiFi card and encountered zero disconnects.

I tested with a mix of both sustained high network utilization and long periods of inactivity, both when running on battery and when running on AC, so I feel this fix is solid,

As such, I changed the tags:
verification-needed-trusty => verification-done-trusty

I've also been casually testing this on a 2nd machine (my daily driver), and have likewise encountered zero disconnects. Although this testing wasn't at all systematic, I was testing against two different brands of 802.11ac routers.

[Tim Gardner (timg-tpi)]

Uploaded 1.127.5 which restores iwlwifi-7260-8.ucode

[Chris J Arges (arges)]

Hello Barry, or anyone else affected,

Accepted linux-firmware into trusty-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/linux-firmware/1.127.5 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Jason Gerard DeRose (jderose)]

As far as I can tell, there is no difference between using the proposed linux-firmware (1.127.5) package vs the stable linux-firmware (1.127.4) package plus a manually installed /lib/firmware/iwlwifi-7260-8.ucode file, a combination that has produced favorable results in my previous testing.

I confirmed that the sha1sum of the iwlwifi-7260-8.ucode file delivered in the linux-firmware (1.127.5) packaged matches the sha1sum of the iwlwifi-7260-8.ucode file I had manually installed for testing:

$ sha1sum /lib/firmware/iwlwifi-7260-8.ucode
7cf634ec52887c4dd6c87241e3b6ae862c7c0e0e /lib/firmware/iwlwifi-7260-8.ucode

As such, I'm changing the tags:
verification-needed => verification-done

[Jason Gerard DeRose (jderose)]

Hmm, I guess a "verification-needed" tag wasn't actually present, despite the (automated?) comment #69.

Regardless, I added a "verification-done" tag for good measure :D

[JaSauders (jasauders)]

@ Jason Gerard DeRose

Thanks for your tip, but I'm a little confused. I ran grep before I downloaded/extracted anything as you recommended above, and I got:

jason@JSXPS:~$ dmesg | grep iwlwifi
[ 4.927130] iwlwifi 0000:02:00.0: irq 60 for MSI/MSI-X
[ 5.010242] iwlwifi 0000:02:00.0: loaded firmware version 22.24.8.0 op_mode iwlmvm
[ 5.082853] iwlwifi 0000:02:00.0: Detected Intel(R) Dual Band Wireless AC 7260, REV=0x144
[ 5.083253] iwlwifi 0000:02:00.0: L1 Enabled; Disabling L0S
[ 5.083514] iwlwifi 0000:02:00.0: L1 Enabled; Disabling L0S
[ 5.862187] iwlwifi 0000:02:00.0: L1 Enabled; Disabling L0S
[ 5.862437] iwlwifi 0000:02:00.0: L1 Enabled; Disabling L0S
[ 945.229994] iwlwifi 0000:02:00.0: L1 Enabled; Disabling L0S
[ 945.230254] iwlwifi 0000:02:00.0: L1 Enabled; Disabling L0S
[ 1720.447091] iwlwifi 0000:02:00.0: L1 Enabled; Disabling L0S
[ 1720.447348] iwlwifi 0000:02:00.0: L1 Enabled; Disabling L0S

Does the line "[ 5.010242] iwlwifi 0000:02:00.0: loaded firmware version 22.24.8.0 op_mode iwlmvm" not indicate that I am on the newer firmware?

I came back here after I started having issues here at home. I must have disconnected from my home router six times this evening while I'm sitting across the room from it. I had proposed enabled so I could pull down Unity 7.2.2 for an unrelated bug test, so that line with the 8 entry makes me wonder if I got the update without realizing it. What concerns me is if I *did* get the update, then this clearly is not fixed... since, after all, if it were fixed I wouldn't have lost connection so many times tonight (I tested other laptops and had no issue. In one instance, my laptop disconnected while others were all connected and actively pulling large ISO files wirelessly from my file server). Sadly, I even just now lost wireless again as I was typing this...

Before I begin tinkering with switching this or that I wanted to get some confirmation here by the folks who clearly know more so I can be accurate with what I'm doing. Thanks!

[JaSauders (jasauders)]

I just ran sha1sum against the download in that link above as well as the 7260 8.ucode that is currently in /lib/firmware and confirm they match. It seems as if I am indeed running the latest patch that is in proposed after all. As a result, something is still wildly wrong, or else I did something wrong... and believe me I'd rather know I goofed than know that this bug is still not fixed, so by all means fire away if you think I goofed somewhere. But all I can say is this very laptop is the only one with continual disconnects while everything else works flawlessly.

What's funny is for several days I had no issues at home whatsoever. I had actually forgotten that this was even a problem until I suddenly couldn't get any work done or transfer anything of significant size (200 MB+) from my server without the connection tanking altogether.

P.S. - As I went to hit "post comment" as I got done typing this message I lost connection yet again. I then ran a cat against syslog and copied everything over the last few minutes into a pastebin in case it helps.

http://paste.ubuntu.com/7828318/

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux-firmware - 1.127.5

---------------
linux-firmware (1.127.5) trusty; urgency=medium

  * Restore iwlwifi-7260-8.ucode. Testing in http://bugs.launchpad.net/bugs/1293569
    comment #67 indicates that the addition of kernel patch 'iwlwifi: mvm: disable
    beacon filtering' is sufficient to re-enable this version of the ucode.
    -LP: #1293569
 -- Tim Gardner <email address hidden> Sat, 12 Jul 2014 07:47:54 +0100

[Sergio (sergiorussia)]

just updated firmware to 1.127.5, while running kernel 3.13.0-32.57
but "modinfo iwlwifi" tells me that its using iwlwifi-7260-7.ucode
or I should check it in the other way?
"dmesg | grep iwlwifi" tells exactly the same as for @jasauders in comment #72

[Seth Forshee (sforshee)]

On Wed, Jul 23, 2014 at 06:13:37PM -0000, Sergio wrote:
> just updated firmware to 1.127.5, while running kernel 3.13.0-32.57
> but "modinfo iwlwifi" tells me that its using iwlwifi-7260-7.ucode
> or I should check it in the other way?
> "dmesg | grep iwlwifi" tells exactly the same as for @jasauders in comment #72

See earlier in this bug, starting with comment #15. If dmesg says you
have 22.24.8.0 then you have the -8 firmware.

[JaSauders (jasauders)]

Well, that's disappointing. As per the dmesg, I am indeed running 22.24.8.0, fully updated, and I lost wireless in an hour's time.

This bug is not fixed.

[Emmanuel Grumbach (egrumbach)]

Are you sure you have the right kernel?
If you delete -8.ucode and fallback to -7.ucode, does the problem disappear?

[JaSauders (jasauders)]

3.13.0-32-generic

[52184.190874] iwlwifi 0000:02:00.0: Loaded firmware version: 22.24.8.0

I just checked and I have no updates available. In other news I let my laptop run idle throughout last night pinging a weather site every 5 seconds. I didn't drop connection once. I'm going to use the laptop throughout today and see if it comes up again.

What do I do to fall back to -7? Just delete the -8 file as (I believe) mentioned above?

[Leith Bade (ljbade)]

Is this issue related to the issue I am having with the Intel 7260 WiFi on Ubuntu 14.04 Server?

I have found that on 11n mode the connection is very slow.

The latency to WiFi router varies wildly between 1 to 100ms. Also using SSH over the connection is very laggy and slow.

If I disable 11n mode (fall back to g) the latency becomes a stable 0.6ms and SSH is fluid.

My computer:
Mobo: Asus H81M-E with BIOS 2001
CPU: Intel Celeron G1840T
RAM: 2x2GB DDR3 Patriot
HDD: WD Red 1TB
WiFi: Intel Wireless 7620 mPCIe on PCIe adapter plugged into x2 lane (on MCH)
WiFi router: NetComm Liberty Series 3G18WV - 3G Wireless N300 VoIP Router

Also location is Australia and the WiFi is on channel 11 in case that matters.

I am using latest linux-firmware (1.127.5) with firmware version 22.24.8.0

Also the connection sometimes stops responding completely.

[Marcel Miguel (marcel-miguel)]

With kernel 3.13.0.32 (using trusty-proposed) and firmware 22.24.8.0. Having lots of disconnections, normally not recovering connection.
With 3.13.0.30, firmware 22.1.7.0 maybe the same amount of disconnections, but normally wifi recovers after a minut.

[weer (romeo8881)]

Linux h4f 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
on Sager laptop
iwlwifi-7260-9.ucode
I have the same issue with frequent reconnect.

[Seth Forshee (sforshee)]

For those of you continuing to have problems, please open new bugs by running 'ubuntu-bug linux' in a terminal. Since the problems originally reported in this bug are verified to have been fixed we need to investigate remaining problems separately. Feel free to subscribe me to the new bug reports. Thanks!

[JaSauders (jasauders)]

Would it be okay to have the new bug linked here? (as in, this bug is fixed but if you're still having problems follow bug #12345678?) I'd like to be the one to report the bug, but given that I'm on the brink of swapping this laptop with another XPS 13 from Dell that doesn't have the problematic 7260 chip (sorry, but with no anticipation of a quick fix and given this is my work laptop, I have little choice), I likely won't be of additional troubleshooting assistance in a matter of a week. I would still like to follow the bug though, as I'm sure most users subscribed to this bug would as it seems the majority of users are still affected...

[Seth Forshee (sforshee)]

On Mon, Jul 28, 2014 at 01:29:48PM -0000, JaSauders wrote:
> Would it be okay to have the new bug linked here? (as in, this bug is
> fixed but if you're still having problems follow bug #12345678?) I'd
> like to be the one to report the bug, but given that I'm on the brink of
> swapping this laptop with another XPS 13 from Dell that doesn't have the
> problematic 7260 chip (sorry, but with no anticipation of a quick fix
> and given this is my work laptop, I have little choice), I likely won't
> be of additional troubleshooting assistance in a matter of a week. I
> would still like to follow the bug though, as I'm sure most users
> subscribed to this bug would as it seems the majority of users are still
> affected...

It's often difficult to tell if two similar problems really have the
same root cause (as evidenced by this bug where the problem is fixed for
some but not for others). So I really think it's better for everyone to
file a separate report so we can collect inidividual hardware
information and logs, then if we later determine they're really the same
problem we can mark them all as duplicates of one bug.

[JaSauders (jasauders)]

Thanks, Seth. I wasn't necessarily suggesting that the to-be-filed bug is a 'dup', but moreso just acknowledging the fact that a lot of users as mentioned above still have problems. If these users don't have a direct link to click on the new report, subscribe and mark as 'affects me too', then the alternative is to dig around Launchpad in order to find the new bug. I was moreso just suggesting an easier way for the users above to track down and follow the new bug, that's all. :D

[Seth Forshee (sforshee)]

On Mon, Jul 28, 2014 at 02:07:58PM -0000, JaSauders wrote:
> Thanks, Seth. I wasn't necessarily suggesting that the to-be-filed bug
> is a 'dup', but moreso just acknowledging the fact that a lot of users
> as mentioned above still have problems. If these users don't have a
> direct link to click on the new report, subscribe and mark as 'affects
> me too', then the alternative is to dig around Launchpad in order to
> find the new bug. I was moreso just suggesting an easier way for the
> users above to track down and follow the new bug, that's all. :D

What I was trying to say is that each person still having problems
should file separate bug reports rather than all clicking "me too" on a
single bug report. Even when the symptoms are similar there can be
multiple root causes, and when someone just clicks "me too" it doesn't
give us any information to help determine whether or not it's really the
same problem. So it's better to file a new bug and then mark it as a
duplicate later if we find out it's the exact same problem as in another
bug report.

[Emmanuel Grumbach (egrumbach)]

you may want to look at https://bugzilla.kernel.org/show_bug.cgi?id=78101
In this case, the bug is in the AP.

[JaSauders (jasauders)]

Eh, that'd be something different then... Unless Meraki, Linksys, Dlink, Netgear, and Aruba all have the same bug in their APs. :(

[Emmanuel Grumbach (egrumbach)]

One more thing you can do is to try a newer kernel + newer firmware.
3.16-rc6 would be a good choice or at least 3.15.X

You can also work with backport which will allow you to stay with your current stable and yet to have the latest wireless stack.

[Seth Forshee (sforshee)]

On Mon, Jul 28, 2014 at 04:23:13PM -0000, JaSauders wrote:
> Eh, that'd be something different then... Unless Meraki, Linksys, Dlink,
> Netgear, and Aruba all have the same bug in their APs. :(

Please, just run 'ubuntu-bug linux' to file a bug and subscribe me.
Everyone else having problems do the same. I'll be making a point of
going through these bugs to work on resolving the issues people are
still seeing with 7260 wireless.

[Marcel Miguel (marcel-miguel)]

Just added a new bug #1349572 and suscribed Seth Forshee.

[Steve Breen (sbreen)]

Added a new https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1354975 related to the same issue. Subscribing Seth.

[Enkouyami (furyhamster)]

I have this issue on Linux Mint 17, which is built on Ubuntu Trusty 14.04, and that fix hasn't been applied to LM yet.

[Enkouyami (furyhamster)]

Added a new bug #1373552 and also subscribed Seth.

[Andrey Arapov (andrey-arapov)]

Possibly related to the https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1371425

try to downgrade to 1.127.4 at least or less than 1.127.4, likely the bug was introduced with linux-firmware 1.127.5

[ehoxha (kasper-lyster)]

I use Ubuntu 14.04 with 3.13.0-40-generic kernel and I have had the exact same problems mentioned in this foroum, hilarious high ping, and a drop in network signal. I incountered them all within 15-20 minutes after booting into the system. I installed a new network card today from a iwlwifi-7260-8 using.ucode firmware. to a Qualcomm Atheros QCA9565 / AR9565 Wireless Network A card and for the last 15 hours I haven't had any trouble with it.
I will report back in about one week to let you know if there are any changes.

[Oleksandr (s-oleksandr)]

This bug has appeared again in Ubuntu 14.10 after upgrade from 14.04. In my case the problem with Intel Wireless-N 7260 driver on my Lenovo L440 disrupts the wireless transmission of TP-Link WR74ND.

[JaSauders (jasauders)]

It sounds like the 7260 wireless card is an all around headache for pretty much any operating system. To date I have heard of a great deal of users with issues on Windows 7, 8, 8.1, Ubuntu, Mint, Fedora, Arch, and Debian. Perhaps others, but those are the specific ones I recall.

There's a lengthy discussion on the Intel forums... not that it helps out much for this specific issue, but I figured it's worth mentioning that we (us Linux users) are not alone with 7260 woes.

https://communities.intel.com/thread/47983?start=0&tstart=0

[Sergio (sergiorussia)]

same here, but seems like the bug was appeared quiet recently, as I had got stable connection until recent updates. I'm using Ubuntu 14.04 with up-to-date packages

[Sergio (sergiorussia)]

I think the only problem-related package updates I've made were linux-firmware (1.127.10 => 1.127.11) and also linux kernel (3.13.0-43.72 => 3.13.0-44.73). I'll try to revert them back and report if it helps

[Sergio (sergiorussia)]

looks like reverting to the older kernel helped, connection is quiet stable back again. the only related change in newer kernel was the fix of the bug #1393317.

[Ludek (lusmo)]

Same here, Ubuntu 14.04 and 14.10 64 bit, ntb Acer & Lenovo the same problem.

[Sergio Daniel Carvalho Canuto (sergiocomputacao-deactivatedaccount)]

Same here, Ubuntu 14.04 and 14.10 64 bit, dell vostro 5470.
I found a solution: BURN THIS MOTHERFRACKING CARD and install a new one.

[Emmanuel Grumbach (egrumbach)]

There is an easier solution: update the driver.
3.13 is old and it uses and old firmware.
You can update your driver with the help of backport and it will dramatically improve the behavior of WiFi.
I also tested 3.16 (14.10) and latest driver with backport. The latest backport behaves *much* better.

[JaSauders (jasauders)]

@ Emmanuel

Not to sound pessimistic, but there seems to be a rather wild different between one 7260 to the next 7260. Myself and two co-workers got the same XPS 13 with Ubuntu. The other two had no issues, while I would disconnect continuously, often times even when we were in the same room. We were running the same distro and everything. Even when I swapped the card three times, antenna twice, and the motherboard once, the issue persisted. Ultimately this resulted in me trading up the XPS 13 under warranty for a Latitude E7440 with Ubuntu, so it worked out (for me) despite the issue not having been "fixed". Likewise, a friend of mine had a laptop with a 7260 chip where he had nothing but issues despite the extensive amount of troubleshooting and testing he did. He ended up buying another 7260 based laptop ready to swap the chip but he ended up having no issues, so he just kept chugging along with it.

There's a massive thread on the Intel forums with seemingly no answer. Users from all types of distributions and operating systems are posting about their issues, from 7 to 8 to Arch and Ubuntu. I want this fixed in ways I cannot begin to describe, but we're about 1.5 years in since this card's release with no "official" fix, just odds and ends tweaks that seem to help one or two users, but not everybody. I can't help but to feel that this is some sort of hardware issue. Unfortunately, Intel has been rather quiet about it, so at this point it's nothing more than an assumption.

Anyway, just wanted to throw that out there.

[Richie (richardjmarini)]

I'm having the same problem. Have a Dell XPS 15 with Network controller: Intel Corporation Wireless 7260 (rev 6b). Wifi link constanlty drops. Disabling power management and 11n_disable stablizes the connection a bit so I no longer get dropped off but wifi link is still very slow (it varies from minute to minute but over all still very slow). Running Ubuntu 14.04 LTS

[Yuriy Vidineev (adeptg)]

Dell XPS 13 (Intel Corporation Wireless 7260 (rev 6b)), kubuntu 14.04. With linux 3.13.0-44 and iwlwifi-7260-7.ucode I had no problems. Few days ago I installed linux 3.16.0-31 (it's used iwlwifi-7260-9.ucode) and got a bunch of disconnects

[spinxz (spinxz)]

Same problem on Lenovo Carbon X1 gen2 with Intel Wireless 7260 (rev 83).
Using Ubuntu 15.04 with 3.19.0-21 kernel (x86_64).
Bluetooth is soft-blocked with rfkill but this does not solve the problem.

I constantly get disconnects:

wlan0: deauthenticating from ....... by local choice (Reason: 3=DEAUTH_LEAVING)