Bug 1180344 - iwlwifi: Kernel 5.10 fails to boot with workqueue lockup
iwlwifi: Kernel 5.10 fails to boot with workqueue lockup
Status: RESOLVED FIXED
: 1180342 1180360 1180376 1180389 1180396 1180402 (view as bug list)
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel
Current
x86-64 openSUSE Tumbleweed
: P5 - None : Critical (vote)
: ---
Assigned To: openSUSE Kernel Bugs
E-mail List
https://bugzilla.kernel.org/show_bug....
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-12-25 01:19 UTC by Adam Stephens
Modified: 2021-01-21 13:08 UTC (History)
28 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
journal from failed boot (127.00 KB, text/plain)
2020-12-25 01:19 UTC, Adam Stephens
Details
lspci (2.27 KB, text/plain)
2020-12-25 01:20 UTC, Adam Stephens
Details
cpuinfo (11.53 KB, text/plain)
2020-12-25 01:20 UTC, Adam Stephens
Details
fstab (900 bytes, text/plain)
2020-12-25 01:20 UTC, Adam Stephens
Details
5.10.2 failed boot (123.94 KB, text/x-vhdl)
2020-12-25 02:10 UTC, Adam Stephens
Details
Tentative fix patch (1.49 KB, patch)
2020-12-27 11:53 UTC, Takashi Iwai
Details | Diff
Fix for bug 1180344 (681 bytes, patch)
2020-12-27 12:40 UTC, Arjen de Korte
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Stephens 2020-12-25 01:19:21 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
Comment 1 Adam Stephens 2020-12-25 01:20:10 UTC
Created attachment 844694 [details]
lspci
Comment 2 Adam Stephens 2020-12-25 01:20:34 UTC
Created attachment 844695 [details]
cpuinfo
Comment 3 Adam Stephens 2020-12-25 01:20:56 UTC
Created attachment 844696 [details]
fstab
Comment 4 Adam Stephens 2020-12-25 02:09:49 UTC
Problem still exists in 5.10.2 from Kernel:Stable.

kernel-default-5.10.2-1.1.g572ce1d.x86_64
Comment 5 Adam Stephens 2020-12-25 02:10:17 UTC
Created attachment 844697 [details]
5.10.2 failed boot
Comment 6 Maximilian Trummer 2020-12-25 11:34:28 UTC
I get the same problem on a Thinkpad T495, but my desktop boots fine with 5.10
Comment 7 Robby Engelmann 2020-12-25 13:50:58 UTC
Same here on a Tuxedo Infinity Book.
Comment 8 Robby Engelmann 2020-12-25 14:30:57 UTC
*** Bug 1180342 has been marked as a duplicate of this bug. ***
Comment 9 Frank Krüger 2020-12-25 14:48:01 UTC
Are you using iwlwifi? If so, does blacklisting it solve the issue?
Comment 10 Robby Engelmann 2020-12-25 15:30:59 UTC
how can I blacklist it? It should be used indeed.
Comment 11 Frank Krüger 2020-12-25 15:33:01 UTC
If blacklisting iwlwifi helps, you are probably hit by https://bugzilla.kernel.org/show_bug.cgi?id=210733.
Comment 12 Adam Stephens 2020-12-25 15:42:18 UTC
Yes, blacklisting iwlwifi does allow the system to boot fully.

Thanks.
Comment 13 Frank Krüger 2020-12-25 15:43:23 UTC
(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.)
Comment 14 Robby Engelmann 2020-12-25 16:12:14 UTC
blacklisting successfully started the system now. So you had the right idea
Comment 15 Bit Juggler 2020-12-25 16:27:52 UTC
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.
Comment 16 Arjen de Korte 2020-12-25 21:28:22 UTC
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.
Comment 17 Frank Krüger 2020-12-25 21:43:41 UTC
(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.
Comment 18 Frank Krüger 2020-12-25 23:54:14 UTC
*** Bug 1180360 has been marked as a duplicate of this bug. ***
Comment 19 Eric Renfro 2020-12-26 01:51:21 UTC
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.
Comment 20 Arjen de Korte 2020-12-26 10:46:39 UTC
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.
Comment 21 Takashi Iwai 2020-12-27 07:57:50 UTC
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.
Comment 22 Frank Krüger 2020-12-27 08:22:15 UTC
(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".
Comment 23 Takashi Iwai 2020-12-27 08:40:50 UTC
(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.
Comment 24 Frank Krüger 2020-12-27 08:57:44 UTC
(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.
Comment 25 Takashi Iwai 2020-12-27 09:08:30 UTC
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?
Comment 26 Frank Krüger 2020-12-27 09:13:35 UTC
(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'.
Comment 27 Takashi Iwai 2020-12-27 09:16:39 UTC
OK, then the blind shot was wrong, and we need to track down more deeply...
Comment 28 Frank Krüger 2020-12-27 09:24:16 UTC
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
Comment 29 Takashi Iwai 2020-12-27 09:32:52 UTC
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.
Comment 30 Frank Krüger 2020-12-27 10:31:10 UTC
(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)!
Comment 31 Frank Krüger 2020-12-27 10:44:16 UTC
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.
Comment 32 Takashi Iwai 2020-12-27 11:52:50 UTC
Good to hear.  Then this is likely the code touching the firmware tlv data that may be read only.  The fix patch below.
Comment 33 Takashi Iwai 2020-12-27 11:53:25 UTC
Created attachment 844708 [details]
Tentative fix patch
Comment 34 Arjen de Korte 2020-12-27 12:31:14 UTC
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.
Comment 35 Arjen de Korte 2020-12-27 12:40:21 UTC
Created attachment 844714 [details]
Fix for bug 1180344
Comment 36 Klein Kravis 2020-12-27 14:37:55 UTC
(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?
Comment 37 Arjen de Korte 2020-12-27 14:46:22 UTC
(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.
Comment 38 Takashi Iwai 2020-12-27 17:01:02 UTC
(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.
Comment 39 Thomas Rother 2020-12-28 09:54:16 UTC
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?
Comment 40 Arjen de Korte 2020-12-28 10:01:24 UTC
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.
Comment 41 Takashi Iwai 2020-12-28 10:18:44 UTC
*** Bug 1180389 has been marked as a duplicate of this bug. ***
Comment 42 Huy Phung 2020-12-28 11:33:10 UTC
*** Bug 1180396 has been marked as a duplicate of this bug. ***
Comment 43 Michal Kubeček 2020-12-28 12:01:47 UTC
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.
Comment 44 Takashi Iwai 2020-12-28 12:38:02 UTC
*** Bug 1180402 has been marked as a duplicate of this bug. ***
Comment 45 Frank Krüger 2020-12-28 18:22:53 UTC
JFYI: kernel-default-5.10.3-2.1.g73f6c2f.x86_64 from Kernel:stable boots fine without the above-mentioned workaround. Thx.
Comment 46 ulfbart 2020-12-28 19:47:13 UTC
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)
Comment 47 Arjen de Korte 2020-12-28 22:19:46 UTC
(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.
Comment 48 Klein Kravis 2020-12-28 22:24:51 UTC
*** Bug 1180376 has been marked as a duplicate of this bug. ***
Comment 49 Adam Stephens 2020-12-30 14:34:30 UTC
(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.
Comment 50 Thomas Rother 2021-01-02 18:09:53 UTC
Also confirmed, kernel 5.10.3 works without workarounds. Marking resolved fixed
Comment 51 Michal Kubeček 2021-01-04 21:00:54 UTC
(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.
Comment 52 Axel Braun 2021-01-04 21:19:00 UTC
(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....
Comment 53 Arjen de Korte 2021-01-04 21:23:26 UTC
(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.
Comment 54 Jiri Slaby 2021-01-05 06:32:30 UTC
(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?
Comment 55 Takashi Iwai 2021-01-05 08:34:09 UTC
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.
Comment 56 Laudecir Daniel 2021-01-15 16:59:18 UTC
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
Comment 57 Adam Stephens 2021-01-15 18:11:50 UTC
(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.
Comment 58 Takashi Iwai 2021-01-21 13:08:57 UTC
The fix went in the upstream now.  Let's close.