Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#64703 - [linux] Wifi device missing in 5.4, 5.4.1 on Dell XPS 13 2-in-1

Attached to Project: Arch Linux
Opened by Nico Schottelius (telmich) - Monday, 02 December 2019, 11:17 GMT
Last edited by Jan Alexander Steffens (heftig) - Friday, 27 December 2019, 20:41 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Jan Alexander Steffens (heftig)
Laurent Carlier (lordheavy)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 30
Private No

Details

Description:

In 5.3.13 wifi works fine, in 5.4 and 5.4.1 the kernel has trouble initialising the wifi device.

Will add dmesg as soon as I have restored network connectivity on the device

Additional info:
* package version(s)
* config and/or log files etc.
* link to upstream bug report, if any

Steps to reproduce:

Upgrade to Linux 5.4.0 or 5.4.1
This task depends upon

Closed by  Jan Alexander Steffens (heftig)
Friday, 27 December 2019, 20:41 GMT
Reason for closing:  Fixed
Additional comments about closing:  linux 5.4.6.arch3-1
Comment by Nico Schottelius (telmich) - Monday, 02 December 2019, 11:21 GMT
Note: if I type "ip link", with 5.4.x there is no wifi device at all. While with 5.3.13 it looks like this:

```
[root@diamond ~]# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
link/ether 24:ee:9a:54:c3:bf brd ff:ff:ff:ff:ff:ff
```
Comment by loqs (loqs) - Monday, 02 December 2019, 20:31 GMT
You have not included details of what the WIFI device is, what kernel driver it used in 5.3.13
or what the state of that driver is in 5.14.
lspci -nnk for a PCI device, lsusb for a USB device, dmesg output.
I would suggest asking for help on the forums, IRC, mailing list or other support channels.
Comment by Nico Schottelius (telmich) - Monday, 02 December 2019, 20:50 GMT
It's this device:

00:14.3 Network controller [0280]: Intel Corporation Killer Wi-Fi 6 AX1650i 160MHz Wireless Network Adapter (201NGW) [8086:34f0] (rev 30)
Subsystem: Bigfoot Networks, Inc. Killer Wi-Fi 6 AX1650i 160MHz Wireless Network Adapter (201NGW) [1a56:1651]
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi

In both cases (can be seen in the dmesg) iwlwifi is being used.

[root@diamond ~]# lsmod | grep iwl
iwlmvm 471040 0
mac80211 999424 1 iwlmvm
iwlwifi 393216 1 iwlmvm
cfg80211 856064 3 iwlmvm,iwlwifi,mac80211
Comment by loqs (loqs) - Monday, 02 December 2019, 21:17 GMT
Please include the dmesg from both a 5.4.Y and 5.3.Y boot
Comment by Jan Alexander Steffens (heftig) - Tuesday, 03 December 2019, 08:34 GMT
This needs either new firmware or a fix to the drivers for the old firmware. Unfortunately, there's been no release of linux-firmware last month and the new firmware only appeared in Chrome OS.
Comment by Jan Alexander Steffens (heftig) - Tuesday, 03 December 2019, 09:34 GMT
Should be fixed in linux-firmware 20191118.e8a0f4c-1 in [testing]. Please test.
Comment by zzzardoz (zzzardoz) - Tuesday, 03 December 2019, 11:45 GMT
Unfortunately linux-firmware 20191118.e8a0f4c-1 doesn't fix this issue...
Comment by Nico Schottelius (telmich) - Tuesday, 03 December 2019, 11:59 GMT
Attached is the dmesg of the working kernel
Comment by Mehmet Akif TASOVA (makiftasova) - Tuesday, 03 December 2019, 12:48 GMT
I have similar issues with Intel Dual Band Wireless AC 9462 ( "00:14.3 Network controller: Intel Corporation Cannon Point-LP CNVi [Wireless-AC] (rev 30)" as in lspci output) on Dell Vostro 5481 laptop.

so far my results are:
linux-5.4.1-arch1-1 + linux-firmware-20191022.2b016af-3 : NO WIFI
linux-5.4.1-arch1-1 + linux-firmware-20191118.e8a0f4c-1 : NO WIFI
linux-5.3.13-arch1-1 + linux-firmware-20191022.2b016af-3 : OK
linux-5.3.13-arch1-1 + linux-firmware-20191118.e8a0f4c-1 : OK

I'm also attaching dmesg output on Linux 5.4.1-arch1-1. It produces similar output with both linux-firmware packages.
Also I have attached output of "sudo lspci -vv" on both Linux 5.4.1 and 5.3.13

Comment by loqs (loqs) - Tuesday, 03 December 2019, 13:05 GMT Comment by loqs (loqs) - Tuesday, 03 December 2019, 23:52 GMT
Patch to the PKGBUILD applies revert from 204873 could those affected please test?
Comment by Jan Alexander Steffens (heftig) - Wednesday, 04 December 2019, 08:14 GMT
Do any of you have the AX1650i this bug is about? That's what the firmware fix is for.
Comment by Nico Schottelius (telmich) - Wednesday, 04 December 2019, 09:00 GMT
I'm actually on it:

00:14.3 Network controller: Intel Corporation Killer Wi-Fi 6 AX1650i 160MHz Wireless Network Adapter (201NGW) (rev 30)
Comment by Mario O. M. (marioortizmanero) - Wednesday, 04 December 2019, 16:47 GMT
Same issue and laptop as Mehmet Akif. When I was using the 5.3.13-arch1-1 kernel the wifi interface only showed up sometimes so it's not like it worked perfectly. I had to reboot and it would start working again (if I was lucky). Anyone else?
Now that I've updated to 5.4.1.arch1-1, it doesn't even work at all. I'm attaching some logs too.


Note for Doug Newgard (Scimmia): sorry for reposting the issue. At first I posted it by mistake and I thought you had removed it because of that. But it was because the issue was duplicated. Sorry.
Comment by Waan (waan) - Wednesday, 04 December 2019, 16:54 GMT
On Lenovo l340 gaming pro 15, when using:
core/linux 5.4.1.arch1-1 [installed] -> on boot the wireless wlp0s20f3 interface is down, when the interface should automatically turn up on boot.
When manually # ip link set wlp0s20f3 up -> returns "rtnetlink answers input/output error"
And the wireless interface will not turn on.
linux-firmware 20191022.2b016af-3 is installed.

This issue started after upgrading to inux 5.4.1.arch1-1
Using linux-lts 4.19.87-1 makes wireless work again.
Comment by Mehmet Akif TASOVA (makiftasova) - Wednesday, 04 December 2019, 17:52 GMT
@loqs I've build kernel 5.4.1 myself with PKGBUILD.diff applied. (using Arch sources via `asp` ) and it seems it does not fix my issue.

I am starting to believe there are two different issues with Intel WiFi drivers of kernel 5.4.1.

I am going to attach new dmesg logs but they looked identical to me when compared to the old ones.

"new_fw" logs are generated when linux-firmware 20191118.e8a0f4c-1 is installed from testing repo. Other file is with everything from stable repos (except custom built kernel)
Comment by acidicX (acidicX) - Thursday, 05 December 2019, 13:43 GMT
I'm having the same issue. My card is:

00:14.3 Network controller: Intel Corporation Wireless-AC 9462 (but it's actually a 9560)

linux 5.3.13 => works
linux 5.4.1 => does not work
linux-lts => does not work (never tested it before encountering the bug though)

tested with linux-firmware 20191022.2b016af-3

I also noticed that the package `linux-api-headers` is still on 5.3, while `linux-headers` is on par with the current kernel version. I don't know if that has any implications or in how those are related.

Compared to @marioortizmanero my card worked perfectly with 5.3, I've never had any issues before.

Please note that WiFi not working these days basically renders a laptop to be a shiny paperweight, so I really question why this has severity "low".
Comment by zzzardoz (zzzardoz) - Thursday, 05 December 2019, 19:28 GMT
FYI: With linux 5.4.2.arch1-1 from Testing the issue persists...
Comment by loqs (loqs) - Thursday, 05 December 2019, 20:46 GMT
@acidicX is there an upstream bug report for your issue?
Comment by fahad (johnjacobjingle) - Thursday, 05 December 2019, 23:26 GMT
Same issue:

Laptop: Lenovo X1 Carbon 7th gen -
WiFi Card: 9560

Kernels that work : 5.3.8
Kernels that don't work : 5.4.1 & 5.4.2 & LTS


Comment by hexchain (hexchain) - Thursday, 05 December 2019, 23:38 GMT
Looks very much like the bug I reported here: https://bugzilla.kernel.org/show_bug.cgi?id=205695

I'm using a 9260AC card, and interestingly I only seem to have such a problem with iwlwifi.lar_disabled=1.
Comment by acidicX (acidicX) - Friday, 06 December 2019, 09:28 GMT
@loqs I suppose this one is related:
https://bugzilla.kernel.org/show_bug.cgi?id=205749
But it has less info than this thread here.

@hexchain I don't have this flag set, so does not seem to be related, at least with my 9560 card.

I'll try to post a dmesg from the latest kernel and LTS today.
Comment by Constantine (Hi-Angel) - Friday, 06 December 2019, 09:36 GMT
Offtop: folks, please, when you report a regressed functional, consider adding a [REGRESSION] word in the title. Regressions has more subjective priority for developers, because often they're more easily fixable compared to some abstract functional that has never worked. And even more so when the report has also been "[BISECTED]".
Comment by hexchain (hexchain) - Friday, 06 December 2019, 11:56 GMT
@acidcX: The call traces in those dmesg outputs are pretty much the same (except for some lines marked with a question mark), and that's why I think they are similar.
Comment by acidicX (acidicX) - Friday, 06 December 2019, 19:07 GMT
Hm, I just noticed it is a bit weirder than I thought.
lspci seems to display the wrong card. I remember speccing the machine with a 9560.

lspci:
00:14.3 Network controller: Intel Corporation Wireless-AC 9462
00:14.3 0280: 8086:02f0 (PCI ID)

iwlwifi however:
[ 46.839888] iwlwifi 0000:00:14.3: Detected Intel(R) Wireless-AC 9560
160MHz, REV=0x354

I'm not sure which is correct, probably the latter, I'll try to open the machine to know it for sure.
Maybe the bug has something to do with lspci detecting the wrong card? But I guess iwlwifi runs it's own detection, so as long as the correct module (iwlwifi) is loaded it should not matter, right?

Anyway, I added the logs for 5.3, 5.4 and LTS.
Comment by Mehmet Akif TASOVA (makiftasova) - Saturday, 07 December 2019, 09:49 GMT
Not sure if there is any patches for iwlwifi is included in 5.4.2 but it seems issue still persists.

adding kernel logs from 5.4.2.arch1-1
Comment by Mehmet Akif TASOVA (makiftasova) - Friday, 13 December 2019, 20:45 GMT
I have spent some time to bisect the issue today and I think I found the commit which introduced the bug, which is commit 06eb547c4ae4 ("iwlwifi: mvm: fix scan config command size")

Applying the patch I attached seems to fix this issue in my case (WiFi chip: Intel(R) Dual Band Wireless AC 9462, PC: Dell Vostro 5481), and yes, this patch simply reverts the commit which made in Jun 2, 2019.

And it seems this issue still exists in 5.5.0-rc1
Comment by Constantine (Hi-Angel) - Friday, 13 December 2019, 20:56 GMT
Amazing! If there's an upstream report opened for this, you probably want to add to CC the author of the commit that introduced regression.
Comment by Mehmet Akif TASOVA (makiftasova) - Friday, 13 December 2019, 21:00 GMT
already sent same patch to related maintainers via e-mail.

I tried to open Linux kernel bugzilla links above, but somehow my browser rejects to open bugzilla.kernel.org URLs thus I cannot access upstream bug reports
Comment by Marcel Fest (cellebyte) - Tuesday, 17 December 2019, 21:12 GMT
My Wifi also crashes all the time.
I think the kernel is causing the crash.
because the firmware between 20191118 and 20190923 is the same iwlwifi

loaded firmware version 46.6bf1df06.0 op_mode iwlmvm
Loaded firmware version: 46.6bf1df06.0

something with the op_mode is not working.

Non working:
* kernel version: linux-5.4.3.arch1-1-x86_64.pkg.tar.xz
* linux-firmware: linux-firmware-20191118.e8a0f4c-2-any.pkg.tar.xz

working:
* kernel version: linux-5.3.1.arch1-1-x86_64.pkg.tar.xz
* linux-firmware: linux-firmware-20190923.417a9c6-1-any.pkg.tar.xz
Comment by Diego Novaes (dnovaes) - Thursday, 19 December 2019, 02:01 GMT
I'm can't use wifi either. iwlwifi driver too.
Started happening after updating kernel to 5.4 and linux-firmware 20191215.eefb5f7-1. The current version of the kernel in the uploaded journalctl is 5.4.3

Does anyone knows any work-arround to make wifi works? Any help is appreciated.

00:14.3 Network controller: Intel Corporation Cannon Point-LP CNVi [Wireless-AC] (rev 30)
Comment by Strubbl (strubbl) - Thursday, 19 December 2019, 15:06 GMT
I can confirm the wifi device Intel wireless-ac 9462 does not even get detected with "ip l". I am using linux 5.4.5-arch1-1 and linux-firmware 20191215.eefb5f7-1.
Comment by zzzardoz (zzzardoz) - Thursday, 19 December 2019, 16:41 GMT
@makiftasova: Did you get any response from the kernel devs?
Comment by loqs (loqs) - Thursday, 19 December 2019, 17:04 GMT
@zzzardoz see https://lore.kernel.org/linux-wireless/20191213203512.8250-1-makiftasova%40gmail.com/

https://bugzilla.kernel.org/show_bug.cgi?id=205695 has been marked fixed with the cause being use of the option lar_disable=1 .
https://bugzilla.kernel.org/show_bug.cgi?id=205749 has not received a response yet.
Perhaps others could try the patch or add more of the information suggested from [1] to 205749 .

[1] https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging

Edit: linuxwifi@intel.com was not added to 205749 which may explain why there has been no developer response.
Comment by zzzardoz (zzzardoz) - Friday, 20 December 2019, 11:43 GMT
Thanks for all the information and your efforts @makiftasova! I've built the kernel with your patch tonight, and it seems that it solves the issue at least for one notebook of mine. I will test on my other machines and report tomorrow.
Comment by loqs (loqs) - Sunday, 22 December 2019, 16:27 GMT
@zzzardoz what wireless device did the patch work for?
Comment by loqs (loqs) - Monday, 23 December 2019, 14:54 GMT Comment by zzzardoz (zzzardoz) - Monday, 23 December 2019, 20:10 GMT
Done testing on my 3 machines. All are working fine with @makiftasova's patch.

1) 3a:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78)

2) 00:0c.0 Network controller: Intel Corporation Device 31dc (rev 03)
-> Intel(R) Dual Band Wireless AC 9462, REV=0x318

3) 00:0c.0 Network controller: Intel Corporation Device 31dc (rev 03)
-> Intel(R) Dual Band Wireless AC 9560, REV=0x318

I'm in favor of including the patch until it's merged upstream, as many of us are affected.
Comment by Jan Alexander Steffens (heftig) - Tuesday, 24 December 2019, 05:41 GMT
This should be fixed by linux 5.4.6.arch3-1 and linux-firmware 20191220.6871bff-1 in [testing].
Comment by Johnny (Shoppinguin) - Tuesday, 24 December 2019, 10:23 GMT
Could this be related to the issue i have on my Asus E203MA with the Intel Dual Band Wireless AC 9461, REV=0x318?
If it is i don't consider this fixed.
I'm running kernel version 5.4.6-arch1-1 and linux-firmware 20190618.acb56f2-1(also tried other versions including 20191215.eefb5f7-1 without any change)
dmesg output is attached
   dmesg (10.3 KiB)
Comment by David Loiseaux (DavidLapous) - Tuesday, 24 December 2019, 14:53 GMT
I still have this issue with linux 5.4.6.arch3-1 and linux-firmware 20191220.6871bff-1.(installed via "downgrade")
With lspci displaying
00:14.3 Network controller: Intel Corporation Wireless-AC 9560 [Jefferson Peak] (rev 10)
and dmesg diplaying
[ 78.502330] iwlwifi 0000:00:14.3: Detected Intel(R) Dual Band Wireless AC 9462, REV=0x318
dmesg attached
   dmesg.txt (93.1 KiB)
Comment by Jan Alexander Steffens (heftig) - Tuesday, 24 December 2019, 17:59 GMT
You're getting NMI_INTERRUPT_UMAC_FATAL, which is not this bug. This bug is about the AX1650i in the Dell XPS 2-in-1 7390.
Comment by acidicX (acidicX) - Wednesday, 25 December 2019, 13:29 GMT
WiFi seems to be working again with linux 5.4.6.arch3-1 and linux-firmware 20191220.6871bff-1, although I just had a crash (system hangup).

> kernel: GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.

Probably unrelated, but I never had the issue before.
Comment by Johnny (Shoppinguin) - Wednesday, 25 December 2019, 15:28 GMT
i can confirm that linux-firmware is not the only issue here. I installed the lts kernel, which is currently 4.19 and this brought my wifi back to life.
It does not even matter which version of linux-firmware i install, it appears to work anyhow.
Comment by Jan Alexander Steffens (heftig) - Wednesday, 25 December 2019, 20:23 GMT
Can I get some confirmations that the XPS 2-in-1 7390 works now?
Comment by Nico Schottelius (telmich) - Wednesday, 25 December 2019, 21:56 GMT
@heftig I'll check latest tomorrow
Comment by Nico Schottelius (telmich) - Wednesday, 25 December 2019, 22:25 GMT
I can confirm, it works again!

[23:25] diamond:~% uname -a
Linux diamond 5.4.6-arch3-1 #1 SMP PREEMPT Tue, 24 Dec 2019 04:36:53 +0000 x86_64 GNU/Linux
[23:25] diamond:~% ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
link/ether 24:ee:9a:54:c3:bf brd ff:ff:ff:ff:ff:ff
[23:25] diamond:~%
Comment by Victor Trac (victortrac) - Thursday, 26 December 2019, 03:12 GMT
Confirmed wifi works again on my X1 Carbon 7th Gen. Although, dmesg and iwlwifi report different wifi chips:

$ lspci | grep Network
00:14.3 Network controller: Intel Corporation Wireless-AC 9462

$ dmesg | grep iwlwifi
[ 14.629386] iwlwifi 0000:00:14.3: enabling device (0000 -> 0002)
[ 14.685368] iwlwifi 0000:00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: 58.3.35.22
[ 14.685584] iwlwifi 0000:00:14.3: loaded firmware version 50.3e391d3e.0 op_mode iwlmvm
[ 14.926950] iwlwifi 0000:00:14.3: Detected Intel(R) Wireless-AC 9560 160MHz, REV=0x354
[ 15.080512] iwlwifi 0000:00:14.3: base HW address: 04:ed:33:8e:43:5b
[ 16.046789] iwlwifi 0000:00:14.3: Conflict between TLV & NVM regarding enabling LAR (TLV = enabled NVM =disabled)
[ 16.212333] iwlwifi 0000:00:14.3: Conflict between TLV & NVM regarding enabling LAR (TLV = enabled NVM =disabled)
Comment by kyuz0 (kyuz0) - Friday, 27 December 2019, 10:21 GMT
I've been having issues with this for months (on HP Elite book), even the last update does not deliver a stable wifi experience:

$ uname -a
Linux kiba-reborn 5.4.6-arch3-1 #1 SMP PREEMPT Tue, 24 Dec 2019 04:36:53 +0000 x86_64 GNU/Linux

$ lspci
02:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)

$ dmesg
[ 67.114288] iwlwifi 0000:02:00.0: enabling device (0000 -> 0002)
[ 67.114462] iwlwifi 0000:02:00.0: HW_REV=0xFFFFFFFF, PCI issues?
[ 67.134554] iwlwifi: probe of 0000:02:00.0 failed with error -5


66.994374] wlp2s0: Failed check-sdata-in-driver check, flags: 0x4
[ 66.994417] WARNING: CPU: 3 PID: 157 at net/mac80211/driver-ops.h:17 drv_remove_interface+0x121/0x130 [mac80211]
[ 66.994418] Modules linked in: fuse ccm joydev mousedev intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel snd_hda_codec_hdmi iTCO_wdt mei_hdcp mei_wdt iTCO_vendor_support snd_hda_codec_conexant snd_hda_codec_generic hp_wmi kvm sparse_keymap ledtrig_audio wmi_bmof intel_wmi_thunderbolt iwlmvm snd_hda_intel snd_intel_nhlt mac80211 snd_hda_codec uvcvideo snd_hda_core snd_hwdep btusb libarc4 videobuf2_vmalloc btrtl videobuf2_memops snd_pcm irqbypass btbcm nls_iso8859_1 iwlwifi btintel intel_cstate nls_cp437 videobuf2_v4l2 i915 intel_uncore snd_timer vfat intel_rapl_perf fat videobuf2_common snd pcspkr bluetooth e1000e psmouse videodev cfg80211 input_leds rtsx_pci_ms soundcore i2c_i801 ecdh_generic mei_me memstick mc rfkill intel_lpss_pci ecc mei i2c_algo_bit intel_lpss intel_xhci_usb_role_switch tpm_infineon intel_pch_thermal roles idma64 intel_gtt wmi battery nf_log_ipv6 tpm_tis ip6t_REJECT nf_reject_ipv6 tpm_tis_core evdev tpm hp_accel xt_hl mac_hid
[ 66.994455] lis3lv02d hp_wireless ac rng_core input_polldev ip6t_rt nf_log_ipv4 nf_log_common ipt_REJECT nf_reject_ipv4 xt_LOG xt_limit xt_addrtype xt_tcpudp xt_conntrack ip6table_filter ip6_tables nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_filter vboxnetflt(OE) vboxnetadp(OE) vboxdrv(OE) vboxvideo drm_vram_helper ttm drm_kms_helper drm agpgart syscopyarea sysfillrect sysimgblt fb_sys_fops vboxsf(OE) vboxguest loop sg crypto_user ip_tables x_tables sd_mod crct10dif_pclmul crc32_pclmul ghash_clmulni_intel rtsx_pci_sdmmc mmc_core serio_raw atkbd libps2 aesni_intel crypto_simd cryptd ahci glue_helper libahci rtsx_pci libata xhci_pci scsi_mod xhci_hcd i8042 serio ext4 crc32c_generic crc32c_intel crc16 mbcache jbd2 dm_crypt dm_mod
[ 66.994491] CPU: 3 PID: 157 Comm: kworker/3:2 Tainted: G W OE 5.4.6-arch3-1 #1
[ 66.994492] Hardware name: HP HP EliteBook 840 G3/8079, BIOS N75 Ver. 01.16 06/08/2017
[ 66.994513] Workqueue: events_freezable ieee80211_restart_work [mac80211]
[ 66.994533] RIP: 0010:drv_remove_interface+0x121/0x130 [mac80211]
[ 66.994536] Code: 25 23 23 e4 e9 49 ff ff ff 48 8b 86 78 04 00 00 48 8d b6 98 04 00 00 48 c7 c7 00 0d 25 c1 48 85 c0 48 0f 45 f0 e8 fd de 2b e4 <0f> 0b 5b 5d 41 5c c3 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 57
[ 66.994537] RSP: 0000:ffffa29d40243c78 EFLAGS: 00010286
[ 66.994538] RAX: 0000000000000000 RBX: ffff89f7da2948c0 RCX: 0000000000000000
[ 66.994539] RDX: 0000000000000001 RSI: 0000000000000086 RDI: 00000000ffffffff
[ 66.994541] RBP: ffff89f7d31498c8 R08: 00000000000009b3 R09: 0000000000000001
[ 66.994542] R10: 0000000000000000 R11: 0000000000000001 R12: ffff89f7d31487a0
[ 66.994543] R13: ffff89f7d3148f98 R14: ffff89f7d3148c38 R15: ffff89f7da295450
[ 66.994544] FS: 0000000000000000(0000) GS:ffff89f7e1380000(0000) knlGS:0000000000000000
[ 66.994545] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 66.994546] CR2: 00005651ae2a4670 CR3: 00000003e07a8006 CR4: 00000000003606e0
[ 66.994547] Call Trace:
[ 66.994573] ieee80211_do_stop+0x5b2/0x890 [mac80211]
[ 66.994597] ieee80211_stop+0x16/0x20 [mac80211]
[ 66.994600] __dev_close_many+0xad/0x120
[ 66.994603] dev_close_many+0x9e/0x150
[ 66.994605] dev_close+0x73/0x90
[ 66.994627] cfg80211_shutdown_all_interfaces+0x71/0xd0 [cfg80211]
[ 66.994652] ieee80211_reconfig+0xa2/0x1680 [mac80211]
[ 66.994673] ieee80211_restart_work+0xb7/0xe0 [mac80211]
[ 66.994677] process_one_work+0x1e2/0x3b0
[ 66.994680] worker_thread+0x4a/0x3d0
[ 66.994683] kthread+0xfb/0x130
[ 66.994685] ? process_one_work+0x3b0/0x3b0
[ 66.994686] ? kthread_park+0x90/0x90
[ 66.994689] ret_from_fork+0x35/0x40
[ 66.994692] ---[ end trace 04324f39a834c3be ]---
[ 66.994709] ------------[ cut here ]------------

Comment by loqs (loqs) - Friday, 27 December 2019, 14:10 GMT
@kyuz0 if you have been having the isue for months it could not be an issue introduced with linux 5.4 and the backtrace you posted does not match those for the issues in this thread.
https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging
Comment by Cassio Batista (cassota) - Friday, 27 December 2019, 15:49 GMT
5.4.6.arch3-1 + 20191220.6871bff-1 does not work on my Dell Inspiron 5480 either.

My wireless card is seen as follows:
* lspci: 00:14.3 Network controller [0280]: Intel Corporation Cannon Point-LP CNVi [Wireless-AC] [8086:9df0] (rev 30)
* dmesg: [ 48.747492] iwlwifi 0000:00:14.3: Detected Intel(R) Dual Band Wireless AC 9462, REV=0x318

dmesg and lspci full outputs attached.
Comment by loqs (loqs) - Friday, 27 December 2019, 15:56 GMT

Loading...