Network Manager: 'Device not ready' after suspend.

[Andrew Morgan]

Hello all,

As of late (past couple days), I have been unable to connect to WiFi
networks without a full shutdown and restart of sys-net. After every
time I suspend the computer I get the message that my WiFi card says
'device not ready', and it is unable to scan for WiFi networks.
Restarting NetworkManager.service does not fix the issue.

Looking at dmesg, it seems to be some problem relating to Intel
micro-code? I am using an Intel WiFi card (Intel 7260 rev bb)

Output of dmesg:

...
[ 24.137165] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[ 24.138983] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[ 24.308169] Bluetooth: hci0: Intel Bluetooth firmware patch completed
and activated
[ 28.825199] iwlwifi 0000:00:01.0: Failed to load firmware chunk!
[ 28.825231] iwlwifi 0000:00:01.0: Could not load the [0] uCode section
[ 28.825257] iwlwifi 0000:00:01.0: Failed to start INIT ucode: -110
[ 28.825273] iwlwifi 0000:00:01.0: Failed to run INIT ucode: -110
[ 28.842749] iwlwifi 0000:00:01.0: L1 Enabled - LTR Enabled
[ 28.843070] iwlwifi 0000:00:01.0: L1 Enabled - LTR Enabled
[ 33.843189] iwlwifi 0000:00:01.0: Failed to load firmware chunk!
[ 33.843222] iwlwifi 0000:00:01.0: Could not load the [0] uCode section
[ 33.843247] iwlwifi 0000:00:01.0: Failed to start INIT ucode: -110
[ 33.843262] iwlwifi 0000:00:01.0: Failed to run INIT ucode: -110
[ 33.844903] iwlwifi 0000:00:01.0: L1 Enabled - LTR Enabled
[ 33.845279] iwlwifi 0000:00:01.0: L1 Enabled - LTR Enabled
...

Kernel version: 4.9.35-20.pvops.qubes.x86_64
Though also occurs on last known good kernel version, 4.4.67-13.

I was messing around with bad internet at a hotel while on vacation and
remember running in sys-net:

sudo ip link set wlp0s0 up

Though I have done with this without consequence on other computers, and
am not sure if it is related, but it is the only possible 'change' I
have made as of late besides possibly an update to either fedora25 or dom0.

Thank you for any possible insight!
Andrew Morgan

[djef...@linuxfoundation.org]

> As of late (past couple days), I have been unable to connect to WiFi
> networks without a full shutdown and restart of sys-net. After every
> time I suspend the computer I get the message that my WiFi card says
> 'device not ready', and it is unable to scan for WiFi networks.
> Restarting NetworkManager.service does not fix the issue.
>
> Looking at dmesg, it seems to be some problem relating to Intel
> micro-code? I am using an Intel WiFi card (Intel 7260 rev bb)
>

I'm fighting the same problem at the moment (along with some random freezing) that seems to have started with the last dom0 update. Does that seem to correlate with the time you saw this behavior start?

I'm running an Intel 7265 rev 59.

[Andrew Morgan]

I did perform a dom0 update a few days ago, but I think this behavior only started after restarting Qubes fully.

Do you have security-testing enabled in dom0? Perhaps it is an issue with an unstable kernel/xen version.

Andrew Morgan

[djef...@linuxfoundation.org]

On Wednesday, August 23, 2017 at 2:38:11 PM UTC-6, Andrew Morgan wrote:
> I did perform a dom0 update a few days ago, but I think this behavior only started after restarting Qubes fully.
>
>
>
> Do you have security-testing enabled in dom0? Perhaps it is an issue with an unstable kernel/xen version.
>

I have been exploring that possibility. Right now I'm back at 4.9.35-19.pvops.qubes.x86_64 and seeing the same issue. You said you rolled back to 4.4.67-13 and were still seeing it, though, right? That has me wanting to look closer at any qubes-specific changes that may have been in the last update. I've been seeing this happen on 3 out of 4 identical-hardware systems and trying to figure out why the 4th one is fine.

Right now I'm trying to chase down the freezing issues I'm getting on one system, which seem to be a different problem and not something I'm seeing on any of the other identical hardware, but I'll look into the update notes after that.

Dan

[Andrew Morgan]

I tried that kernel on sys-net with no change yes, but dom0's kernel has not changed.

Would it perhaps be an issue with xen's PCI passthrough functionality? Could it be left in a broken state after a suspend and thus sys-net is not able to have proper access to the network device?

Thanks for helping with testing and debugging.

Andrew Morgan

[Reg Tiangha]

On 2017-08-23 3:08 PM, Andrew Morgan wrote:
> I tried that kernel on sys-net with no change yes, but dom0's kernel has
> not changed.
>
> Would it perhaps be an issue with xen's PCI passthrough functionality?
> Could it be left in a broken state after a suspend and thus sys-net is
> not able to have proper access to the network device?
>
> Thanks for helping with testing and debugging.
>
> Andrew Morgan
>

Have you guys tried blacklisting your wireless driver modules as per
these instructions here:

https://www.qubes-os.org/doc/wireless-troubleshooting/#automatically-reloading-drivers-on-suspendresume

The people who have been experiencing the same issues say that this
workaround works.

[djef...@linuxfoundation.org]

Thanks, I hadn't found that page yet. Unfortunately, that doesn't seem to fix it.

Andrew, in your case, when the wifi locks up, do you sometimes/always get issues in dom0 as well? For example, I can have problems where I can't open or run certain binaries, but not all binaries have problems. Right now I can't open the dom0 terminal. I get:
Failed to execute command "exo-open --launch TerminalEmulator" Failed to execute child process "exo-open" (input/output error)

The input/output error is what I get if I had the terminal open before suspending and attempt something like lspci or attempting ls/vi a log.

At this point, I'm looking at https://github.com/QubesOS/qubes-issues/issues/2922 to see if that is related.

[djef...@linuxfoundation.org]

> At this point, I'm looking at https://github.com/QubesOS/qubes-issues/issues/2922 to see if that is related.

I decided the previous bug may not be the same so I opened a new issue if you want to follow/join in, Andrew.

https://github.com/QubesOS/qubes-issues/issues/3049

[Adrian Rocha]

Hi,

I had the same issue, and the workaround metioned by Reg worked for me:

https://www.qubes-os.org/doc/wireless-troubleshooting/#automatically-reloading-drivers-on-suspendresume

Maybe there are two differen issues.
Just to be sure, do you restarted the sys-net after modify the /rw/config/suspend-module-blacklist file?

[Andrew Morgan]

Yep, with the following contents of /rw/config/suspend-module-blacklist,
it now works!

mac80211
iwlmvm
iwlwifi
cfg80211

Thanks!
Andrew Morgan