Bug 205299 - iwlwifi: ax200: Failed to wake NIC; failed with error -110 (timeout)
Summary: iwlwifi: ax200: Failed to wake NIC; failed with error -110 (timeout)
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: network-wireless-intel (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: Default virtual assignee for network-wireless-intel
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-23 20:59 UTC by Thomas Weißschuh
Modified: 2021-05-30 23:38 UTC (History)
12 users (show)

See Also:
Kernel Version: 5.3.7, 5.4-rc4
Tree: Mainline
Regression: No


Attachments
ftrace for iwlwifi init (1.88 MB, text/plain)
2020-12-07 08:18 UTC, sandy.8925
Details

Description Thomas Weißschuh 2019-10-23 20:59:11 UTC
Device: Intel Corporation Wi-Fi 6 AX 200 (rev 1a)
Firmware: 20191022 (2b016af)

On boot the device is detected (shows up in lspci) but the initialization from iwlwifi fails with the following log in dmesg:

$ dmesg |grep iwlwifi
[    4.983570] iwlwifi 0000:04:00.0: enabling device (0000 -> 0002)
[    4.983762] iwlwifi 0000:04:00.0: U _iwl_disable_interrupts Disabled interrupts
[    4.983766] iwlwifi 0000:04:00.0: U iwl_pcie_prepare_card_hw iwl_trans_prepare_card_hw enter
[    4.983776] iwlwifi 0000:04:00.0: U iwl_pcie_set_hw_ready hardware ready
[    5.036621] iwlwifi 0000:04:00.0: U iwl_finish_nic_init Failed to wake NIC
[    5.080453] iwlwifi: probe of 0000:04:00.0 failed with error -110


The device does *not* appear as a network interface.

For testing I increased the initialization timeout in iwl_finish_nic_init() from 25000 to 225000 microseconds, which did not help.

The device worked before but stopped at some point (if there is interest, I can try to bisect).
The device works under windows.

Note:

After rebooting once into windows it now also works on Linux, even after further reboots.
But the issue definitively happened before. I reproduced it in over 30 consecutive boots. (Even with windows boots in between).
Comment 1 mxunknown 2020-01-27 22:27:17 UTC
I have encountered this same issue when using Proxmox VE and alternating boots of Windows with Linux. 

If the Wi-Fi adapter is passed through to windows, and I shutdown in regular fashion, this error appears both on the host machine or a Linux VM. However, if I disable the WiFi adapter in Windows before shutting down, the adapter is available both in the host, or the Linux VM, if I pass it through.

All of this leads me to think that this is an issue with how Windows interacts with the WiFi adapter, possibly setting some sort of 'claim' flag on the adapter.
Comment 2 Tom Tang 2020-02-07 09:31:49 UTC
Hi - my scenario is as follows.  Ubuntu 20.04 (5.4.0.9-generic) on AMD Ryzen platform with backported Intel drivers following the instructions.  When I cold boot into Ubuntu, the wireless driver never works.  When I boot into Windows and then warm boot into Ubuntu, the wireless driver works.  Something seems to be wrong with the Linux drivers??  Replication of scenario is 100%...


dmesg | grep iwlwifi (when it does not work)
[    3.851895] Loading modules backported from iwlwifi
[    3.851896] iwlwifi-stack-public:master:8324:9176b151
[    3.872051] iwlwifi 0000:05:00.0: enabling device (0000 -> 0002)
[    3.968122] iwlwifi: probe of 0000:05:00.0 failed with error -110

dmesg | grep iwlwifi (when it does work)
[    3.916619] Loading modules backported from iwlwifi
[    3.916620] iwlwifi-stack-public:master:8324:9176b151
[    3.999711] iwlwifi 0000:05:00.0: enabling device (0000 -> 0002)
[    4.003067] iwlwifi 0000:05:00.0: Direct firmware load for iwl-dbg-cfg.ini failed with error -2
[    4.003083] iwlwifi 0000:05:00.0: Direct firmware load for iwlwifi-cc-a0-55.ucode failed with error -2
[    4.003091] iwlwifi 0000:05:00.0: Direct firmware load for iwlwifi-cc-a0-54.ucode failed with error -2
[    4.003099] iwlwifi 0000:05:00.0: Direct firmware load for iwlwifi-cc-a0-53.ucode failed with error -2
[    4.003106] iwlwifi 0000:05:00.0: Direct firmware load for iwlwifi-cc-a0-52.ucode failed with error -2
[    4.003114] iwlwifi 0000:05:00.0: Direct firmware load for iwlwifi-cc-a0-51.ucode failed with error -2
[    4.003122] iwlwifi 0000:05:00.0: Direct firmware load for iwlwifi-cc-a0-50.ucode failed with error -2
[    4.003130] iwlwifi 0000:05:00.0: Direct firmware load for iwlwifi-cc-a0-49.ucode failed with error -2
[    4.009606] iwlwifi 0000:05:00.0: TLV_FW_FSEQ_VERSION: FSEQ Version: 43.2.23.17
[    4.009609] iwlwifi 0000:05:00.0: Found debug destination: EXTERNAL_DRAM
[    4.009610] iwlwifi 0000:05:00.0: Found debug configuration: 0
[    4.009771] iwlwifi 0000:05:00.0: loaded firmware version 48.4fa0041f.0 cc-a0-48.ucode op_mode iwlmvm
[    4.009788] iwlwifi 0000:05:00.0: Direct firmware load for iwl-debug-yoyo.bin failed with error -2
[    4.093285] iwlwifi 0000:05:00.0: Detected Intel(R) Wi-Fi 6 AX200 160MHz, REV=0x340
[    4.105169] iwlwifi 0000:05:00.0: Applying debug destination EXTERNAL_DRAM
[    4.105459] iwlwifi 0000:05:00.0: Allocated 0x00400000 bytes for firmware monitor.
[    4.253935] iwlwifi 0000:05:00.0: base HW address: dc:71:96:88:04:69
[    4.757357] iwlwifi 0000:05:00.0 wlp5s0: renamed from wlan0
[    5.448423] iwlwifi 0000:05:00.0: Applying debug destination EXTERNAL_DRAM
[    5.597301] iwlwifi 0000:05:00.0: FW already configured (0) - re-configuring
Comment 3 Emil Dimitrov 2020-04-01 14:52:53 UTC
I encountered the same issue with Intel 9260 on a dual-boot Ubuntu 18.04 and Windows 10. Disabling fast-boot in Windows solved the issue for me:

https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi#about_dual-boot_with_windows_and_fast-boot_enabled
Comment 4 Sebastian Meric de Bellefon 2020-05-04 15:58:59 UTC
Disabling fast-boot in Windows also solved the issue for me. Windows 10, kernel 5.7.0 rc3 and Intel AX200 Wi-Fi adapter.
Comment 5 sandy.8925 2020-12-06 14:44:29 UTC
(In reply to Thomas Weißschuh from comment #0)
> Device: Intel Corporation Wi-Fi 6 AX 200 (rev 1a)
> Firmware: 20191022 (2b016af)
> 
> On boot the device is detected (shows up in lspci) but the initialization
> from iwlwifi fails with the following log in dmesg:
> 
> $ dmesg |grep iwlwifi
> [    4.983570] iwlwifi 0000:04:00.0: enabling device (0000 -> 0002)
> [    4.983762] iwlwifi 0000:04:00.0: U _iwl_disable_interrupts Disabled
> interrupts
> [    4.983766] iwlwifi 0000:04:00.0: U iwl_pcie_prepare_card_hw
> iwl_trans_prepare_card_hw enter
> [    4.983776] iwlwifi 0000:04:00.0: U iwl_pcie_set_hw_ready hardware ready
> [    5.036621] iwlwifi 0000:04:00.0: U iwl_finish_nic_init Failed to wake NIC
> [    5.080453] iwlwifi: probe of 0000:04:00.0 failed with error -110
> 
> 
> The device does *not* appear as a network interface.
> 
> For testing I increased the initialization timeout in iwl_finish_nic_init()
> from 25000 to 225000 microseconds, which did not help.
> 
> The device worked before but stopped at some point (if there is interest, I
> can try to bisect).
> The device works under windows.
> 
> Note:
> 
> After rebooting once into windows it now also works on Linux, even after
> further reboots.
> But the issue definitively happened before. I reproduced it in over 30
> consecutive boots. (Even with windows boots in between).

I have the exact same problem! I also debugged and figured out it was in the same function. The call to iwl_poll_bit ultimately fails, and after that the device refuses to work.

It usually happens after suspend/hibernate and resume, but I am not able to reproduce it reliably.
Comment 6 d 2020-12-06 15:37:48 UTC
Isn't this a duplicate of https://bugzilla.kernel.org/show_bug.cgi?id=203709?
Comment 7 sandy.8925 2020-12-07 08:15:32 UTC
(In reply to d from comment #6)
> Isn't this a duplicate of https://bugzilla.kernel.org/show_bug.cgi?id=203709?

No, when I get this error, the device is unavailable (i.e there's no wireless device like wlan0), because device init fails.
Comment 8 sandy.8925 2020-12-07 08:18:24 UTC
Created attachment 293973 [details]
ftrace for iwlwifi init

ftrace that starts from the PCI probe function where the following message gets printed out: 

iwlwifi: probe of 0000:04:00.0 failed with error -110
Comment 9 sandy.8925 2020-12-29 16:37:04 UTC
Well if the Windows Fast boot disable workaround is real, then this comment from the driver code might explain it "Later devices (5xxx/6xxx/1xxx) use non-volatile SRAM, and do not need to save/restore it."

If Windows writes some values to the device SRAM, and it remains after shutdown and reboot as well, it might be screwing up device state in dual boot situations. And then I wonder what happens with hibernate as well. Is there any way to just tell the drivers in both Windows and Linux to always re-init from scratch and not rely on the device state staying the same?
Comment 10 sandy.8925 2020-12-29 17:06:06 UTC
Further info about my system:
Linux version: 5.10.1
Firmware version: iwlwifi-cc-a0-59.ucode
Hardware: Intel Wifi AX200, embedded in an MSI x570 motherboard
Comment 11 phackwer 2021-05-30 23:38:23 UTC
I have the same situation here. This is probably because Windows somehow tries to do what MacOS does and keep waking it self up from time to time to get data from the network. Somehow there is something that keeps the card attached to that OS, and even with the boot of a new one, the card is not made available by the BIOS. Sounds not correct, but, if someone has a better explanation...

Sandy.8925 comment makes a lot of sense. So, major problem would be that Intel wifi card keeps instructions there. Should the boot process force a clean on the SRAM to make sure it gets fixed? Would this affect the normal behaviour of the card somehow? I would say that the call to ignore SRAM instructions should be the default, but I never really needed them to say they are needed.

Note You need to log in before you can comment on or make changes to this bug.