Bugzilla – Bug 1180344
iwlwifi: Kernel 5.10 fails to boot with workqueue lockup
Last modified: 2021-01-21 13:08:57 UTC
Created attachment 844693 [details] journal from failed boot Linux 5.10.1 on my Thinkpad X1 Carbon Gen 7 fails to boot with workqueue lockup messages and a failure to mount /home. I've given it 10 minutes, but it will not complete booting. Previous kernels, including the fallback 5.9.14 do not exhibit this behavior. Dec 24 18:00:05 think kernel: BUG: workqueue lockup - pool cpus=5 node=0 flags=0x0 nice=0 stuck for 50s! Dec 24 18:00:05 think kernel: Showing busy workqueues and worker pools: Dec 24 18:00:05 think kernel: workqueue events: flags=0x0 Dec 24 18:00:05 think kernel: pwq 10: cpus=5 node=0 flags=0x0 nice=0 active=11/256 refcnt=12 Dec 24 18:00:05 think kernel: in-flight: 840:request_firmware_work_func Dec 24 18:00:05 think kernel: pending: delayed_fput, drm_fb_helper_dirty_work [drm_kms_helper], free_work, kfree_rcu_monitor, kernfs_notify_workfn, rfkill_global_led_trigger_worker [rfkill], smp_call_on_c> Dec 24 18:00:05 think kernel: pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2 Dec 24 18:00:05 Previous kernels, including the fallback 5.9.14 do not exhibit this behavior. think kernel: pending: vmstat_shepherd Dec 24 18:00:05 think kernel: workqueue events_long: flags=0x0 Dec 24 18:00:05 think kernel: pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2 Dec 24 18:00:05 think kernel: in-flight: 143:ucsi_init_work [typec_ucsi] Dec 24 18:00:05 think kernel: workqueue events_unbound: flags=0x2 Dec 24 18:00:05 think kernel: pwq 16: cpus=0-7 flags=0x4 nice=0 active=4/512 refcnt=6 Dec 24 18:00:05 think kernel: in-flight: 58:fsnotify_connector_destroy_workfn fsnotify_connector_destroy_workfn, 63:fsnotify_mark_destroy_workfn fsnotify_mark_destroy_workfn Dec 24 18:00:05 think kernel: workqueue rcu_gp: flags=0x8 Dec 24 18:00:05 think kernel: pwq 10: cpus=5 node=0 flags=0x0 nice=0 active=1/256 refcnt=2 Dec 24 18:00:05 think kernel: pending: process_srcu Dec 24 18:00:05 think kernel: workqueue mm_percpu_wq: flags=0x8 Dec 24 18:00:05 think kernel: pwq 10: cpus=5 node=0 flags=0x0 nice=0 active=2/256 refcnt=4 Dec 24 18:00:05 think kernel: pending: vmstat_update, lru_add_drain_per_cpu BAR(907) Dec 24 18:00:05 think kernel: workqueue kec_query: flags=0x0 Dec 24 18:00:05 think kernel: pwq 10: cpus=5 node=0 flags=0x0 nice=0 active=1/16 refcnt=2 Dec 24 18:00:05 think kernel: pending: acpi_ec_event_processor Dec 24 18:00:05 think kernel: workqueue usb_hub_wq: flags=0x4 Dec 24 18:00:05 think kernel: pwq 10: cpus=5 node=0 flags=0x0 nice=0 active=1/256 refcnt=2 Dec 24 18:00:05 think kernel: pending: hub_event [usbcore] Dec 24 18:00:05 think kernel: pool 0: cpus=0 node=0 flags=0x0 nice=0 hung=0s workers=4 idle: 5 770 7 Dec 24 18:00:05 think kernel: pool 10: cpus=5 node=0 flags=0x0 nice=0 hung=50s workers=4 idle: 764 43 133 Dec 24 18:00:05 think kernel: pool 16: cpus=0-7 flags=0x4 nice=0 hung=0s workers=8 idle: 8 60 59 62 61 64 ❯ rpm -qa | grep kernel-default kernel-default-5.10.1-1.1.x86_64 kernel-default-5.9.14-1.2.x86_64
Created attachment 844694 [details] lspci
Created attachment 844695 [details] cpuinfo
Created attachment 844696 [details] fstab
Problem still exists in 5.10.2 from Kernel:Stable. kernel-default-5.10.2-1.1.g572ce1d.x86_64
Created attachment 844697 [details] 5.10.2 failed boot
I get the same problem on a Thinkpad T495, but my desktop boots fine with 5.10
Same here on a Tuxedo Infinity Book.
*** Bug 1180342 has been marked as a duplicate of this bug. ***
Are you using iwlwifi? If so, does blacklisting it solve the issue?
how can I blacklist it? It should be used indeed.
If blacklisting iwlwifi helps, you are probably hit by https://bugzilla.kernel.org/show_bug.cgi?id=210733.
Yes, blacklisting iwlwifi does allow the system to boot fully. Thanks.
(In reply to Robby Engelmann from comment #10) > how can I blacklist it? It should be used indeed. Yes, of course. It was just a suggestion to find out whether iwlwifi is the culprit (cd /etc/modprobe.d, add 'blacklist iwlwifi' to 50-blacklist.conf, reboot.)
blacklisting successfully started the system now. So you had the right idea
Same problem here. The journal shows Dez 25 16:58:45 WORKSTATION kernel: Intel(R) Wireless WiFi driver for Linux Dez 25 16:58:45 WORKSTATION kernel: iwlwifi 0000:6e:00.0: enabling device (0000 -> 0002) Dez 25 16:58:45 WORKSTATION kernel: BUG: unable to handle page fault for address: ffffadee03d6127b Dez 25 16:58:45 WORKSTATION kernel: #PF: supervisor write access in kernel mode Dez 25 16:58:45 WORKSTATION kernel: #PF: error_code(0x0003) - permissions violation Dez 25 16:58:45 WORKSTATION kernel: PGD 100000067 P4D 100000067 PUD 1001cb067 PMD 107da2067 PTE 80000002a185d061 Dez 25 16:58:45 WORKSTATION kernel: Oops: 0003 [#1] SMP PTI Dez 25 16:58:45 WORKSTATION kernel: CPU: 3 PID: 72 Comm: kworker/3:1 Tainted: G U O 5.10.1-1-default #1 openSUSE Tumbleweed Dez 25 16:58:45 WORKSTATION kernel: Hardware name: TUXEDO P65xHP/P65xHP, BIOS 1.05.04RTR 02/22/2017 Dez 25 16:58:45 WORKSTATION kernel: Workqueue: events request_firmware_work_func Dez 25 16:58:45 WORKSTATION kernel: RIP: 0010:iwl_dbg_tlv_alloc_region+0x27/0x180 [iwlwifi] Dez 25 16:58:45 WORKSTATION kernel: Code: 00 00 00 0f 1f 44 00 00 41 57 41 56 41 55 41 54 55 53 48 83 ec 08 8b 46 04 44 8b 66 10 44 8b 6e 14 83 f8 3f 0f 86 0b 01 00 00 <c6> 46 37 00 48 89 fb > Dez 25 16:58:45 WORKSTATION kernel: RSP: 0018:ffffadee002dfce0 EFLAGS: 00010212 Dez 25 16:58:45 WORKSTATION kernel: RAX: 0000000000000040 RBX: ffff8fdb4b9e4018 RCX: 0000000000000000 Dez 25 16:58:45 WORKSTATION kernel: RDX: ffffffffc0f081b0 RSI: ffffadee03d61244 RDI: ffff8fdb4b9e4018 Dez 25 16:58:45 WORKSTATION kernel: RBP: 0000000000000000 R08: 0000000000000080 R09: 0000000000000001 Dez 25 16:58:45 WORKSTATION kernel: R10: ffffadee03d6128c R11: 0000000000000040 R12: 000000000000000c Dez 25 16:58:45 WORKSTATION kernel: R13: 0000000000000006 R14: ffff8fdc00bd8800 R15: ffff8fdc008ea800 Dez 25 16:58:45 WORKSTATION kernel: FS: 0000000000000000(0000) GS:ffff8feabecc0000(0000) knlGS:0000000000000000 Dez 25 16:58:45 WORKSTATION kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Dez 25 16:58:45 WORKSTATION kernel: CR2: ffffadee03d6127b CR3: 0000000310c92004 CR4: 00000000003706e0 Dez 25 16:58:45 WORKSTATION kernel: Call Trace: Dez 25 16:58:45 WORKSTATION kernel: iwl_dbg_tlv_alloc+0x79/0x120 [iwlwifi] Dez 25 16:58:45 WORKSTATION kernel: iwl_req_fw_callback+0x10f0/0x2480 [iwlwifi] Dez 25 16:58:45 WORKSTATION kernel: ? devres_add+0x1e/0x60 Dez 25 16:58:45 WORKSTATION kernel: ? fw_add_devm_name.part.0+0x5c/0x80 Dez 25 16:58:45 WORKSTATION kernel: ? assign_fw+0x6d/0x230 Dez 25 16:58:45 WORKSTATION kernel: request_firmware_work_func+0x4d/0x90 Dez 25 16:58:45 WORKSTATION kernel: process_one_work+0x1df/0x370 Dez 25 16:58:45 WORKSTATION kernel: worker_thread+0x50/0x400 Dez 25 16:58:45 WORKSTATION kernel: ? process_one_work+0x370/0x370 Dez 25 16:58:45 WORKSTATION kernel: kthread+0x11b/0x140 Dez 25 16:58:45 WORKSTATION kernel: ? __kthread_bind_mask+0x60/0x60 Dez 25 16:58:45 WORKSTATION kernel: ret_from_fork+0x22/0x30 Dez 25 16:58:45 WORKSTATION kernel: Modules linked in: btrtl snd_compress btbcm iwlwifi btintel snd_pcm_dmaengine kvm(+) fjes(-) r8169 videodev bluetooth snd_pcm irqbypass realtek snd_timer c> Dez 25 16:58:45 WORKSTATION kernel: CR2: ffffadee03d6127b Dez 25 16:58:45 WORKSTATION kernel: ---[ end trace 8e03a10eccb1ee9d ]--- Dez 25 16:58:45 WORKSTATION kernel: RIP: 0010:iwl_dbg_tlv_alloc_region+0x27/0x180 [iwlwifi] Dez 25 16:58:45 WORKSTATION kernel: Code: 00 00 00 0f 1f 44 00 00 41 57 41 56 41 55 41 54 55 53 48 83 ec 08 8b 46 04 44 8b 66 10 44 8b 6e 14 83 f8 3f 0f 86 0b 01 00 00 <c6> 46 37 00 48 89 fb > Dez 25 16:58:45 WORKSTATION kernel: RSP: 0018:ffffadee002dfce0 EFLAGS: 00010212 Dez 25 16:58:45 WORKSTATION kernel: RAX: 0000000000000040 RBX: ffff8fdb4b9e4018 RCX: 0000000000000000 Dez 25 16:58:45 WORKSTATION kernel: RDX: ffffffffc0f081b0 RSI: ffffadee03d61244 RDI: ffff8fdb4b9e4018 Dez 25 16:58:45 WORKSTATION kernel: RBP: 0000000000000000 R08: 0000000000000080 R09: 0000000000000001 Dez 25 16:58:45 WORKSTATION kernel: R10: ffffadee03d6128c R11: 0000000000000040 R12: 000000000000000c Dez 25 16:58:45 WORKSTATION kernel: R13: 0000000000000006 R14: ffff8fdc00bd8800 R15: ffff8fdc008ea800 Dez 25 16:58:45 WORKSTATION kernel: FS: 0000000000000000(0000) GS:ffff8feabecc0000(0000) knlGS:0000000000000000 Dez 25 16:58:45 WORKSTATION kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Dez 25 16:58:45 WORKSTATION kernel: CR2: ffffadee03d6127b CR3: 0000000310c92004 CR4: 00000000003706e0 However blacklisting iwlwifi is not really an option. I will use kernel 5.9.14 for the time being.
Same problem here, iwlwifi with AX200. Looking at the module options, I noticed that the the debug interface is enabled by default. Long shot, so I added options iwlwifi enable_ini=0 to /etc/modprobe.d/99-local.conf and rebooted. Lo-and-behold, system boots as usual and iwlwifi seems to work in kernel 5.10.1 as well. Let's see what upstream comes with, but so far it looks like there is a workaround.
(In reply to Arjen de Korte from comment #16) > Same problem here, iwlwifi with AX200. Looking at the module options, I > noticed that the the debug interface is enabled by default. Long shot, so I > added > > options iwlwifi enable_ini=0 > > to /etc/modprobe.d/99-local.conf and rebooted. Lo-and-behold, system boots > as usual and iwlwifi seems to work in kernel 5.10.1 as well. Let's see what > upstream comes with, but so far it looks like there is a workaround. I can confirm that the aforementioned workaround results in a booting system (5.10.2 from kernel:stable). Thx.
*** Bug 1180360 has been marked as a duplicate of this bug. ***
Confirmed, I do set options to enable_ini=0 (and trying to find the documentation on this for more information), and it works as well for the initial issue. Is this due to ABI issues from the mentioned changes in https://lwn.net/Articles/835774/ ? Looks like some ABI changes specifically.
I wouldn't be surprised if this is just caused by a change somewhere that happens to result in a huge increase in debug output that is overwhelming the debug_fs. After setting enable_ini=0 iwlwifi seems to work normally, just like it already did for hardware where the debug_fs isn't used at all. I also have a system with a Intel Dual Band Wireless-AC 7260, which works just fine without the workaround.
I haven't had time to take a deeper look (and the bug doesn't hit on my machine), but as a blind shot, I built a kernel with the patch with a revert of the commit in the relevant code path. Can anyone test a kernel package in OBS home:tiwai:bsc1180344? Just to be sure.
(In reply to Takashi Iwai from comment #21) > I haven't had time to take a deeper look (and the bug doesn't hit on my > machine), but as a blind shot, I built a kernel with the patch with a revert > of the commit in the relevant code path. Can anyone test a kernel package > in OBS home:tiwai:bsc1180344? Just to be sure. Tried your kernel, but failed with "bad shim signature".
(In reply to Frank Krüger from comment #22) > (In reply to Takashi Iwai from comment #21) > > I haven't had time to take a deeper look (and the bug doesn't hit on my > > machine), but as a blind shot, I built a kernel with the patch with a revert > > of the commit in the relevant code path. Can anyone test a kernel package > > in OBS home:tiwai:bsc1180344? Just to be sure. > > Tried your kernel, but failed with "bad shim signature". It's an unofficial package, so please test with Secure Boot disabled.
(In reply to Takashi Iwai from comment #21) > I haven't had time to take a deeper look (and the bug doesn't hit on my > machine), but as a blind shot, I built a kernel with the patch with a revert > of the commit in the relevant code path. Can anyone test a kernel package > in OBS home:tiwai:bsc1180344? Just to be sure. Disabling secure boot and booting kernel-default-5.10.2-1.1.gcb6a1b3.x86_64 from home:tiwai:bsc1180344 results in a black screen.
Then you're hitting a problem that is something else than this bug. I guess you get the same result from the kernel in OBS Kernel:stable, too?
(In reply to Takashi Iwai from comment #25) > Then you're hitting a problem that is something else than this bug. > I guess you get the same result from the kernel in OBS Kernel:stable, too? Yes, but your kernel with the "iwlwifi dbg revert" boots fine with 'options iwlwifi enable_ini=0'.
OK, then the blind shot was wrong, and we need to track down more deeply...
When boot fails, I can see Dez 27 09:48:27 kernel: iwlwifi 0000:03:00.0: enabling device (0000 -> 0002) Dez 27 09:48:27 kernel: iwlwifi 0000:03:00.0: api flags index 2 larger than supported by driver Dez 27 09:48:27 kernel: RIP: 0010:iwl_dbg_tlv_alloc_region+0x27/0x180 [iwlwifi] Dez 27 09:48:27 kernel: iwl_dbg_tlv_alloc+0x79/0x120 [iwlwifi] Dez 27 09:48:27 kernel: iwl_req_fw_callback+0x10f0/0x2480 [iwlwifi] Dez 27 09:48:27 kernel: Modules linked in: btrtl snd_intel_dspcfg btbcm soundwire_intel btintel tps6598x roles soundwire_generic_allocation soundwire_cadence bluetooth snd_hda_codec snd_hda_core uvcvideo kvm_amd videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 snd_hwdep kvm videobuf2_common soundwire_bus iwlwifi videodev ecdh_generic snd_soc_core dmi_sysfs ftsteutates pcc_cpufreq(-) cfg80211 irqbypass ecc mc snd_compress joydev snd_pcm_dmaengine pcspkr efi_pstore snd_pcm thinkpad_acpi wmi_bmof r8169 sp5100_tco i2c_piix4 k10temp realtek snd_timer snd_rn_pci_acp3x mdio_devres snd_pci_acp3x ledtrig_audio ipmi_devintf libphy rfkill ipmi_msghandler ucsi_acpi(+) snd typec_ucsi typec soundcore ac tiny_power_button i2c_multi_instantiate i2c_scmi button acpi_cpufreq xfs nls_iso8859_1 nls_cp437 vfat fat libcrc32c fuse configfs amdgpu iommu_v2 gpu_sched ttm i2c_algo_bit rtsx_pci_sdmmc drm_kms_helper mmc_core syscopyarea sysfillrect sysimgblt fb_sys_fops cec xhci_pci xhci_pci_renesas crct10dif_pclmul Dez 27 09:48:27 gropius kernel: RIP: 0010:iwl_dbg_tlv_alloc_region+0x27/0x180 [iwlwifi] Using the above-mentioned workaround it boots fine: Dez 27 09:54:33 kernel: iwlwifi 0000:03:00.0: enabling device (0000 -> 0002) Dez 27 09:54:33 kernel: iwlwifi 0000:03:00.0: api flags index 2 larger than supported by driver Dez 27 09:54:33 kernel: iwlwifi 0000:03:00.0: TLV_FW_FSEQ_VERSION: FSEQ Version: 89.3.35.22 Dez 27 09:54:33 kernel: iwlwifi 0000:03:00.0: loaded firmware version 59.601f3a66.0 cc-a0-59.ucode op_mode iwlmvm Dez 27 09:54:34 kernel: iwlwifi 0000:03:00.0: Detected Intel(R) Wi-Fi 6 AX200 160MHz, REV=0x340 Dez 27 09:54:34 kernel: iwlwifi 0000:03:00.0: base HW address: a8:7e:ea:04:a8:67 Dez 27 09:54:34 NetworkManager[826]: <info> [1609059274.8447] rfkill3: found Wi-Fi radio killswitch (at /sys/devices/pci0000:00/0000:00:02.3/0000:03:00.0/ieee80211/phy0/rfkill3) (driver iwlwifi) Dez 27 09:54:34 gropius kernel: iwlwifi 0000:03:00.0 wlp3s0: renamed from wlan0
Thanks, that shows that the problem still persists. I refreshed the same repo with another shot, now a new kernel is being built. Please check it later again. It'll be based on 5.10.3.
(In reply to Takashi Iwai from comment #29) > Thanks, that shows that the problem still persists. > > I refreshed the same repo with another shot, now a new kernel is being > built. Please check it later again. It'll be based on 5.10.3. 5.10.3-1.g0a5cd07-default x86_64 from your repo works fine (without the workaround)!
For the sake of completeness, I have tested kernel 5.10.3 from Kernel:stable without your patch, and it fails to boot with the messages shown in comment 28.
Good to hear. Then this is likely the code touching the firmware tlv data that may be read only. The fix patch below.
Created attachment 844708 [details] Tentative fix patch
Looking at drivers/net/wireless/intel/iwlwifi/iwl-debug.h, IWL_DEBUG_FW accepts a va_arg list, so why not replace the offending code with IWL_DEBUG_FW(trans, "WRT: parsing region: %.*s\n", IWL_FW_INI_MAX_NAME, reg->name); This will have the same effect, but without the terrible habit of modifying a buffer/string one doesn't own.
Created attachment 844714 [details] Fix for bug 1180344
(In reply to Maximilian Trummer from comment #6) > I get the same problem on a Thinkpad T495, but my desktop boots fine with > 5.10 Same issue on my ThinkBook 13s IWL (See bug: 1180376) Would blacklisting iwlwifi prevent WiFi from working?
(In reply to Klein Kravis from comment #36) > Same issue on my ThinkBook 13s IWL (See bug: 1180376) Would blacklisting > iwlwifi prevent WiFi from working? You don't need to blacklist iwlwifi (which would indeed prevent WiFi from working). In https://bugzilla.suse.com/show_bug.cgi?id=1180344#c16 a workaround is described which will temporary fix this problem. It disables the debug logging, which is where the problem seems to be in. Unless you're actively involved in the iwlwifi development, it is highly unlikely that you need the debuglog anyway.
(In reply to Arjen de Korte from comment #34) > Looking at drivers/net/wireless/intel/iwlwifi/iwl-debug.h, IWL_DEBUG_FW > accepts a va_arg list, so why not replace the offending code with > > IWL_DEBUG_FW(trans, "WRT: parsing region: %.*s\n", IWL_FW_INI_MAX_NAME, > reg->name); > > This will have the same effect, but without the terrible habit of modifying > a buffer/string one doesn't own. That would work, yes. But then add a comment why this form is used (i.e. it may be a non-terminated string and may be read-only) before the call, otherwise the reader at a later point would overlook the need of the modifier again.
I also have the same issue on a dell precision 7530. Just for info (I am not deep in kernel dev issues) and for understanding: So the only current solutions are a) either disable iwlwifi with "options iwlwifi enable_ini=0" and boot kernel 5.10, but with loosing wireless functionality as a consequence b) go back to 5.9 Is that correct?
No, that is not correct. The workaround from https://bugzilla.suse.com/show_bug.cgi?id=1180344#c16 will not disable iwlwifi. It will only switch of the debug logging that is enabled by default for some hardware. It will work just fine.
*** Bug 1180389 has been marked as a duplicate of this bug. ***
*** Bug 1180396 has been marked as a duplicate of this bug. ***
I was a bit surprised that the regression is discussed here and in kernel.org bugzilla but there doesn't seem to be any word in linux-wireless and netdev mailing lists so I sent a note about it to both and to offending commit author.
*** Bug 1180402 has been marked as a duplicate of this bug. ***
JFYI: kernel-default-5.10.3-2.1.g73f6c2f.x86_64 from Kernel:stable boots fine without the above-mentioned workaround. Thx.
Seams that I'm also effected with my Notebook The brand new upgrad "zypper dup": openSUSE Tumbleweed 20201226-0 -> 20201227-0 Don't fix the issue, but echo "options iwlwifi enable_ini=0" >> /etc/modprobe.d/99-local.conf fix it! By the way, my NUC7i7BNHX1 isn't effected: 40: None 00.0: 10701 Ethernet [Created at net.126] Unique ID: 16Zt.ndpeucax6V1 Parent ID: F1ls.BKkqJHftN68 SysFS ID: /class/net/wlp58s0 SysFS Device Link: /devices/pci0000:00/0000:00:1c.5/0000:3a:00.0 Hardware Class: network interface Model: "Ethernet network interface" Driver: "iwlwifi" Driver Modules: "iwlwifi" Device File: wlp58s0 HW Address: 0a:f6:98:7c:20:e6 Permanent HW Address: f8:63:3f:3c:85:fc Link detected: no Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #7 (Ethernet controller) Effekted Notebook Fujitsu Lifebook U939X: 67: None 00.0: 10701 Ethernet [Created at net.126] Unique ID: 63Vg.ndpeucax6V1 Parent ID: Dhtl.7WFAbqD11t0 SysFS ID: /class/net/wlp0s20f3 SysFS Device Link: /devices/pci0000:00/0000:00:14.3 Hardware Class: network interface Model: "Ethernet network interface" Driver: "iwlwifi" Driver Modules: "iwlwifi" Device File: wlp0s20f3 HW Address: 7c:b2:7d:31:b5:55 Permanent HW Address: 7c:b2:7d:31:b5:55 Link detected: yes Config Status: cfg=no, avail=yes, need=no, active=unknown Attached to: #9 (Ethernet controller)
(In reply to ulfbart from comment #46) > By the way, my NUC7i7BNHX1 isn't effected: [...] > Effekted Notebook Fujitsu Lifebook U939X: Whether or not you're seeing this, depends on the model of the network card. I have older AC-7260 network cards and all of them are working properly. Only a single notebook with an AX200 network card is affected here. But I've also seen reports for the AC-9260 with similar problems and most likely there will be more. It probably can be found in the sources for iwlwifi which ones will be affected, but I didn't look that up. If one is worried about this, adding the workaround even when it is not needed is not going to harm.
*** Bug 1180376 has been marked as a duplicate of this bug. ***
(In reply to Frank Krüger from comment #45) > JFYI: kernel-default-5.10.3-2.1.g73f6c2f.x86_64 from Kernel:stable boots > fine without the above-mentioned workaround. Thx. I can confirm that I'm able to boot into 5.10.3 without any workarounds.
Also confirmed, kernel 5.10.3 works without workarounds. Marking resolved fixed
(In reply to Thomas Rother from comment #50) > Also confirmed, kernel 5.10.3 works without workarounds. Marking resolved > fixed That would be premature. First, 5.10.3 certainly does not work without workaround, only our KotD snapshot does, thanks to Takashi's patch. Even current mainline (or 5.11-rc2) does not have the issue addressed, AFAICS. Thus I would prefer to keep the bug open until we have some response from upstream and until a fix (Takashi's, Arjen's or some other) is on its way to mainline.
(In reply to Michal Kubeček from comment #51) > (In reply to Thomas Rother from comment #50) > > Also confirmed, kernel 5.10.3 works without workarounds. Marking resolved > > fixed > > That would be premature. First, 5.10.3 certainly does not work without > workaround, only our KotD snapshot does, thanks to Takashi's patch. Even > current mainline (or 5.11-rc2) does not have the issue addressed, AFAICS. I have upgraded to Kernel 5.10.3 without workaround and iwlwifi works....
(In reply to Axel Braun from comment #52) > I have upgraded to Kernel 5.10.3 without workaround and iwlwifi works.... That is because Takashi patched out the offending code in Kernel 5.10.3 before it was released in Tumbleweed. But upstream Kernel 5.10.3 (and 5.10.4 as well) is still broken. That's why it is probably a good idea to leave this open, as the upstream fix is not available. FWIW, upstream might choose a completely different approach to fix this.
(In reply to Arjen de Korte from comment #35) > Created attachment 844714 [details] This is the second time iwlwifi tries to write to the FW data: commit ea0cca61d628662e4a1b26c77c7646f9a0257069 Author: Jiri Slaby <jirislaby@kernel.org> Date: Fri Jun 12 09:38:00 2020 +0200 iwlwifi: fix crash in iwl_dbg_tlv_alloc_trigger I wonder why the data is not const?
It must be just laziness :) I've prepared a patch to add const, but it's not for 5.11 (and still waiting for the reaction of this bug itself), so the patch hasn't been submitted yet.
If it may be of help, I still cannot boot any kernel version starting from 5.10... Problem started with the kernel update of Tumbleweed 20201223. All later updates are of no help. System does not boot with the workaround suggested "options iwlwifi enable_ini=0", and neither with UEFI disabled. It also does not leave log messages in journalctl even with in recovery mode. Running fine with: Linux version 5.9.10-1-default (geeko@buildhost) (gcc (SUSE Linux) 10.2.1 20201117 [revision 98ba03ffe0b9f37b4916ce6238fad754e00d720b], GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.35.1.20201112-1) #1 SMP Mon Nov 23 09:08:45 UTC 2020 (b7c3768) BOOT_IMAGE=/boot/vmlinuz-5.9.10-1-default root=UUID=n resume=/dev/disk/by-uuid/n splash=silent quiet showopts amdgpu.si_support=1 radeon.si_support=0 acpi_backlight=amdgpu_bl0 tumbleweed installed: 20210107 kernel-default-5.10.4-1.1.x86_64 kernel-default-5.10.3-1.2.x86_64 kernel-default-5.9.10-1.1.x86_64 ASUS X550IU/X550IU, BIOS X550IU.308 04/19/2019
(In reply to Laudecir Daniel from comment #56) > If it may be of help, I still cannot boot any kernel version starting from > 5.10... > Problem started with the kernel update of Tumbleweed 20201223. All later > updates are of no help. System does not boot with the workaround suggested > "options iwlwifi enable_ini=0", and neither with UEFI disabled. It also does > not leave log messages in journalctl even with in recovery mode. This issue is for iwlwifi. I suggest you create another if you are experience a different problem.
The fix went in the upstream now. Let's close.