Fedora Account System
Red Hat Associate
Red Hat Customer
1. Please describe the problem: System experiences a kernel panic during boot when alsactl attempts to load and initialize the snd_soc_rt712_sdca_dmic module. 2. What is the Version-Release number of the kernel: 7.2.5-200.fc44.x86_64 (Note: 7.2.4 is also affected) 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? 7.1.13 worked fine. Started from 7.2.4 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: 5. Does this problem occur with the latest Rawhide kernel? N/A 6. Are you running any modules that not shipped with directly Fedora's kernel?: N/A 7. Please attach the kernel logs. [ 1.027052] fedora kernel: Linux version 7.2.5-200.fc44.x86_64 (mockbuild@b7cf753306404a0aace7b8416a1a73b3) (gcc (GCC) 16.2.1 20260819 (Red Hat 16.2.1-2), GNU ld version 2.46.1-1.fc44) #1 SMP PREEMPT_DYNAMIC Fri Sep 11 15:11:05 UTC 2026 ... [ 27.779326] fedora kernel: soundwire sdw:0:3:025d:1713:01: Bus clash detected before INT mask is enabled [ 27.779569] fedora kernel: soundwire sdw:0:0:025d:0713:01: PARITY error detected before INT mask is enabled [ 28.776787] fedora kernel: rt712-sdca-dmic sdw:0:3:025d:1713:01: Defer on undeferrable control: 40800f13 [ 28.776997] fedora kernel: BUG: kernel NULL pointer dereference, address: 0000000000000058 [ 28.777052] fedora kernel: #PF: supervisor read access in kernel mode [ 28.777091] fedora kernel: #PF: error_code(0x0000) - not-present page [ 28.783059] fedora kernel: Oops: Oops: 0000 [#1] SMP NOPTI [ 28.783080] fedora kernel: CPU: 18 UID: 0 PID: 1878 Comm: alsactl Not tainted 7.2.5-200.fc44.x86_64 #1 PREEMPT(lazy) [ 28.783093] fedora kernel: Hardware name: Dell Inc. Precision 5690/096JV4, BIOS 1.25.0 06/30/2026 [ 28.783110] fedora kernel: RIP: 0010:__dev_printk+0x10/0x70 ... [ 28.783270] fedora kernel: Call Trace: [ 28.783285] fedora kernel: <TASK> [ 28.783298] fedora kernel: _dev_err+0x7f/0x99 [ 28.783309] fedora kernel: rt712_sdca_dmic_set_gain_put.cold+0x20/0x25 [snd_soc_rt712_sdca_dmic] [ 28.783321] fedora kernel: snd_ctl_elem_write+0x19a/0x1f0 [snd] [ 28.783331] fedora kernel: snd_ctl_ioctl+0x658/0x8a0 [snd] [ 28.783346] fedora kernel: __x64_sys_ioctl+0xb9/0x100 [ 28.783357] fedora kernel: do_syscall_64+0xe2/0x570 [ 28.783384] fedora kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 28.783494] fedora kernel: </TASK> [ 28.783506] fedora kernel: Modules linked in: snd_soc_rt712_sdca(+) snd_soc_rt712_sdca_dmic snd_soc_sof_sdw snd_soc_rt1316_sdw regmap_sdw_mbq snd_soc_intel_hda_dsp_common snd_soc_dmic snd_sof_probes regmap_sdw snd_hda_codec_nvhdmi snd_hda_codec_intelhdmi snd_hda_codec_hdmi snd_sof_pci_intel_mtl snd_sof_intel_hda_generic soundwire_intel snd_sof_intel_hda_sdw_bpt snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_intel_hda_mlink nf_conntrack_netbios_ns snd_sof_intel_hda nf_conntrack_broadcast soundwire_cadence nft_fib_inet snd_sof_pci nft_fib_ipv4 snd_sof_xtensa_dsp nft_fib_ipv6 snd_sof nft_fib snd_sof_utils nft_reject_inet snd_hda_ext_core nf_reject_ipv4 snd_soc_acpi_intel_match nf_reject_ipv6 snd_soc_acpi_intel_sdca_quirks nft_reject soundwire_generic_allocation snd_soc_sdw_utils nft_ct snd_soc_acpi intel_rapl_msr crc8 intel_uncore_frequency nft_chain_nat soundwire_bus intel_uncore_frequency_common snd_hda_intel nf_nat snd_soc_sdca x86_pkg_temp_thermal snd_hda_codec nf_conntrack snd_hda_core intel_powerclamp snd_soc_core iwlmld [ 28.783658] fedora kernel: CR2: 0000000000000058 [ 28.783671] fedora kernel: ---[ end trace 0000000000000000 ]--- Reproducible: Always
Created attachment 2157672 [details] kernel panic log
The oops comes from a type mix-up in sound/soc/codecs/rt712-sdca-dmic.c. The two gain kcontrol handlers read the driver data as struct rt712_sdca_priv, but this driver stores struct rt712_sdca_dmic_priv. "slave" is at a different offset in the two, so the dev_err() in the put handler's error path gets a NULL slave. Your log shows it: RSI, the dev argument of __dev_printk, is 0x8. Fix posted upstream: https://lore.kernel.org/all/20260920024232.710189-1-junjie.cao@intel.com/ It is compile-tested only; I don't have this hardware. The patch does not cover why the write fails in the first place ("Defer on undeferrable control: 40800f13", about a second after the "Bus clash" / "PARITY error" lines). With the patch that write should log "... can't be set" instead of oopsing. Whether the DMIC gain then works is unknown. One data point would help upstream: does a 7.1.13 boot on this machine also log that line? journalctl --list-boots journalctl -k -b -N | grep -i undeferrable (N = the index of a 7.1.13 boot.) The buggy code is the same in 7.1.13, so if the line is absent there, what changed in 7.2 is the failing write, not the oops path. If you can build a kernel with the patch, please reply on the lore thread with the result.