Intel 3160 wireless card no longer able to connect to wifi networks

[Michael Boratko]

[Impact]

Laptop: Lenovo Y70 Touch
Wireless Card: Intel Corporation Wireless 3160 (rev 93)

When running Ubuntu Gnome 14.10 (on a live USB drive) I am able to connect to wifi networks without any issue. When running Ubuntu Gnome 15.04 (either on live USB or installed and fully updated) I am able to see the list of available wifi networks, but not able to connect. Selecting one and entering the password makes the network manager applet indicate that it is "Connecting..." but then it gives up after about a minute or so and reverts back to "Not Connected". I have tested this without network encryption as well, and the same result occurs.

[Test Case]

I have ran a wifi debugging script, here is the output:

For Ubuntu 14.10 - http://pastebin.com/aLUhTyrM
For Ubuntu 15.04 - http://pastebin.com/f0yRjQUC

Again, the card seems to work perfectly on 14.10, but is unable to connect to any networks on 15.04.

[Fix]

commit afcee962b09842d0f4191beb4a2d08251b4c7705 upstream

[Workaround]

Boot with bluetooth turned off. If the computer boots with the bluetooth turned on, the wifi will not work, even if you first turn off the bluetooth. A restart is needed.

---
ApportVersion: 2.17-0ubuntu2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: mboratko 1609 F.... pulseaudio
 /dev/snd/controlC1: mboratko 1609 F.... pulseaudio
CurrentDesktop: GNOME
DistroRelease: Ubuntu 15.04
EcryptfsInUse: Yes
InstallationDate: Installed on 2015-04-10 (0 days ago)
InstallationMedia: Ubuntu-GNOME 15.04 "Vivid Vervet" - Beta amd64 (20150326)
MachineType: LENOVO 80DU
Package: linux (not installed)
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-12-generic.efi.signed root=UUID=0fb46cba-f7ac-4bc5-aa7d-5f6aa74636c1 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.19.0-12.12-generic 3.19.3
RelatedPackageVersions:
 linux-restricted-modules-3.19.0-12-generic N/A
 linux-backports-modules-3.19.0-12-generic N/A
 linux-firmware 1.143
Tags: vivid
UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
Uname: Linux 3.19.0-12-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm bumblebee cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 02/11/2015
dmi.bios.vendor: LENOVO
dmi.bios.version: 9ECN37WW(V2.01)
dmi.board.asset.tag: 31900058WIN
dmi.board.name: Lenovo Y70-70 Touch
dmi.board.vendor: LENOVO
dmi.board.version: 31900058WIN
dmi.chassis.asset.tag: 31900058WIN
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Lenovo Y70-70 Touch
dmi.modalias: dmi:bvnLENOVO:bvr9ECN37WW(V2.01):bd02/11/2015:svnLENOVO:pn80DU:pvrLenovoY70-70Touch:rvnLENOVO:rnLenovoY70-70Touch:rvr31900058WIN:cvnLENOVO:ct10:cvrLenovoY70-70Touch:
dmi.product.name: 80DU
dmi.product.version: Lenovo Y70-70 Touch
dmi.sys.vendor: LENOVO

[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 v4.0 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/v4.0-rc7-vivid/

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1442411

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Michael Boratko (boratko)]

apport information

[Michael Boratko (boratko)]

apport information

[Michael Boratko (boratko)]

apport information

[Michael Boratko (boratko)]

apport information

[Michael Boratko (boratko)]

apport information

[Michael Boratko (boratko)]

apport information

[Michael Boratko (boratko)]

apport information

[Michael Boratko (boratko)]

apport information

[Michael Boratko (boratko)]

apport information

[Michael Boratko (boratko)]

apport information

[Michael Boratko (boratko)]

apport information

[Michael Boratko (boratko)]

apport information

[Michael Boratko (boratko)]

apport information

[Michael Boratko (boratko)]

apport information

[Michael Boratko (boratko)]

The above logs are from apport on Ubuntu Vivid running the 3.19 kernel (fully updated at time of posting).

I also updated to newest version of kernel (4.0.0-040000rc7-generic) as you requested, and the problem persists as before. Do you want more apport logs from the new kernel as well?

[Michael Boratko (boratko)]

The wireless card also works in Arch Linux using this kernel:

Linux LenovoY70 3.19.3-3-ARCH #1 SMP PREEMPT Wed Apr 8 14:10:00 CEST 2015 x86_64 GNU/Linux

I've attached the wifi script output from Arch to this

[penalvch (penalvch)]

Michael Boratko, could you please boot into a Utopic kernel https://launchpad.net/ubuntu/+source/linux/3.16.0-23.31 in your current install and advise to the results following https://wiki.ubuntu.com/Kernel/KernelBisection ?

[Michael Boratko (boratko)]

I cloned the git repo for the Ubuntu kernel and I built a number of test kernels. It seems like the problem starts in 3.18.0-1.1, here are the kernels tested:

Good
3.16.0-23.31
3.16.0-24.32
3.16.0-25.33
3.16.0-28.38 *

Bad
3.18.0-1.1
3.18.0-7.8
3.19.0-1.1
3.19.0-10.10
3.19.0-12.12
3.19.0-13.13

* - On this kernel it does work, but I have strange issues with it which were not present on earlier kernels. It is slower to establish a connection, and also started having intermittent connectivity problems (it indicated it was still connected, but I wasn't able to ping my router, for instance).

I would be happy to perform a complete git bisect to help isolate the problem further, but as it was I had to do this a bit manually as git bisect would choose a commit between releases, and therefore there was no debian/rules file so that I could perform the deb package build with fakeroot. The instructions on the KernelBisection wiki page point to this page for kernel building instructions:
https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel

The problem is that that page only contains the instructions which work for a release (i.e. requires the debian/rules file and so forth). If you could point me to instructions for building it in the intermediate commits, I would be happy to do it.

[Michael Boratko (boratko)]

The asterisk mentioned above (for kernel 3.16.0-28.38) should be disregarded - the behavior was present for a few tests, but I have repeatedly tested it at this point and I think it was just typical wifi wonkyness rather than the indication of a problem. Therefore, 3.16.0-28.38 should be regarded as an unqualified good kernel, and thus the breaking point is sharp between 3.16.0-28.38 and 3.18.0-1.1.

[Michael Boratko (boratko)]

I figured out how to do a kernel bisection manually, and isolated the first bad commit to this one:

ab1304b986468e3ef698ec4e1cb1a3d4ba080811 is the first bad commit
commit ab1304b986468e3ef698ec4e1cb1a3d4ba080811
Author: Marcel Holtmann <email address hidden>
Date: Mon Aug 11 22:11:35 2014 +0200

    iwlwifi: Remove module build requirement for Intel Wireless WiFi

    The CONFIG_IWLDVM and CONFIG_IWLMVM currently have a
    "depends on m" as its requirement forcing it to be build
    as module. This is not needed and thus just remove it.

    Fixes: ae7486a2b734 ("iwlwifi: fix Kconfig issues")
    Signed-off-by: Marcel Holtmann <email address hidden>
    [Squashed 2 commites for MVM and DVM]
    Signed-off-by: Emmanuel Grumbach <email address hidden>

:040000 040000 ca6d0eb787ca471c6e6267bf86863acb9bcd638b 6fda9a82d01a59a4edeaee8d1fbeb2cce28eeecc M drivers

The thing is, however, that after resetting to Ubuntu 3.19.0-13.13, and then reverting this commit (which had merge issues, but I believe I resolved them correctly) I still get the same result. I suppose I can conclude one of two things from this - either there is another independent commit which also causes this problem and occurs after the one above, or I did the merge incorrectly.

Let me know if there is more I can do to help resolve this.

[penalvch (penalvch)]

Michael Boratko, it wouldn't hurt to confirm your results by testing one commit prior to this.

[Michael Boratko (boratko)]

I thought that is exactly what git bisect does.

In any event, I manually created a new branch and compiled the kernel one commit behind ab1304b986468e3ef698ec4e1cb1a3d4ba080811, and verified that it does work on this commit.

[Michael Boratko (boratko)]

To be more specific, commit f47f46d7b09cf1d09e4b44b6cc4dd7d68a08028c works, commit ab1304b986468e3ef698ec4e1cb1a3d4ba080811 does not. Furthermore, checking out Ubuntu 3.19.0-13.13 and reverting commit ab1304b986468e3ef698ec4e1cb1a3d4ba080811 (which requires making a minor merge conflict adjustment) does not work either.

[penalvch (penalvch)]

Michael Boratko, if one does not confirm by testing to the results of a git bisect, then no, it's not what a git bisect does.

However, given you tested one commit back, this contradicts your statement in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1442411/comments/22 :
>"The thing is, however, that after resetting to Ubuntu 3.19.0-13.13, and then reverting this commit (which had merge issues, but I believe I resolved them correctly) I still get the same result."

Could you please clarify if this comment would be mistaken?

[Michael Boratko (boratko)]

I think perhaps I'm using the wrong vocabulary, which is the cause of confusion.

When I did the git bisect I tested each bisection point manually, so I must have actually tested that commit at some point in the past (otherwise I wouldn't have truly bisected). Checking the bisect log, that commit was tested fifth, and found to be "good" at that time.

The two comments are not contradictory. When I simply use git reset --hard f47f46d7b09cf1d09e4b44b6cc4dd7d68a08028c and compile the wifi works. (This is the last working commit.) When I use git reset --hard ab1304b986468e3ef698ec4e1cb1a3d4ba080811 and compile, the wifi does not work.

Finally, when I use git reset --hard Ubuntu 3.19.0-13.13 and then do git revert ab1304b986468e3ef698ec4e1cb1a3d4ba080811, I get a merge conflict. There is just one file to address, and the changes are pretty straightforward to handle. I clear the merge, commit, and compile, but again the wifi doesn't work.

[Michael Boratko (boratko)]

First, I have to mention that after additional testing I found that the ab1304b986468e3ef698ec4e1cb1a3d4ba080811 commit actually does work, but for some unknown reason I have to turn off the wifi adapter and turn it back on after the computer starts.

The commit after that (d88c8958dc13b4e4eb7fc57e3f06dc1c4abc7b1f), which increases the acceptable firmware API to 10, is actually where the problem occurs.

This prompted me to look into the firmware itself more. I booted into the 3.19.0-13.13 generic and did the following:

sudo mv /lib/firmware/iwlwifi-3160-12.ucode /lib/firmware/backup-iwlwifi-3160-12.ucode
sudo mv /lib/firmware/iwlwifi-3160-10.ucode /lib/firmware/backup-iwlwifi-3160-10.ucode

Then I rebooted. I am now using the wifi on the Ubuntu 3.19.0-13.13 kernel, albeit with the older firmware (version 9). Dmesg confirms that moving these firmware files made the iwlwifi driver fallback to the earlier version:

# dmesg | grep iwlwifi
[ 6.856144] iwlwifi 0000:08:00.0: Direct firmware load for iwlwifi-3160-12.ucode failed with error -2
[ 6.856208] iwlwifi 0000:08:00.0: Direct firmware load for iwlwifi-3160-11.ucode failed with error -2
[ 6.856217] iwlwifi 0000:08:00.0: Direct firmware load for iwlwifi-3160-10.ucode failed with error -2
[ 6.856219] iwlwifi 0000:08:00.0: request for firmware file 'iwlwifi-3160-10.ucode' failed.
[ 6.861495] iwlwifi 0000:08:00.0: Firmware has old API version, expected v10 through v12, got v9.
[ 6.861499] iwlwifi 0000:08:00.0: New firmware can be obtained from http://www.intellinuxwireless.org/.
[ 6.861664] iwlwifi 0000:08:00.0: loaded firmware version 25.228.9.0 op_mode iwlmvm
[ 6.899533] iwlwifi 0000:08:00.0: Detected Intel(R) Dual Band Wireless AC 3160, REV=0x164
[ 6.899677] iwlwifi 0000:08:00.0: L1 Enabled - LTR Disabled
[ 6.899923] iwlwifi 0000:08:00.0: L1 Enabled - LTR Disabled
[ 7.323877] iwlwifi 0000:08:00.0: L1 Enabled - LTR Disabled
[ 7.324167] iwlwifi 0000:08:00.0: L1 Enabled - LTR Disabled

This is an OK workaround, but clearly something is up here because I am able to use the newest firmware on other distributions (Arch for instance).

[penalvch (penalvch)]

Michael Boratko, if this is reproducible with the latest mainline kernel (4.0), then the issue you are reporting is an upstream one. Could you please report this problem to the appropriate mailing list (linux-wireless, ilw, iwlwifi maintainer, CC the regression committer and those who signed off on it) by following the instructions verbatim at https://wiki.ubuntu.com/Bugs/Upstream/kernel ?

Please provide a direct URL to your e-mail to the mailing list once you have made it so that it may be tracked via http://vger.kernel.org/vger-lists.html . It can take a day for the new e-mail to show up in the respective archive.

Thank you for your understanding.

[Michael Boratko (boratko)]

I understand what you're saying, however I'm confused as to why this would work appropriately on other distributions with the newer (version 12) firmware. In particular, it works on Arch linux (mentioned above).

[Michael Boratko (boratko)]

I am perplexed to report that, although I am able to reproduce the error on 4.0, I am not able to reproduce it on 4.1. Furthermore, directly after writing the above comment, I updated my Arch Linux install, and now the wifi fails in a completely different way than described above, so I really don't know what's going on.

I'm going to see if I can figure out what makes it work in 4.1, and if that commit would be able to be brought back to previous kernels.

[penalvch (penalvch)]

Michael Boratko, please keep in mind that the Ubuntu kernel, Arch kernel, and upstream/mainline kernel are all different from one another.

Despite this, the next step is to fully reverse commit bisect from kernel 4.0-rc7 to 4.1-rc1 in order to identify the last bad commit, followed immediately by the first good one. Once this commit has been identified, then it may be reviewed as a candidate for backporting into your release. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection#How_do_I_reverse_bisect_the_upstream_kernel.3F ?

Please note, finding adjacent kernel versions is not fully commit bisecting.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[Michael Boratko (boratko)]

Understood. It just seemed that if there was a bug in the upstream kernel
and (for instance) the Arch kernel team had found it, it would similarly be
reported back upstream, not to mention that Arch seems quite against making
upstream modifications.

In any event, I am in the process of reverse commit bisecting right now. An
initial search for commits with comments containing iwlwifi did not lead to
anything promising. I will report back with results.

[mexlinux (mcanedo)]

The solution indicated here:
http://askubuntu.com/questions/611222/cannot-connect-to-wifi-intel-corporation-wireless-3160

Makes it possible to connect to wifi, but after suspension it does not work, restarting network services does not work. Restarting computer does.

[penalvch (penalvch)]

mexlinux, unfortunately WORKAROUNDs are not considered solutions. Also, making folks dumpster dive through some link isn't terribly helpful here.

Despite this, it will be most helpful if you filed a new report via a terminal:
ubuntu-bug linux

Please feel free to subscribe me to it.

[Michael Boratko (boratko)]

I reverse bisected the upstream kernel, and determined that the fix is in commit 16c426f. I also believe that this is (upstream) already set to be merged into the 3.19 kernel (please let me know if that's not the case).

Specifically, there is only one small change in this commit, which adjusts the way the shared bluetooth antenna works. Inspecting the code, I also determined the following test and workaround - turn off the bluetooth, and then restart.

I attempted this on the latest Ubuntu 3.19.0-15-generic kernel. If the computer is booted with the bluetooth turned off (i.e. from a previous session) then the wifi will work. If the computer boots with the bluetooth turned on, the wifi will not work, even if you first turn off the bluetooth. A restart is needed.

Let me know if there is more I can do.

[Jason Gerard DeRose (jderose)]

@boratko - what's the full git commit ID of the of the mainline commit that fixes this?

[Jason Gerard DeRose (jderose)]

Mostly just confirming what @boratko already shared, plus perhaps a few new details:

The ingredients needed to reproduce this bug on Vivid:

1) Intel 3160 WiFi card

2) Boot with bluetooth enabled (turn on in the bluetooth indicator and reboot if needed)

3) Connect to a 2.4 GHz N router

In this situation, I've not once successfully connected to my AP. When my SSID shows up in NetworkManager, attempting to connect my AP will fail and there is an error in dmesg about the authentication timing out. But occasionally the SSID wont even show up in NetworkManager, so I can't try to connect to it.

With the same hardware and same scenario, this bug is not present when running 14.04.2 (with Utopic HWE).

Some other details:

1) Turning off bluetooth (from the indicator) and rebooting seems a reliable way to work-around this

2) There are no issues when connecting to a 5 GHz AC router, and based on feedback from System76 customers, it seems 5 GHz N is fine and 2.4 GHz G is likewise fine ( the problem is seemingly limited to just 2.4 GHz N)

3) This problem is not present with Intel 7260 WiFi cards, only the 3160

4) I confirmed that the 4.1rc2 mainline build fixes this issue:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.1-rc2-vivid/

[Michael Boratko (boratko)]

The full git ID for the commit which fixes this issue in the mainstream kernel is:

16c426ff9e13a06d754ed7484f5e6e6d6550f968

[Jason Gerard DeRose (jderose)]

Okay, afcee962b09842d0f4191beb4a2d08251b4c7705 seems to fix this problem:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=afcee962b09842d0f4191beb4a2d08251b4c7705

I cherry-picked it into the current ubuntu-vivid.git tree and built a kernel, and have had no problems so far.

It's only a one line change:

diff --git a/drivers/net/wireless/iwlwifi/mvm/coex_legacy.c b/drivers/net/wireless/iwlwifi/mvm/coex_legacy.c
index d530ef3..85144d5 100644
--- a/drivers/net/wireless/iwlwifi/mvm/coex_legacy.c
+++ b/drivers/net/wireless/iwlwifi/mvm/coex_legacy.c
@@ -1176,7 +1176,7 @@ bool iwl_mvm_bt_coex_is_ant_avail_old(struct iwl_mvm *mvm, u8 ant)
 bool iwl_mvm_bt_coex_is_shared_ant_avail_old(struct iwl_mvm *mvm)
 {
  u32 ag = le32_to_cpu(mvm->last_bt_notif_old.bt_activity_grading);
- return ag == BT_OFF;
+ return ag < BT_HIGH_TRAFFIC;
 }

 bool iwl_mvm_bt_coex_is_tpc_allowed_old(struct iwl_mvm *mvm,

[Jason Gerard DeRose (jderose)]

Attaching the patch from:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=afcee962b09842d0f4191beb4a2d08251b4c7705

[Michael Boratko (boratko)]

@jderose - Thanks for catching the error with my commit ID, yes that is the commit I meant to refer to.

Also, I seem to be getting intermittent behavior still when connected to a 5GHz wireless AC network. I haven't tested others, but even with the bluetooth off I am getting random disconnects. I typically notice this when watching Netflix, YouTube, listening to Spotify, or using GMail. The website will indicate I am no longer connected, however the Network Manager applet still indicates a strong connection. The only way to fix it has been to turn off the WiFi and turn it back on. Not sure if that's related to this, but I wanted to post this here to see if you could corroborate this situation.

Other devices in the house which connect to the 5GHz wireless AC network do not exhibit this behavior.

[Launchpad Janitor (janitor)]

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

[Jason Gerard DeRose (jderose)]

@boratko - no problem, thanks for figuring out that it was related to bluetooth being turned on!

[pask (pd65)]

I've the same problem and confirm that putting OFF the bluetooth and restarting the PC the connection is OK ( even if manually I've choiced it ).

thanks

[Ariel Keselman (skariel)]

hi, I have the same issue however none of the above fixed it for me:

- kernel 4.1rc2 doesnt fix it
- booting with bluetooth of doesnt fix it either

it just says connecting and the goes back to disconnected state, exactly as stated above.

I also have a Y50 with an Intel 3160. I also updated the firmware but nothing seems to help...

[Ariel Keselman (skariel)]

actually the only thing that does work is going back to kernel 3.16

[Ariel Keselman (skariel)]

so at least I got that ;)

[Jan Newmarch (jan-newmarch)]

kernel 4.0.0 #1 SMP on a Gigabyte BXi7H-550. Behaviour is intermittent: sometimes it connects fine, sometimes it won't connect but the networks can be seen, sometimes the card is not visible to iwconfig.

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 3.19.0-20.20

---------------
linux (3.19.0-20.20) vivid; urgency=low

  [ Luis Henriques ]

  * Release Tracking Bug
    - LP: #1459957
  * Revert "SAUCE: Call i915_bpo specific functions from the hda driver"
    - LP: #1457369

linux (3.19.0-19.19) vivid; urgency=low

  [ Brad Figg ]

  * Release Tracking Bug
    - LP: #1458964

  [ Duc Dang ]

  * SAUCE: (no-up) [PCIE] APM X-Gene: Remove debug messages in MSI
    interrupt handler path.
    - LP: #1451593

  [ Luis Henriques ]

  * [Config] updateconfigs for 3.19.7 stable update

  [ Paolo Pisati ]

  * [Config] armhf: CPUFREQ_DT=y
    - LP: #1457781
  * annotations: enforce CPUFREQ_DT
    - LP: #1457781

  [ Tanmay Inamdar ]

  * SAUCE: (no-up) Add MSI/MSI-X driver for APM PCI bus
    - LP: #1451593

  [ Timo Aaltonen ]

  * SAUCE: i915_bpo: Rebase to v4.1-rc4.
    - LP: #1456123
  * SAUCE: i915_bpo: Revert dma-buf: cleanup dma_buf_export() to make it
    easily extensible
    - LP: #1456123

  [ Tuan Phan ]

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

  [ Upstream Kernel Changes ]

  * Revert "nfs: replace nfs_add_stats with nfs_inc_stats when add one"
    - LP: #1454699
  * cpufreq: powernv: Report cpu frequency throttling
    - LP: #1452547
  * x86: kvm: Revert "remove sched notifier for cross-cpu migrations"
    - LP: #1450584
  * x86: vdso: fix pvclock races with task migration
    - LP: #1450584
  * ip_forward: Drop frames with attached skb->sk
    - LP: #1454699
  * net: add skb_checksum_complete_unset
    - LP: #1454699
  * ppp: call skb_checksum_complete_unset in ppp_receive_frame
    - LP: #1454699
  * tcp: fix possible deadlock in tcp_send_fin()
    - LP: #1454699
  * tcp: avoid looping in tcp_send_fin()
    - LP: #1454699
  * net: do not deplete pfmemalloc reserve
    - LP: #1454699
  * net: fix crash in build_skb()
    - LP: #1454699
  * pxa168: fix double deallocation of managed resources
    - LP: #1454699
  * net/mlx4_en: Prevent setting invalid RSS hash function
    - LP: #1454699
  * md: fix md io stats accounting broken
    - LP: #1454699
  * x86/asm/decoder: Fix and enforce max instruction size in the insn
    decoder
    - LP: #1454699
  * sched/idle/x86: Restore mwait_idle() to fix boot hangs, to improve
    power savings and to improve performance
    - LP: #1454699
  * sched/idle/x86: Optimize unnecessary mwait_idle() resched IPIs
    - LP: #1454699
  * perf/x86/intel: Fix Core2,Atom,NHM,WSM cycles:pp events
    - LP: #1454699
  * KVM: x86: Fix MSR_IA32_BNDCFGS in msrs_to_save
    - LP: #1454699
  * Btrfs: fix log tree corruption when fs mounted with -o discard
    - LP: #1454699
  * btrfs: don't accept bare namespace as a valid xattr
    - LP: #1454699
  * Btrfs: fix inode eviction infinite loop after cloning into it
    - LP: #1454699
  * Btrfs: fix inode eviction infinite loop after extent_same ioctl
    - LP: #1454699
  * usb: gadget: printer: enqueue printer's response for setup request
    - LP: #1454699
  * KVM: s390: fix handling of write errors in the tpi handler
    - LP: #1454699
  * KVM: s390: reinjection of irqs can fail in the tpi handler
    - LP: #1454699
  * KVM:...

[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-vivid' to 'verification-done-vivid'.

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!

[Jason Gerard DeRose (jderose)]

I'm not sure what the relevant difference is, but I'm still having trouble connecting to 2.4GHz N networks with an Intel 3160 when running 3.19.0-20-generic from proposed (when Bluetooth is turned on). In particular, my 2.4GHz N SSID frequently isn't showing up in the list of available access points.

On the other hand, I didn't have trouble when I built my own kernel after cherry picking afcee962b09842d0f4191beb4a2d08251b4c7705 into the current (at the time) ubuntu-vivid.git tree. So I'm wondering if this patch is interacting badly with some other patch that has been merged into ubuntu-vivid in the meantime?

@boratko, have you had a chance to try 3.19.0-20-generic from proposed? If so, what's your experience been?

[Jason Gerard DeRose (jderose)]

Okay, after some more careful testing, afcee962b09842d0f4191beb4a2d08251b4c7705 does indeed fix the problem.

I was having some unrelated issues when connecting to 2.4GHz N when too far away from the access point (lots of WiFi interference here at System76 HQ).

But the important thing is that when running the 3.19.0-20-generic kernel from proposed, I can at least *sometimes* connect over N when bluetooth is enabled (assuming I'm close enough to the access point). Whereas with 3.19.0-18-generic and earlier, I could *never* connect, not even when only a few feet from the access point.

As such, I'm removing removing the "verification-needed-vivid " tag, adding "verification-done-vivid".

[Michael Boratko (boratko)]

The proposed kernel worked for me with bluetooth on.

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 3.19.0-20.20

---------------
linux (3.19.0-20.20) vivid; urgency=low

  [ Luis Henriques ]

  * Release Tracking Bug
    - LP: #1459957
  * Revert "SAUCE: Call i915_bpo specific functions from the hda driver"
    - LP: #1457369

linux (3.19.0-19.19) vivid; urgency=low

  [ Brad Figg ]

  * Release Tracking Bug
    - LP: #1458964

  [ Duc Dang ]

  * SAUCE: (no-up) [PCIE] APM X-Gene: Remove debug messages in MSI
    interrupt handler path.
    - LP: #1451593

  [ Luis Henriques ]

  * [Config] updateconfigs for 3.19.7 stable update

  [ Paolo Pisati ]

  * [Config] armhf: CPUFREQ_DT=y
    - LP: #1457781
  * annotations: enforce CPUFREQ_DT
    - LP: #1457781

  [ Tanmay Inamdar ]

  * SAUCE: (no-up) Add MSI/MSI-X driver for APM PCI bus
    - LP: #1451593

  [ Timo Aaltonen ]

  * SAUCE: i915_bpo: Rebase to v4.1-rc4.
    - LP: #1456123
  * SAUCE: i915_bpo: Revert dma-buf: cleanup dma_buf_export() to make it
    easily extensible
    - LP: #1456123

  [ Tuan Phan ]

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

  [ Upstream Kernel Changes ]

  * Revert "nfs: replace nfs_add_stats with nfs_inc_stats when add one"
    - LP: #1454699
  * cpufreq: powernv: Report cpu frequency throttling
    - LP: #1452547
  * x86: kvm: Revert "remove sched notifier for cross-cpu migrations"
    - LP: #1450584
  * x86: vdso: fix pvclock races with task migration
    - LP: #1450584
  * ip_forward: Drop frames with attached skb->sk
    - LP: #1454699
  * net: add skb_checksum_complete_unset
    - LP: #1454699
  * ppp: call skb_checksum_complete_unset in ppp_receive_frame
    - LP: #1454699
  * tcp: fix possible deadlock in tcp_send_fin()
    - LP: #1454699
  * tcp: avoid looping in tcp_send_fin()
    - LP: #1454699
  * net: do not deplete pfmemalloc reserve
    - LP: #1454699
  * net: fix crash in build_skb()
    - LP: #1454699
  * pxa168: fix double deallocation of managed resources
    - LP: #1454699
  * net/mlx4_en: Prevent setting invalid RSS hash function
    - LP: #1454699
  * md: fix md io stats accounting broken
    - LP: #1454699
  * x86/asm/decoder: Fix and enforce max instruction size in the insn
    decoder
    - LP: #1454699
  * sched/idle/x86: Restore mwait_idle() to fix boot hangs, to improve
    power savings and to improve performance
    - LP: #1454699
  * sched/idle/x86: Optimize unnecessary mwait_idle() resched IPIs
    - LP: #1454699
  * perf/x86/intel: Fix Core2,Atom,NHM,WSM cycles:pp events
    - LP: #1454699
  * KVM: x86: Fix MSR_IA32_BNDCFGS in msrs_to_save
    - LP: #1454699
  * Btrfs: fix log tree corruption when fs mounted with -o discard
    - LP: #1454699
  * btrfs: don't accept bare namespace as a valid xattr
    - LP: #1454699
  * Btrfs: fix inode eviction infinite loop after cloning into it
    - LP: #1454699
  * Btrfs: fix inode eviction infinite loop after extent_same ioctl
    - LP: #1454699
  * usb: gadget: printer: enqueue printer's response for setup request
    - LP: #1454699
  * KVM: s390: fix handling of write errors in the tpi handler
    - LP: #1454699
  * KVM: s390: reinjection of irqs can fail in the tpi handler
    - LP: #1454699
  * KVM:...

[govind (dagagovind)]

the problem ihave seen is in edit connection wi fi is showing IPv4 empty, even aftee editing it wifi is not connecting. though Ethernet connects.

[penalvch (penalvch)]

govind, as this report is closed, it has nothing to do with your problem. If you want your issue addressed, please file a new report via a terminal:
ubuntu-bug linux

Please feel free to subscribe me to it.

[govind (dagagovind)]

the problem got solved by inter changing configuration to various options
given in network edit . I change d to automatic to manual and then to local
links.. after opting to local links some local configuration appeared in
IPv4 section,, Here i changed /edited to my service provider's IP, net-mask
and dns server... LOL wifi now ok. Ubuntu 15-.04.

See i am not a technical person but have turned to a best driver for Ubuntu.

On 18 September 2015 at 15:07, Christopher M. Penalver <
<email address hidden>> wrote:

> govind, as this report is closed, it has nothing to do with your problem.
> If you want your issue addressed, please file a new report via a terminal:
> ubuntu-bug linux
>
> Please feel free to subscribe me to it.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1442411
>
> Title:
> Intel 3160 wireless card no longer able to connect to wifi networks
>
> Status in System76:
> Fix Released
> Status in linux package in Ubuntu:
> Fix Released
> Status in linux source package in Vivid:
> Fix Released
>
> Bug description:
> [Impact]
>
> Laptop: Lenovo Y70 Touch
> Wireless Card: Intel Corporation Wireless 3160 (rev 93)
>
> When running Ubuntu Gnome 14.10 (on a live USB drive) I am able to
> connect to wifi networks without any issue. When running Ubuntu Gnome
> 15.04 (either on live USB or installed and fully updated) I am able to
> see the list of available wifi networks, but not able to connect.
> Selecting one and entering the password makes the network manager
> applet indicate that it is "Connecting..." but then it gives up after
> about a minute or so and reverts back to "Not Connected". I have
> tested this without network encryption as well, and the same result
> occurs.
>
> [Test Case]
>
> I have ran a wifi debugging script, here is the output:
>
> For Ubuntu 14.10 - http://pastebin.com/aLUhTyrM
> For Ubuntu 15.04 - http://pastebin.com/f0yRjQUC
>
> Again, the card seems to work perfectly on 14.10, but is unable to
> connect to any networks on 15.04.
>
> [Fix]
>
> commit afcee962b09842d0f4191beb4a2d08251b4c7705 upstream
>
> [Workaround]
>
> Boot with bluetooth turned off. If the computer boots with the
> bluetooth turned on, the wifi will not work, even if you first turn
> off the bluetooth. A restart is needed.
>
> ---
> ApportVersion: 2.17-0ubuntu2
> Architecture: amd64
> AudioDevicesInUse:
> USER PID ACCESS COMMAND
> /dev/snd/controlC0: mboratko 1609 F.... pulseaudio
> /dev/snd/controlC1: mboratko 1609 F.... pulseaudio
> CurrentDesktop: GNOME
> DistroRelease: Ubuntu 15.04
> EcryptfsInUse: Yes
> InstallationDate: Installed on 2015-04-10 (0 days ago)
> InstallationMedia: Ubuntu-GNOME 15.04 "Vivid Vervet" - Beta amd64
> (20150326)
> MachineType: LENOVO 80DU
> Package: linux (not installed)
> ProcEnviron:
> TERM=xterm
> PATH=(custom, no user)
> XDG_RUNTIME_DIR=<set>
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> ProcFB: 0 inteldrmfb
> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-12-generic.efi.signed
> root=UUID=0fb46cba-f7ac-4bc5-...