Bug 201319

I've updated to kernel 4.18.12-arch1-1-ARCH and am no longer encountering the issue. Wi-Fi is working fine now and so is Bluetooth.

Thanks for reporting back!

Unfortunately. Today I'm getting the same issue again. I've got a dual-boot with Windows. Maybe it's because I booted into Windows and back into Arch which caused something to change?

And now it works again. I guess it's a lottery with me given the lowest odds.

We'll assign this to someone to see if we can figure anything out.  Please keep us posted in case you find anything out.

I also got the same issue. From what I see, if I restart in Windows then I can use wifi afterward. But if I shutdown in Windows, then I got the timeout error in iwlwifi.

I have tested what hgmin95 says and I am experiencing the same. Restarting in Windows means that I can use it in Linux and shutdown in Windows means I cannot. Very odd.

I have been experiencing the same thing with dual boot from windows. After reboot from windows to Ubuntu 18.04.1 no wifi, Reboot from ubuntu to ubuntu and wifi starts working.

My wifi hw is:
~$ sudo lspci -knn | grep Wire -A3
Network controller [0280]: Intel Corporation Wireless 8265 / 8275 [8086:24fd] (rev 78)
Subsystem: Intel Corporation Wireless 8265 / 8275 [8086:8110]
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi

I also dual boot with Windows and KDE neon 18.04, and I too have issues with iwlwifi.  However, I have noticed it appears to be from cold boot only.  The first time I power on and boot into KDE neon, my wifi almost certainly will not work.  After rebooting, it works fine. The mobo is a Gigabyte X470 Aorus Gaming 7 Wifi, with BIOS F4g (BIOS F4 and F5 are newer, but they break virtualization and suspend within Linux due to an AGESA bug).

Here are my details:

$ lspci -k

07:00.0 Network controller: Intel Corporation Device 2526 (rev 29)
        Subsystem: Intel Corporation Device 0014
        Kernel driver in use: iwlwifi
        Kernel modules: iwlwifi

$ dmesg | grep wifi

[    6.668309] iwlwifi 0000:07:00.0: enabling device (0000 -> 0002)
[    6.792193] iwlwifi: probe of 0000:07:00.0 failed with error -110

$ dmesg | grep firmware

[    6.599143] iwlwifi 0000:07:00.0: loaded firmware version 38.c0e03d94.0 op_mode iwlmvm

Can you please try to blacklist btusb and do a cold reboot?
This will of course disable BT, but will let us know a bit more about this issue.

Also, if someone can try this:


diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-io.c b/drivers/net/wireless/intel/iwlwifi/iwl-io.c
index fccb63a32..370f602b5 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-io.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-io.c
@@ -113,6 +113,7 @@ int iwl_poll_bit(struct iwl_trans *trans, u32 addr,
                t += IWL_POLL_INTERVAL;
        } while (t < timeout);

+       dump_stack();
        return -ETIMEDOUT;
 }
 IWL_EXPORT_SYMBOL(iwl_poll_bit);
@@ -164,6 +165,7 @@ int iwl_poll_direct_bit(struct iwl_trans *trans, u32 addr, u32 mask,
                t += IWL_POLL_INTERVAL;
        } while (t < timeout);

+       dump_stack();
        return -ETIMEDOUT;
 }
 IWL_EXPORT_SYMBOL(iwl_poll_direct_bit);
@@ -227,6 +229,7 @@ int iwl_poll_prph_bit(struct iwl_trans *trans, u32 addr,
                t += IWL_POLL_INTERVAL;
        } while (t < timeout);

+       dump_stack();
        return -ETIMEDOUT;
 }






Thanks.

I get a slightly different response from `dmesg`:



[    4.630318] iwlwifi 0000:3b:00.0: enabling device (0000 -> 0002)
[    4.652342] iwlwifi 0000:3b:00.0: Direct firmware load for iwlwifi-9260-th-b0-jf-b0-38.ucode failed with error -2
[    4.652351] iwlwifi 0000:3b:00.0: Direct firmware load for iwlwifi-9260-th-b0-jf-b0-37.ucode failed with error -2
[    4.652363] iwlwifi 0000:3b:00.0: Direct firmware load for iwlwifi-9260-th-b0-jf-b0-36.ucode failed with error -2
[    4.652369] iwlwifi 0000:3b:00.0: Direct firmware load for iwlwifi-9260-th-b0-jf-b0-35.ucode failed with error -2
[    4.652374] iwlwifi 0000:3b:00.0: Direct firmware load for iwlwifi-9260-th-b0-jf-b0-34.ucode failed with error -2
[    4.652380] iwlwifi 0000:3b:00.0: Direct firmware load for iwlwifi-9260-th-b0-jf-b0-33.ucode failed with error -2
[    4.652385] iwlwifi 0000:3b:00.0: Direct firmware load for iwlwifi-9260-th-b0-jf-b0-32.ucode failed with error -2
[    4.652391] iwlwifi 0000:3b:00.0: Direct firmware load for iwlwifi-9260-th-b0-jf-b0-31.ucode failed with error -2
[    4.652397] iwlwifi 0000:3b:00.0: Direct firmware load for iwlwifi-9260-th-b0-jf-b0-30.ucode failed with error -2
[    4.652397] iwlwifi 0000:3b:00.0: no suitable firmware found!
[    4.652398] iwlwifi 0000:3b:00.0: minimum version required: iwlwifi-9260-th-b0-jf-b0-30
[    4.652399] iwlwifi 0000:3b:00.0: maximum version supported: iwlwifi-9260-th-b0-jf-b0-38
[    4.652400] iwlwifi 0000:3b:00.0: check git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

lspci -k
...
3b:00.0 Network controller: Intel Corporation Wireless-AC 9260 (rev 29)
	Subsystem: Intel Corporation Device 4010
	Kernel modules: iwlwifi
...

@Robert, this absolutely not related to this bug.
Please install the firmware. But, please do not reply to not hijack this bug.

Thank you.

@Emmanuel, apologies, brief moment of insanity,

dnf groupinstall hardware-support

resolved that issue unrelated to this bug report.

@Emmanuel, blacklist btusb makes the wifi work

$ tail /etc/modprobe.d/blacklist.conf -n1
blacklist btusb

$ dmesg | grep iwlwifi
[    2.908494] iwlwifi 0000:03:00.0: enabling device (0000 -> 0002)
[    2.913394] iwlwifi 0000:03:00.0: loaded firmware version 38.c0e03d94.0 op_mode iwlmvm
[    2.933919] iwlwifi 0000:03:00.0: Detected Intel(R) Dual Band Wireless AC 9260, REV=0x324

I will try to figure out how to add these dump_stack().

Unfortunately I do not have the time the coming 2 months to provide feedback because of exams. I've currently resorted to installing a wired socket by my desk so I can use that. Sorry for not being able to help debug the problem.

Ok, I'll close this for now. If someone can help, he can reopen the bug.

Created attachment 280589 [details]
Output of proposed dump_stack() call

For me, the bug occurs whenever I boot into Windows and then back into Linux. The bug goes away when I boot again into Linux, no matter whether I shut down and turn the machine back on, or just reboot.

Here are the outputs of lspci -vv , merged into a unified diff:

--- ok-lspci-vv.txt	2019-01-18 18:05:14.682005050 +0200
+++ bug-lspci-vv.txt	2019-01-18 18:07:56.435000630 +0200
@@ -1,34 +1,32 @@
 00:14.3 Network controller: Intel Corporation Device a370 (rev 10)
 	Subsystem: Intel Corporation Device 02a4
-	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
+	Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
-	Latency: 0, Cache Line Size: 64 bytes
 	Interrupt: pin A routed to IRQ 16
 	Region 0: Memory at a4314000 (64-bit, non-prefetchable) [size=16K]
 	Capabilities: [c8] Power Management version 3
 		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
 		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
 	Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
 		Address: 0000000000000000  Data: 0000
 	Capabilities: [40] Express (v2) Root Complex Integrated Endpoint, MSI 00
 		DevCap:	MaxPayload 128 bytes, PhantFunc 0
 			ExtTag- RBE-
 		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
 			RlxdOrd+ ExtTag- PhantFunc- AuxPwr+ NoSnoop+
 			MaxPayload 128 bytes, MaxReadReq 128 bytes
 		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
 		DevCap2: Completion Timeout: Range B, TimeoutDis+, LTR+, OBFF Via WAKE#
 			 AtomicOpsCap: 32bit- 64bit- 128bitCAS-
 		DevCtl2: Completion Timeout: 16ms to 55ms, TimeoutDis-, LTR+, OBFF Disabled
 			 AtomicOpsCtl: ReqEn-
-	Capabilities: [80] MSI-X: Enable+ Count=16 Masked-
+	Capabilities: [80] MSI-X: Enable- Count=16 Masked-
 		Vector table: BAR=0 offset=00002000
 		PBA: BAR=0 offset=00003000
 	Capabilities: [100 v0] #00
 	Capabilities: [14c v1] Latency Tolerance Reporting
 		Max snoop latency: 0ns
 		Max no snoop latency: 0ns
 	Capabilities: [164 v1] Vendor Specific Information: ID=0010 Rev=0 Len=014 <?>
-	Kernel driver in use: iwlwifi
 	Kernel modules: iwlwifi

I have the same or a very similar issue. Since I booted Windows again I can not access any wifi anymore. No matter how often I boot intow Linux again.
dmesg | grep iwlwifi shows the following output.

[    3.445668] iwlwifi: probe of 0000:17:00.0 failed with error -110

dmesg | grep firmware shows the following output (appears unrelated to me, but I I give it for completeness).

[    3.532814] [drm] Found UVD firmware Version: 1.130 Family ID: 16
[    3.534169] [drm] Found VCE firmware Version: 53.26 Binary ID: 3

Here is the output of lspci -k regarding wifi.

17:00.0 Network controller: Intel Corporation Wireless-AC 9260 (rev 29)
        DeviceName: Broadcom 5762
        Subsystem: Intel Corporation Wireless-AC 9260
        Kernel modules: iwlwifi

I run kernel version 4.20.6. I am not that familiar with kernel debugging, but if can help to fix this issue in any way I will be happy to help.

Please install the latest firmware from BT:

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/intel/ibt-18-16-1.sfi
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/intel/ibt-18-2.sfi

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/intel/ibt-17-16-1.sfi
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/intel/ibt-17-2.sfi


Then shutdown the system (not reboot!) and then test again.

Thanks.

Ping?

(In reply to Emmanuel Grumbach from comment #20)
> Please install the latest firmware from BT:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
> plain/intel/ibt-18-16-1.sfi
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
> plain/intel/ibt-18-2.sfi
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
> plain/intel/ibt-17-16-1.sfi
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
> plain/intel/ibt-17-2.sfi
> 
> 
> Then shutdown the system (not reboot!) and then test again.
> 
> Thanks.

Sorry it took me so long to answer you. Here is a short update.

In the meantime, the WiFi started to work normally again, even though I did not change anything. So, it seems to me, that the behavior of my pc is pretty much the same as the behavior Andreas, Heikki, Colin and Taneli observed. Just that for me, it takes more boot-reboot cycles to work again.

However, booting into Windows and then into Linux again reproduced the problem.
As a (maybe unrelated) side note: When I booted into Windows, the WiFi did not connect automatically even though I configured it earlier.

After I reproduced the problem, I downloaded the latest version of the files you linked and placed them in /lib/firmware/intel/, shutdown the pc and then restarted it. However, nothing changed. The WiFi still does not show up and all the outputs I listed above are still the same.

> 
> In the meantime, the WiFi started to work normally again, even though I did
> not change anything. So, it seems to me, that the behavior of my pc is
> pretty much the same as the behavior Andreas, Heikki, Colin and Taneli
> observed. Just that for me, it takes more boot-reboot cycles to work again.
> 
> However, booting into Windows and then into Linux again reproduced the
> problem.
> As a (maybe unrelated) side note: When I booted into Windows, the WiFi did
> not connect automatically even though I configured it earlier.

This is clearly not related. This is an internal Windows problem (if we consider this as a problem).

> 
> After I reproduced the problem, I downloaded the latest version of the files
> you linked and placed them in /lib/firmware/intel/, shutdown the pc and then
> restarted it. However, nothing changed. The WiFi still does not show up and
> all the outputs I listed above are still the same.

Ok, at this point, I guess that what would help would be to try to take our backport driver and put lots of prints in the probe function to see where we get stuck.
Would it be something doable on your side? (I'd provide the code to compile of course).

(In reply to Emmanuel Grumbach from comment #23)

> Ok, at this point, I guess that what would help would be to try to take our
> backport driver and put lots of prints in the probe function to see where we
> get stuck.
> Would it be something doable on your side? (I'd provide the code to compile
> of course).

I'm somewhat busy these days, but I know how to do that. I'll do it later this week or maybe the next, if nobody else does it quicker.

I also installed the latest firmware without any difference, as far as I could tell. For me, the bug occurs exactly when I've shut down the computer in Windows and next boot into Linux. If I use Windows and reboot instead of shutting down, it works. Booting into Linux and either shutting down or rebooting fixes it. Even rebooting straight from rEFInd, without booting any system, fixes it.

(In reply to Emmanuel Grumbach from comment #23)
> Ok, at this point, I guess that what would help would be to try to take our
> backport driver and put lots of prints in the probe function to see where we
> get stuck.
> Would it be something doable on your side? (I'd provide the code to compile
> of course).

That should be doable for me. Also, it's always great to learn something new.
I should have enough time at my hands next week, if that fits your schedule.

Please take the debug_201319 branch of:

git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/backport-iwlwifi.git

I added debug prints.

Please compile with IWLWIFI_DEBUG enabled and load iwlwifi with:
debug=0xffffffff

Thanks.

Created attachment 281471 [details]
Debug outputs, with and without bug

I rmmod'ed iwlmvm and iwlwifi, which had been autoloaded at boot, and modprobe'd them back with debug enabled. First I did that with the wireless card working, then with the bug. After that, I grepped "iwlwifi" from my debug log. As you can see, the bug made the module fail almost immediately, with only four output lines.

Please let me know if you wish me to do any further testing.

Problem is that the prints I added didn't include iwlwifi :)
Can you please send the logs w/o grepping iwlwifi?

Created attachment 281473 [details]
Corrected debug output

Sorry, I'd accidentally checked out the main branch, so the extra debug outputs weren't there in the first place. Here's the relevant snippet from dmesg after installing the debug_201319 version.

I pushed another patch in the same branch.

can you produce the same logs with the new content there?
Thanks.

Created attachment 281475 [details]
Debug output again

Snippet of dmesg output, with latest version

Pushed again, but I don't think it'll help.
Still worth trying.

You have updated the BT firmware as mentioned in comment #20, right?

I just noticed that the BT patches were updated:

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=55fa1fbae78512c305153aeb66ef5cd948ea3709
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=30b931413997178cab3163c1cf15f54c59c486c9

Please take those.
Note that you need a cold boot for the BT to take the new FW.

Yes, I had updated the firmware. Updating it again and compiling the latest version of the driver ("read after write") didn't make any visible difference.

Created attachment 281477 [details]
debug-output_2019-03-03-16-00-CET.txt

I compiled your branch and installed the latest patches for BT.

Here is the output of dmesg | grep iwl it yielded.

If you need any other output, let me know.

Thanks.
Your two logs are exactly identical.

I need to get more info internally.

As a side note: I just found out why for all others rebooting into Linux helps but not for me. It seems that I need to completely unplug the computer. When I then reboot into Linux the problem is fixed.

This might not be crucial information, but I wanted to share it nevertheless if it maybe helps in fixing the bug.

Ping? Is there any progress on this issue?

Unfortunately no.

This is constantly bypassed by higher priority tasks.

(In reply to Emmanuel Grumbach from comment #39)
> Unfortunately no.
> 
> This is constantly bypassed by higher priority tasks.

That's understandable, thanks for the update.

For the record, I am experiencing the same issue.

I have a dual-boot machine, Debian Stretch and Windows 10.

I installed a new Intel 9260 card, and booted into Debian first running the kernel (4.19.0-0.bpo.4-amd64) & firmware (20190114-1~bpo9+2) from stretch-backports. The card worked fine, through multiple reboots.

I then booted into Windows, updated Intel's drivers, and it worked there too. I powered down the machine for the night.

Booting into Linux after that resulted in the -110 timeout behavior, which wouldn't resolve across either hard or soft reboots, nor with manually removing/re-adding the kernel module a few times.

Booting into Windows, then soft-rebooting into Linux led to a working card.

Happy to help with testing in the future whenever someone has time to work on this - no rush, just happy to see that it's had some attention so far.

After you boot into Linux with a working device, can you shut down the machine. Power it up again in Linux and get a working device again?

Only booting to windows makes the problem appear?

Fwiw, this is the exact opposite of what I'd expect. There is some state that stays alive across reboots. So I'd expect that once you boot from fresh (as opposed to reboot) things would fall in place. But what you described is the exact opposite.

> After you boot into Linux with a working device, can you shut down the
> machine. Power it up again in Linux and get a working device again?

Yes, I just powered it off now and back on again, the device works without issue:

$ dmesg | grep iwlwifi

[    4.789382] iwlwifi 0000:27:00.0: enabling device (0000 -> 0002)
[    4.797452] iwlwifi 0000:27:00.0: firmware: direct-loading firmware iwlwifi-9260-th-b0-jf-b0-38.ucode
[    4.798053] iwlwifi 0000:27:00.0: loaded firmware version 38.755cfdd8.0 op_mode iwlmvm
[    4.846147] iwlwifi 0000:27:00.0: Detected Intel(R) Dual Band Wireless AC 9260, REV=0x324
[    4.896223] iwlwifi 0000:27:00.0: base HW address: a4:c3:f0:88:bb:e8
[    4.971072] iwlwifi 0000:27:00.0 wlp39s0: renamed from wlan0

I'll run a few more tests tonight and write them up for you.

For me, the bug shows up exactly when the last thing I did before starting up Linux was to shut down Windows. A warm reboot from Windows, Linux, or even straight from the bootloader clears the bug, and so does shutting down from Linux and cold booting. As long as I don't touch Windows (which is most of the time), the bug never comes back.

Created attachment 282805 [details]
print fseq version

Can you please all use the patch attached and tell me what the print there say?

I need the TLV_FW_FSEQ_VERSION: output.

Thank you.

The patched version didn't compile. IWL_UCODE_TLV_FW_FSEQ_VERSION was undefined.

Hmmm... it define in my code. Apparently, we have different version of the code.

Please add:

       IWL_UCODE_TLV_FW_FSEQ_VERSION   = 60

in  enum iwl_ucode_tlv_type {
which is in drivers/net/wireless/intel/iwlwifi/fw/file.h

Thanks.

I compiled the latest rev of the backport-iwlwifi driver (ac5faf65ba515d3f7ac4ca29de59dce5baf3f85f) with your patch to print the fseq version. I also installed the latest firmware, iwlwifi-9260-th-b0-jf-b0-46.ucode.

Unfortunately, loading the module doesn't seem to print the line we're looking for:

[ 1958.208284] iwlwifi 0000:27:00.0: U _iwl_disable_interrupts Disabled interrupts
[ 1958.208288] iwlwifi 0000:27:00.0: U iwl_pcie_prepare_card_hw iwl_trans_prepare_card_hw enter
[ 1958.208296] iwlwifi 0000:27:00.0: U iwl_pcie_set_hw_ready hardware ready
[ 1958.208321] iwlwifi 0000:27:00.0: U iwl_trans_pcie_alloc HW REV: 0x324
[ 1958.208569] iwlwifi 0000:27:00.0: U iwl_pcie_set_interrupt_capa MSI-X enabled. 16 interrupt vectors were allocated
[ 1958.209368] iwlwifi 0000:27:00.0: firmware: failed to load iwl-dbg-cfg.ini (-2)
[ 1958.209371] iwlwifi 0000:27:00.0: Direct firmware load for iwl-dbg-cfg.ini failed with error -2
[ 1958.209376] iwlwifi 0000:27:00.0: U iwl_request_firmware attempting to load firmware 'iwlwifi-9260-th-b0-jf-b0-46.ucode'
[ 1958.209702] iwlwifi 0000:27:00.0: firmware: direct-loading firmware iwlwifi-9260-th-b0-jf-b0-46.ucode
[ 1958.209705] iwlwifi 0000:27:00.0: U iwl_req_fw_callback Loaded firmware file 'iwlwifi-9260-th-b0-jf-b0-46.ucode' (1456088 bytes).
[ 1958.209708] iwlwifi 0000:27:00.0: U iwl_parse_tlv_firmware Found debug memory segment: 0
[ 1958.209710] iwlwifi 0000:27:00.0: U iwl_parse_tlv_firmware Found debug memory segment: 1
[ 1958.209711] iwlwifi 0000:27:00.0: U iwl_parse_tlv_firmware Found debug memory segment: 2
[ 1958.209713] iwlwifi 0000:27:00.0: U iwl_parse_tlv_firmware Found debug memory segment: 0
[ 1958.209714] iwlwifi 0000:27:00.0: U iwl_parse_tlv_firmware Found debug memory segment: 1
[ 1958.209714] iwlwifi 0000:27:00.0: U iwl_parse_tlv_firmware Found debug memory segment: 2
[ 1958.209716] iwlwifi 0000:27:00.0: U iwl_parse_tlv_firmware unknown TLV: 58
[ 1958.209718] iwlwifi 0000:27:00.0: U iwl_parse_tlv_firmware Paging: paging enabled (size = 241664 bytes)
[ 1958.209719] iwlwifi 0000:27:00.0: U iwl_parse_tlv_firmware unknown TLV: 58

Maybe I've missed something here?

I have exactly the same problem (error -110) with an Intel(R) Wi-Fi 6 AX200 160MHz, REV=0x340 both on 5.2.11 and 5.3.0-rc6

The problem for me only happens when powering off windows, then power on and boot into linux. A reboot from windows clears the problem, and after it's working it doesn't happen again unless powering off windows. Rebooting linux, powering off linux etc does not help if the problem has occured, and does not cause it.

I think windoows driver does something when powering off the machine which linux driver can't undo.

Here is the log with TLV_FW_FSEQ_VERSION when it is working:

[    2.587563] iwlwifi 0000:03:00.0: enabling device (0000 -> 0002)
[    2.592047] iwlwifi 0000:03:00.0: TLV_FW_FSEQ_VERSION: FSEQ Version: 43.2.23.17
[    2.592049] iwlwifi 0000:03:00.0: Found debug destination: EXTERNAL_DRAM
[    2.592050] iwlwifi 0000:03:00.0: Found debug configuration: 0
[    2.592177] iwlwifi 0000:03:00.0: loaded firmware version 48.954cff6d.0 op_mode iwlmvm
[    2.992221] iwlmvm: unknown parameter 'power_save' ignored
[    2.992300] iwlwifi 0000:03:00.0: Detected Intel(R) Wi-Fi 6 AX200 160MHz, REV=0x340
[    3.002880] iwlwifi 0000:03:00.0: Applying debug destination EXTERNAL_DRAM
[    3.003027] iwlwifi 0000:03:00.0: Allocated 0x00400000 bytes for firmware monitor.
[    3.159180] iwlwifi 0000:03:00.0: base HW address: 3c:f0:11:d9:cc:13
[    3.173805] iwlwifi 0000:03:00.0 wlp3s0: renamed from wlan0
[   22.181142] iwlwifi 0000:03:00.0: Applying debug destination EXTERNAL_DRAM
[   22.331987] iwlwifi 0000:03:00.0: FW already configured (0) - re-configuring
[   22.341352] iwlwifi 0000:03:00.0: BIOS contains WGDS but no WRDS
[   25.756449] wlp3s0: authenticate with 7c:8b:ca:59:05:8c
[   25.758586] wlp3s0: send auth to 7c:8b:ca:59:05:8c (try 1/3)
[   25.782952] wlp3s0: authenticated
[   25.784190] wlp3s0: associate with 7c:8b:ca:59:05:8c (try 1/3)
[   25.797300] wlp3s0: RX AssocResp from 7c:8b:ca:59:05:8c (capab=0x431 status=0 aid=9)
[   25.800772] wlp3s0: associated

Booting into windows and turning wifi off solved the issue for me

This is probably due to "fast boot" on Windows.  Can you try to follow these instructions from our wiki and see if it solves the problem?

https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi#about_dual-boot_with_windows_and_fast-boot_enabled

Additionally, you should make sure that the Bluetooth firmwares are also up-to-date.

Confirm that disabling "fast boot" on Windows solve the problem for me.

Thanks.

with the more recent iwlwifi drivers i noticed after a while of troubleshooting that the LAR (Location Aware Regulatory) "feature" of the iwlwifi drivers were incorrectly detecting wireless regulatory domain info or rather that it detects the correct one and it also disables most of the channels with another. 

disabling lar fixes the dropped or no-connection issue

iwlwifi.lar_disable=1

(In reply to dglt from comment #53)
> with the more recent iwlwifi drivers i noticed after a while of
> troubleshooting that the LAR (Location Aware Regulatory) "feature" of the
> iwlwifi drivers were incorrectly detecting wireless regulatory domain info
> or rather that it detects the correct one and it also disables most of the
> channels with another. 
> 
> disabling lar fixes the dropped or no-connection issue
> 
> iwlwifi.lar_disable=1

LAR is used to detect the current location and handle the regulatory accordingly.  But it's not related to this bug and, in any case, you're not supposed to disable lar, this option was there just for initial testing and will be removed.

I'm going to close this bug now, since people have been reporting that disabling fastboot on Windows has solved the problem for them.  And this bug has so many comments from different things that it is hard to track.

Please open a new bug if you still have problems.  Especially the original author of this bug entry.

In case someone's still interested in this, I found out that initiating a PCI reset of the device allowed to properly initialize it (and load the iwlwifi module) when coming from a Windows hibernation or Fast Startup state (-110 error).

This seems to be working fine, with no visible side-effect, either on the Linux or Windows side (tested on kernel 5.8.1):

$ cat /etc/modprobe.d/iwlwifi.conf
# PCIe reset device before loading the module.
#   Windows Hibernation/FastBoot may leave it in an unusable state
#   Replace 0000:00:14.3 below by the actual PCI address of the device
install iwlwifi echo 1 > /sys/bus/pci/devices/0000\:00\:14.3/reset ; \
        /sbin/modprobe --ignore-install iwlwifi

Hope this helps.