Wireless network disconnections on Dell XPS 13

Marcel: Can you go ahead and update so that everything is current, then boot with the current kernel (3.13.0-32.57) and the -8 firmware for iwlwifi (22.24.8.0). Then wait until you experience problems and run 'apport-collect 1349572' to attach logs to this bug report. It's better to start from the most recent updates for debugging this problem. Thanks!

Hi Seth.
It Is valid to test with 3.13.0-32-generic ? Is the same as 3.13.0-32.57?
If not How can I get to upgrade to that version?

You can also use the latest backport:

http://drvbp1.linux-foundation.org/~mcgrof/rel-html/backports/

and with latest firmware: https://git.kernel.org/cgit/linux/kernel/git/egrumbach/linux-firmware.git/plain/iwlwifi-7260-9.ucode?id=e2844339cb779c00f856c554958e16beca99b462

3.13.0-32-generic should be the same. Run 'dpkg -l linux-image-3.13.0-32-generic' and check the version number to confirm. Or else once you've booted that kernel you can run 'uname -a' and you'll see something like:

Linux ubuntu-hedt 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

The "#57" in the output corresponds to the .57 in the version number.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

I hope I attached logs with "apport-collect 1349572".

I cannot call this when there is a wireless shutdown, i must recover coms by shutting them down and restarting them, and after call it.

Also when calling it, shows "dpkg.query: no se ha encontrado ningún paquete que corresponda con linux". I suspect because of the package on the bug ("linux"), I do not know which one must be.

Thanks, Marcel. The problem does look very similar to that in bug #1293569, but apparently that fix isn't working for you.

Let's try to get some more data. Please download http://people.canonical.com/~sforshee/wifi-debug, then open a terminal and make it file executable ("chmod u+x wifi-debug" in the directory where you downloaded the file). Run "sudo apt-get install iw trace-cmd tcpdump" to install some needed tools, then run "./wifi-debug -t -p". This will start collecting data. Leave it running until you experience wireless problems, then press Enter to stop collecting data (this collects a lot of data, so if this problem takes a long time to happen you may want to periodically stop and restart wifi-debug as long as the connection is stable as well).

Once the script finishes you should have a file named wifi-debug-files.tar.gz. Please give me this file either via email or by uploading it to some kind of online storage and providing me a link. I don't suggest attaching it to this bug report.

Please note that this script will log your network activity and the activity of other wireless clients on the same channel (though traffic from other clients will be encrypted if connected to a protected network), so anything you do on the wireless connection while it's running will be captured. I won't be looking at the actual data sent over the network, and anything sent over a secure SSL connection will still be encrypted, but you may want to restrict your activity while the script is running to avoid having any personal or confidential information captured. If you aren't comfortable with having network activity logged you can omit the -p option to wifi-debug. In that case only mildly private information such as network addresses will be collected, but that will also limit what I'm able to do to help you.

Thanks!

After some disconnections, the system cannot recover wireless connection, arounf 1-2hours . Rebooting the system does not help.

I must change to 3.13.0.30 and -7 firmware to connect with wifi (and some problems, but al least can connect to write this).

Connection on my Nexus 5 is ok all the time.

I'm still in the process of looking through the data you sent me. Everything I've seen so far points to loss of beacons from the AP, but if wireless on your phone continues to work then I have to think the AP is sending beacons. The second dump is interesting because it shows associations followed almost immediately by beacon loss messages which lead to disassociation.

One thing you can try while I continue looking at the data is to test a newer kernel version to see if you still have problems there. We have builds that you can download and install at http://kernel.ubuntu.com/~kernel-ppa/mainline/, with the newest kernel currently being 3.16-rc7:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.16-rc7-utopic/

You should just need to download the linux-image-*-generic_*amd64.deb and install it (sudo dpkg -i <filename>), then reboot into the new kernel. This should also cause you to use the newer -9 firmware, so if you find this kernel works well I'd be curious to know if it still works well with the -8 firmware. You can test this by moving/renaming /lib/firmware/iwlwifi-7260-9.ucode and running 'sudo modprobe -r iwlwifi; sudo modprobe iwlwifi'. Thanks!

Seems that with this kernel I'm not losing connections, haven't tested for a long time, but seems to connect quikly after a reboot.

Tomtorrow afternoon I'll try more tests.

Doing an speedtest.net with new kernel gives really bad speeds.
http://www.speedtest.net/my-result/3660405916

Normally in the same home position they are about 9Mbps Down and 0.9 Uo.

Sorry to ask this: Do you know if with this kernel I can make touchpad work? If I am getting better connection I'll like to keep this kernel.

Thanks, please keep me posted. I wouldn't suggest using that kernel long-term since it's unsupported, but if it continues working well maybe we can continue testing more kernels to try and determine what changed to fix the problem.

As for the touchpad, my first guess would be that you have a DKMS module for it. If that's the case you'll also need to install the linux-headers-*_all.deb and linux-headers-*_amd64.deb packages to get it working. I think installing the packages should trigger a rebuild, but if the touchpad still doesn't work (after rebooting) you might try running 'sudo dkms autoinstall' and rebooting again to see if that helps.

Marcel: Another kernel for you to test. It is 3.13.0-32.57 with a single update to give a little more leeway for beacon loss. Let me know if this helps at all.

http://people.canonical.com/~sforshee/lp1349572/linux-3.13.0-32.57+lp1349572/

Note that you do need to install the linux-image-extra package in addition to the linux-image package. The headers packages are optional, but if your touchpad driver does turn out to be DKMS then you may need them for it to work.

Seth, I couldn't test them very much.

Yesterday I updated the system to your 3.13.0.32, so far so good. But it was only a 30 min test. Today I will test it more deeper.

As for 3.16 i was getting some disconenctions (but much better than with stock 3.13.0.32), but also only a 30 min test.
Also I tested it at work (with fiber connection), and the cable modem (CBN Inc. CG6640E) got "hanged" every time I made a speedtest.net. Previous test with other kernels didn't hanged this cable modem.
I have not yet tested it with your new kernel, tomorrow I expect to bring my home computer to this location.

This night I expect to send you a report.
I will only test with new 3.13.10.32.57 kernel, is it ok?

Marcel: That's fine. If you're getting connections with 3.16 we might want to check later and see if those are the same or different than what you're getting in 3.13, but for now you can continue testing the kernel I built to see if it improves things for you at all.

Hi Seth,
I had no disconnections, now for a 3h period (a fabolous improvement!)

Speed seems to decrease, at least with a speedtest:
  http://www.speedtest.net/my-result/3668258447

I know, it is not a valid test, but maybe is a reference. I tested it with various servers and seems a limit at about 5Mbps.

Firmware is 22.24.8.0.

With this versions I don't get an strange phenomenon where "System Load Indicator" showed equally separated peaks of infinity connection download speed.

Is there a method to know if there was a disconnection? I mean some kind of "dmesg | grep xxxx"

Tomorrow I'll try it at other locations.

On Mon, Aug 04, 2014 at 08:59:52PM -0000, Marcel Miguel wrote:
> Hi Seth,
> I had no disconnections, now for a 3h period (a fabolous improvement!)

Good!

> Speed seems to decrease, at least with a speedtest:
> http://www.speedtest.net/my-result/3668258447
>
> I know, it is not a valid test, but maybe is a reference. I tested it
> with various servers and seems a limit at about 5Mbps.

I don't really think this change should affect your speed at all. A more
reliable test of performance would be to use iperf against a machine
with a wired connection to the same network, if possible, and make sure
that you're using the same network with all kernels. If it's a network
with multiple access points then you could get different results though
depending on the AP you happen to be connected to, channel, etc.

> Firmware is 22.24.8.0.
>
> With this versions I don't get an strange phenomenon where "System Load
> Indicator" showed equally separated peaks of infinity connection
> download speed.
>
> Is there a method to know if there was a disconnection? I mean some kind
> of "dmesg | grep xxxx"

You could check /var/log/syslog for the string "disconnect", e.g. 'grep
-i disconnect /var/log/syslog', but that could contain logs from prior
boots so you could get false positivies. The particular problem I was
seeing (disconnection due to beacon loss) result in messages like this:

wlan0: CTRL-EVENT-DISCONNECTED bssid=xx:xx:xx:xx:xx:xx reason=4

I had some disconnections 15 minuts ago:

wlan0: CTRL-EVENT-DISCONNECTED bssid=xxxxxx reason=4 locally_generated=1

I needed a restart to arrange it. After this everything seems to work fine.

It sounds like the 3.13 test build is better but still not perfect. Is this correct?

Once you feel confident in your results, I'd appreciate it if you could try 3.16 for a longer period and see how it compares to the 3.13 test build. If it's better then there may be additional improvements we can backport to 3.13 to improve the connection. Thanks!

This afternoon there has been lots of disconnections, around 40, but connection was recovered, so its is better, but not very usable.

I'll inform when I am able to test 3.16, expect some tests on thursday.

After some hours, maybe 2 disconnections. Less than with 3.13.0.32.57 (with backported 3.14 parts)
Some tests speedtest.net get better speeds than previous kernel.
So it's difficult to say with a short test, but it is better than stock, and better than 3.13 (backported).
I cannot work with 3.16, so I need to come back to 3.13 (I got a wireless shutdown in a the first minut working with it)

Can you give me syslog from 3.16 so I can check whether the disconnections appear to have the same cause?

The next thing I'd like to know is whether 3.16 with the -8 firmware, to see whether it's the kernel or the firmware that improves your results. If you're able too, could you rename /lib/firmware/iwlwifi-7260-9.ucode to something else, reboot to 3.16, and see how well that works?

I found some people saying that a workaround for touchpad issues on your machine is to blacklist the i2c-hid module, so you could try that with 3.16 to see if it helps. You can do this by running 'echo "blacklist i2c_hid" | sudo tee /etc/modprobe.d/blacklist-i2c-hid.conf' before booting to 3.16, then you can delete /etc/modprove.d/blacklist-i2c-hid.conf when you're done testing. Might be worth a try.

I tested 3.16 rc7 with firmware 22.24.8.0, and seems stable, no more reason=4 disconnections for about 5 hours on the computer. Difficult to say but more stable than with .9 firmware...
Speed seems ok (not tested correctly yet, I only have this computer at home).

Blacklisting does not work on 3.16 kernel, I already blalisted i2c when I updated to 14.04.
Unfortunately, for these an others problems I need to come back to 3.13. Is it possible to backport some of the changes of 3.16 so I can test them on 3.13?

The easiest way I know of for you to test the 3.16 driver with 3.13 is by using the drivers from the backports project. Unfortunately there is no prebuilt version for Ubuntu, so you'll have to manually build and install the drivers. If you want to give this a try see https://backports.wiki.kernel.org/index.php/Main_Page.

Ultimately if 3.16 gives a more stable connection than 3.13 I'd like to backport the relevant changes to 3.13, but the problem is that I don't know yet which changes need to be backported. If it were only due to the -9 firmware then I believe that's easily backported to 3.13, but based on your results so far that doesn't seem to be the case.

My tests were not very exhaustive. Especially beacuse mainly my wifi was working on the computer.

If you wish I can test other kernels/drivers, better with 3.13.

The main problem with 3.16 is that VisrtualBox is not working for me, and I need it.

I found another upstream fix related to the recovery from missed beacons for drivers like iwlwifi, so I think it's worth giving that a try. I backported it to 3.13 and posted the build here:

  http://people.canonical.com/~sforshee/lp1349572/linux-3.13.0-32.57+lp1349572v201408111147/

Please try it out and let me know if it works any better. Thanks!

I'm testing your new kernel., using firmware 22.24.8.0.

I tested for about 2 hours yesterday, and today for an hour.

No disconnections for reason 4.

Now at work, I wanted to test speeds. I got 57mb/s close to one of the AP. Then I changed to 3.16 to test on it. But after that I can't connect to hotspots, even if I come back to your new kernel. I deleted connections on ubuntu and created them again with no luck.

From my Nexus 5 and other mobiles connects to the APs.

In the past I also had many problems with wifis at work. Tested with other kernels, the last was 3.13.30.

At home, I did not have any reason=4 disconnections, for a 10hours time, so this kernel is better than stock and (maybe) better than 3.16 with -9 firmware.

Thanks, Marcel. That's good enough for us to move forward with the patches, so I'll get them applied in trusty. I'm not convinced that the problems are 100% fixed, so if you're seeing problems after we get these patches in place please file new bugs for these issues.

https://lists.ubuntu.com/archives/kernel-team/2014-August/047672.html

Thanks Seth. This is working better than stock.
But just got 4 consecutives reason=4 disconnections, the system recovered alone in 3 minutes. Do I create a new bug?

On Sat, Aug 16, 2014 at 11:40:28AM -0000, Marcel Miguel wrote:
> Thanks Seth. This is working better than stock.
> But just got 4 consecutives reason=4 disconnections, the system recovered alone in 3 minutes. Do I create a new bug?

Yeah, as I said I don't think we've found a complete fix at this point.

Filing a new bug the normal way will probably be a bit tricky since
apport is going to refuse to collect bug data for a non-official kernel
package. If you want to do so manually without all of the logs we could
work off of that (since wifi-debug will collect most of the data I want
to see anyhow), or if you're patient you can just wait until the fixes
here are officially released and then file a new bug.

Seth, thanks for your efforts, I'm affected as well.

I just tried kernel 3.16 (your post #40) and got no disconnects (though not testing for a long time now) but the connection was very slow, some Kb/s (maybe related to #1354975). Unfortunately I can't use your build as I'm on i386. I'll keep observing.

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!

Still some reason=4 disconnections, but seems the same as Seth's kernel.
I have tested it not on my own computer, but on onother Dell XPS 9333 (same version) but on my home wifi.

I don't how to change tag. I must do it myself?

Just tested on my office wifi and got 120Mbit/s, so there is no speed problem with this new kernel. Also no reason=4 disconnections for a hour test.

Thank you very much to Seth and others for the good work.

This bug was fixed in the package linux - 3.13.0-36.63

---------------
linux (3.13.0-36.63) trusty; urgency=low

  [ Joseph Salisbury ]

  * Release Tracking Bug
    - LP: #1365052

  [ Feng Kan ]

  * SAUCE: (no-up) irqchip:gic: change access of gicc_ctrl register to read
    modify write.
    - LP: #1357527
  * SAUCE: (no-up) arm64: optimized copy_to_user and copy_from_user
    assembly code
    - LP: #1358949

  [ Ming Lei ]

  * SAUCE: (no-up) Drop APM X-Gene SoC Ethernet driver
    - LP: #1360140
  * [Config] Drop XGENE entries
    - LP: #1360140
  * [Config] CONFIG_NET_XGENE=m for arm64
    - LP: #1360140

  [ Stefan Bader ]

  * SAUCE: Add compat macro for skb_get_hash
    - LP: #1358162
  * SAUCE: bcache: prevent crash on changing writeback_running
    - LP: #1357295

  [ Suman Tripathi ]

  * SAUCE: (no-up) arm64: Fix the csr-mask for APM X-Gene SoC AHCI SATA PHY
    clock DTS node.
    - LP: #1359489
  * SAUCE: (no-up) ahci_xgene: Skip the PHY and clock initialization if
    already configured by the firmware.
    - LP: #1359501
  * SAUCE: (no-up) ahci_xgene: Fix the link down in first attempt for the
    APM X-Gene SoC AHCI SATA host controller driver.
    - LP: #1359507

  [ Tuan Phan ]

  * SAUCE: (no-up) pci-xgene-msi: fixed deadlock in irq_set_affinity
    - LP: #1359514

  [ Upstream Kernel Changes ]

  * iwlwifi: mvm: Add a missed beacons threshold
    - LP: #1349572
  * mac80211: reset probe_send_count also in HW_CONNECTION_MONITOR case
    - LP: #1349572
  * genirq: Add an accessor for IRQ_PER_CPU flag
    - LP: #1357527
  * arm64: perf: add support for percpu pmu interrupt
    - LP: #1357527
  * cifs: sanity check length of data to send before sending
    - LP: #1283101
  * KVM: nVMX: Pass vmexit parameters to nested_vmx_vmexit
    - LP: #1329434
  * KVM: nVMX: Rework interception of IRQs and NMIs
    - LP: #1329434
  * KVM: vmx: disable APIC virtualization in nested guests
    - LP: #1329434
  * HID: Add transport-driver functions to the USB HID interface.
    - LP: #1353021
  * ahci_xgene: Removing NCQ support from the APM X-Gene SoC AHCI SATA Host
    Controller driver.
    - LP: #1358498
  * fold d_kill() and d_free()
    - LP: #1354234
  * fold try_prune_one_dentry()
    - LP: #1354234
  * new helper: dentry_free()
    - LP: #1354234
  * expand the call of dentry_lru_del() in dentry_kill()
    - LP: #1354234
  * dentry_kill(): don't try to remove from shrink list
    - LP: #1354234
  * don't remove from shrink list in select_collect()
    - LP: #1354234
  * more graceful recovery in umount_collect()
    - LP: #1354234
  * dcache: don't need rcu in shrink_dentry_list()
    - LP: #1354234
  * lift the "already marked killed" case into shrink_dentry_list()
  * split dentry_kill()
    - LP: #1354234
  * expand dentry_kill(dentry, 0) in shrink_dentry_list()
    - LP: #1354234
  * shrink_dentry_list(): take parent's ->d_lock earlier
    - LP: #1354234
  * dealing with the rest of shrink_dentry_list() livelock
    - LP: #1354234
  * dentry_kill() doesn't need the second argument now
    - LP: #1354234
  * dcache: add missing lockdep annotation
    - LP: #1354234
  * fs: convert use of typedef ctl_table to struct ctl_table
 ...

On my Dell Inspiron 7537 the wifi is working very well on 3.16 (trusty), however I experience frequent disconnections on 3.19 kernel (vivid). After I get disconnected, no APs are visible by Unity wifi applet. However, using wavemon to connect to a network "fixes" everything for about 1 hour. Switching off wifi power saving helps. I'm wondering why everything works well on the 3.16 but I have issues on 3.19.