Wifi not working after suspend/resume cycle

[David Britton]

About 75% of the time for the past few weeks (I don't have a time where this started), my wifi is not working after resume from suspend. I'm happy to provide more debugging info if needed.

I have tried an rmmod/modprobe on on the iwlwifi,iwlmvm modules just to see after the resume, and didn't re-enable the card.

The symptoms are, the wlp4so interface is DOWN, I can't bring it up. gnome-network-manager widget turning the interface off/on doesn't work. I don't see anything glaring in dmesg.

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: linux-image-generic 5.0.0.14.15
ProcVersionSignature: Ubuntu 5.0.0-14.15-generic 5.0.6
Uname: Linux 5.0.0-14-generic x86_64
ApportVersion: 2.20.10-0ubuntu27
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: dpb 4587 F.... pulseaudio
CurrentDesktop: ubuntu:GNOME
Date: Tue May 7 18:49:01 2019
InstallationDate: Installed on 2018-06-18 (323 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
MachineType: LENOVO 20HRCTO1WW
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-14-generic root=UUID=fa64d67d-26bf-4c42-a12f-c45b6ea5117c ro quiet splash vt.handoff=1
RelatedPackageVersions:
 linux-restricted-modules-5.0.0-14-generic N/A
 linux-backports-modules-5.0.0-14-generic N/A
 linux-firmware 1.178
SourcePackage: linux
UpgradeStatus: Upgraded to disco on 2019-03-15 (53 days ago)
dmi.bios.date: 02/14/2019
dmi.bios.vendor: LENOVO
dmi.bios.version: N1MET52W(1.37)
dmi.board.asset.tag: Not Available
dmi.board.name: 20HRCTO1WW
dmi.board.vendor: LENOVO
dmi.board.version: Not Defined
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias: dmi:bvnLENOVO:bvrN1MET52W(1.37):bd02/14/2019:svnLENOVO:pn20HRCTO1WW:pvrThinkPadX1Carbon5th:rvnLENOVO:rn20HRCTO1WW:rvrNotDefined:cvnLENOVO:ct10:cvrNone:
dmi.product.family: ThinkPad X1 Carbon 5th
dmi.product.name: 20HRCTO1WW
dmi.product.sku: LENOVO_MT_20HR_BU_Think_FM_ThinkPad X1 Carbon 5th
dmi.product.version: ThinkPad X1 Carbon 5th
dmi.sys.vendor: LENOVO

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This change was made by a bot.

[David Britton (dpb)]

Also note, the following sequence seems to avoid the problem so far (4/4 in testing, not conclusive, but it's looking good):

```
dpb@aries:~[]$ sudo modprobe -r iwlmvm
# Suspend/Resume, then...
dpb@aries:~[]$ sudo modprobe iwlmvm
```

[Andrea Righi (arighi)]

Can you try to set the following before suspend:

 echo 0 > /sys/class/net/wlp4s0/device/d3cold_allowed

And then test a suspend/resume cycle.

[David Britton (dpb)]

Hi Andrea -- Thanks for the suggestion.

I attempted this and it seems to not help. The first suspend/resume worked, and I was hopeful, but after 4 more attempts (obviously I have reboots in between each failed attempt), it didn't prove to be a solid option.

FYI, so far the comment I made in #3 still holds true

[Andrea Righi (arighi)]

Interesting that the d3cold_allowed change made some differences (I'm assuming it was failing 100% of the times before that change).

Few more questions. After a bad resume:

1) are there unkillable processes (D state) in the system (`ps axuw | grep D`)?

2) does `sudo iwlist wlp4s0 scan` return any error or does it hang indefinitely?

3) do you have bluetooth enabled (what's the output of `sudo rfkill list`)?

As a temporary workaround you can automate the modprobe trick (#3) doing something like the following:

$ cat /lib/systemd/system-sleep/iwlmvm.sh
#!/bin/sh
case $1 in
    pre)
        modprobe -r iwlmvm
        ;;
    post)
        modprobe iwlmvm
        ;;
esac

But it'd be nice to find a proper solution to this. Thanks!

[David Britton (dpb)]

Hi Andrea --

1) No D state processes
2) interestingly, `iwlist wlp4s0 scan` shows data like usual
3) rfkill shows everything off

I'm going to read up on how to connect to networks from iwconfig and see if that helps me at all. I'm attaching a debug.txt file with a bunch of the output you asked for.

[David Britton (dpb)]

Restarting network-manager.service fixes the issue reliably. I'm going to see if there is more in the log there to determine what is failing.

[Terry Rudd (terrykrudd)]

Hello David, any new information on this problem?

[Sebastien Bacher (seb128)]

The issue would probably be best reported upstream on https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/

[Till Kamppeter (till-kamppeter)]

Reported upstream as

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/213

[Launchpad Janitor (janitor)]

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