Repository navigation
Intel Lunar Lake (ASUS Vivobook S5406SA): DSP panic creating drc.2.1, no audio at all #11076
Description
Activity
@arkybruh7 Could you please test this with a fresh SOF binary package (SOF FW + DRC lib) from thesofproject/sof-bin?
This will help determine whether the failure is caused by the DRC binary itself or by a firmware/drc module version mismatch.@arkybruh7 we do have an issue where if DRC mismatches with BaseFW then it can panic, in these cases only its caused by the DRC and baseFW not being from the same build version in the file system.
@arkybruh7 Could you please test this with a fresh SOF binary package (SOF FW + DRC lib) from thesofproject/sof-bin? This will help determine whether the failure is caused by the DRC binary itself or by a firmware/drc module version mismatch.
@abonislawski @lgirdwood so I actually went and grabbed the newest sof-bin release (2025.12.2) to test the mismatch theory since that got brought up
first just ran the normal install.sh, which pulled in the community-signed stuff by default. same panic, same fw version, no change at all.
so then I went back and manually swapped in the intel-signed versions instead, specifically:
/lib/firmware/intel/sof-ipc4/lnl/sof-lnl.ri /lib/firmware/intel/sof-ipc4-lib/lnl/*.bin /lib/firmware/intel/sof-ipc4-lib/lnl/drc.llextall pulled straight from the intel-signed folder in that same release archive so there's zero chance of anything being out of sync. ran update-initramfs and rebooted both times to make sure it actually took.
both tests gave me the exact same result:
sof-audio-pci-intel-lnl 0000:00:1f.3: Loaded firmware library: ADSPFW, version: 2.14.1.1
sof-audio-pci-intel-lnl 0000:00:1f.3: Booted firmware version: 2.14.1.1
sof-audio-pci-intel-lnl 0000:00:1f.3: FW reported error: 104 - Other failure of module instance initialization request
sof-audio-pci-intel-lnl 0000:00:1f.3: failed to create module drc.2.1
sof-audio-pci-intel-lnl 0000:00:1f.3: DSP panic!still cascades into pipeline.1, pipeline.4, pipeline.12, and pipeline.15 failing just like my first report. happens every single time on the first playback attempt no matter which signed variant I use.
so at this point I'm pretty confident it's not a version mismatch thing since both firmware and drc module came from the literal same release archive both times. feels like it's just something broken with drc.2.1 itself on LNL with fw 2.14.1.1. can grab a sof-logger trace or try an older release if that'd help you guys track it down
Update: Follow-up testing on the DRC panic, plus a related unresolved issue
Re: testing with a fresh SOF binary release
I tested with
sof-binrelease 2025.12.2 as suggested, in two configurations. First, a standard install viainstall.sh, which defaulted to the community-signed variant. Second, a manual installation using only the Intel-signed firmware, DRC library, and topology files from that same release archive, to eliminate any possibility of a version mismatch between components. Both configurations were followed by a full reboot to ensure the change took effect.Both tests produced identical results:
sof-audio-pci-intel-lnl 0000:00:1f.3: Loaded firmware library: ADSPFW, version: 2.14.1.1
sof-audio-pci-intel-lnl 0000:00:1f.3: Booted firmware version: 2.14.1.1
sof-audio-pci-intel-lnl 0000:00:1f.3: FW reported error: 104 - Other failure of module instance initialization request
sof-audio-pci-intel-lnl 0000:00:1f.3: failed to create module drc.2.1
sof-audio-pci-intel-lnl 0000:00:1f.3: DSP panic!Since both firmware and the DRC module were sourced from the same release archive in each test, and the failure was identical in both cases, this appears to rule out a version mismatch between the DRC module and base firmware as the root cause.
Unexpected change: panic ceased after enabling debug tracing
Following the above, I enabled
sof_debug=1in order to capture anmtracelog for further diagnosis. After the subsequent reboot, thedrc.2.1panic stopped occurring entirely. Across multiple boots since, the firmware has booted cleanly every time, andmtraceoutput showsdrc_initanddrc_set_config(withenable_switch = 1) completing without error.I want to flag this rather than present it as a resolution. No firmware or configuration files changed between the panicking and non-panicking states, only the debug tracing flag did. This is more consistent with a timing-sensitive race condition than an actual fix; enabling debug instrumentation is a well-known way to inadvertently alter timing enough to mask a race rather than resolve it. I'd treat the underlying issue as still present and potentially latent.
A second, related issue surfaced once the panic stopped: silent playback followed by distorted audio
With the panic no longer blocking pipeline creation, playback still produced no audible output, despite PipeWire reporting a healthy, active stream at the correct sink and volume. I worked through the following elimination process:
- PipeWire-level mute: Ruled out via
wpctl get-volume; no muted state reported. - ALSA channel mutes: Ruled out via full
amixer -c 0 scontentsoutput. TheSpeakerchannel was confirmed on and unmuted across multiple volume levels (90%, 60%, 30%). The channels showing[off]were Headphone, IEC958, and DMIC capture controls, none of which are part of the active output path. - Buffering/timing (XRUNs): Ruled out via repeated
speaker-testruns. Period timing was consistent (about 3.0s) across dozens of cycles with zero underrun/XRUN messages, at both full and reduced volume. - Power management: Ruled out;
snd_hda_intel'spower_saveparameter confirmed at0. - Smart amplifier misconfiguration: Ruled out. I2C buses 0 through 4 (the relevant DesignWare adapters, excluding display-related gmbus/AUX buses) were scanned with no devices detected. An ACPI device scan for known smart-amp identifiers (Cirrus, TI, Maxim, Realtek) also returned nothing. This board appears to have no discrete amplifier; the ALC294 codec handles amplification directly.
- Topology mismatch: Ruled out. The loaded topology,
sof-hda-generic-2ch.tplg, appears correct for this hardware. All Lunar Lake-specific topology files present under/lib/firmware/intel/sof-ipc4-tplg/are for SoundWire-based codecs (cs42l43,rt7xxseries, etc.), none of which apply to this board's plain HDA/ALC294 configuration. - DSP pipeline health: An
mtracecapture during a clean run showed the full pipeline building without error, withll_schedulestats reportingoverruns 0consistently over a 60+ second capture window.
Physical/hardware fault: ruled out via dual-boot comparison. This system is dual-boot with Windows on the same physical hardware. Under Windows, the internal speaker produces clean, fully correct audio with no crackling or dropout. Since the speaker, its wiring, and all physical connections are identical regardless of which OS is running, this rules out a mechanical or hardware-level fault entirely. A physically damaged speaker or connector would fail identically under both operating systems. This confirms the issue is specific to the Linux audio stack. (Bluetooth output on Linux was also tested and is clean, though this only confirms PipeWire/general audio routing works, not that the SOF DSP path specifically is fine, since Bluetooth output doesn't traverse the DSP.)
Disabling the
Post Mixer Analog Playback DRC switchviaamixerrestores audible output, but the result is distorted/crackling rather than clean, suggesting the DRC module remains implicated in some capacity even though it no longer triggers a hard panic.Current test in progress
I'm attempting to bypass the SOF DSP path entirely by forcing the legacy
snd_hda_inteldriver, to test the codec independently of DSP processing. An initial attempt via/etc/modprobe.d/alsa-base.confhad no effect;/sys/module/snd_intel_dspcfg/parameters/dsp_driverremained at0after the change, indicatingdsp_driveris compiled into the kernel rather than loaded as a module. I'm redoing this via thesnd_intel_dspcfg.dsp_driver=1GRUB kernel parameter instead. Results pending.Summary
Every individually testable layer, buffering, power management, amplifier hardware, physical speaker integrity, and topology selection, checks out clean. This points toward corruption occurring inside the SOF DSP's audio processing chain itself (EQ_IIR to EQ_FIR to DRC to mixer) at the sample-processing level, rather than a misconfiguration in any single component. Happy to provide additional logs or run further tests as needed.
- PipeWire-level mute: Ruled out via
@arkybruh7 pls ask you agent to make sure it has installed both the baseFW and DRC llext module from the latest SOF bin, it must check the md5 sums match (to sof-bin) and it must search the firmware directory for all files with the same name (as there are soft links) to align md5 sums. If the md5 sums do not align to release version in sof-bin then it must copy from sof-bin to firmware directory.
I have Lunarlake and DRC on my personal device and audio works with DRC when there is no mismatch between baseFW and DRC versions.I think @arkybruh7 's test already confirm, but to double check, I reviewed the Ubuntu packaged binaries for LNL and they seem correct (https://packages.ubuntu.com/questing/firmware-sof-signed , version 2025.05.1-1). @arkybruh7 we are asking about this a lot as we've had a few cases in the past where distributions shipped sof-bin updates with mismatching versions (e.g. in Ubuntu https://bugs.launchpad.net/ubuntu/+source/firmware-sof/+bug/2121849 ) . This should no longer happen.
And highlighting one piece of info from @arkybruh7 's analysis, "Following the above, I enabled sof_debug=1 in order to capture an mtrace log for further diagnosis. After the subsequent reboot, the drc.2.1 panic stopped occurring entirely. "
Can you check the installed files for 2.14.1.1?
[ 2655.624821] sof-audio-pci-intel-lnl 0000:00:1f.3: Booted firmware version: 2.14.1.1 [ 2655.642854] sof-audio-pci-intel-lnl 0000:00:1f.3: Loaded firmware library: ADSPFW, version: 2.14.1.1 # pacman -Q sof-firmware sof-firmware 2025.12-1 # md5sum /lib/firmware/intel/sof-ipc4/lnl/intel-signed/sof-lnl.ri 9d66bffa1da7bc493dbe2767fc03bf6f /lib/firmware/intel/sof-ipc4/lnl/sof-lnl.ri # md5sum /lib/firmware/intel/sof-ipc4-lib/lnl/B36EE4DA-006F-47F9-A06D-FECBE2D8B6CE.bin 9456b5416ce1d70d1d15d658135bc6c9 /lib/firmware/intel/sof-ipc4-lib/lnl/B36EE4DA-006F-47F9-A06D-FECBE2D8B6CE.binCan you check the installed files for 2.14.1.1?
[ 2655.624821] sof-audio-pci-intel-lnl 0000:00:1f.3: Booted firmware version: 2.14.1.1 [ 2655.642854] sof-audio-pci-intel-lnl 0000:00:1f.3: Loaded firmware library: ADSPFW, version: 2.14.1.1 # pacman -Q sof-firmware sof-firmware 2025.12-1 # md5sum /lib/firmware/intel/sof-ipc4/lnl/intel-signed/sof-lnl.ri 9d66bffa1da7bc493dbe2767fc03bf6f /lib/firmware/intel/sof-ipc4/lnl/sof-lnl.ri # md5sum /lib/firmware/intel/sof-ipc4-lib/lnl/B36EE4DA-006F-47F9-A06D-FECBE2D8B6CE.bin 9456b5416ce1d70d1d15d658135bc6c9 /lib/firmware/intel/sof-ipc4-lib/lnl/B36EE4DA-006F-47F9-A06D-FECBE2D8B6CE.binSOF Firmware Investigation Summary
Original Ubuntu firmware:
firmware-sof-signed 2025.05.1-1ubuntu0.1Original hashes:
sof-lnl.ri = f479866a873a9f81e0b2b2b09d430b09
drc.llext = 86ad3c2a9b682fc2ad28b0240ae6b314These did not match the official sof-bin-2025.12.2 LNL Intel-signed files:
sof-lnl.ri = 9d66bffa1da7bc493dbe2767fc03bf6f
drc.llext = 9456b5416ce1d70d1d15d658135bc6c9I backed up the original files and replaced them with the official Intel-signed binaries.
After reboot:
Booted firmware version: 2.14.1.1
Loaded firmware library: ADSPFW, version: 2.14.1.1The previous drc.2.1 error 104, DSP panic, and SOF IPC timeout are no longer appearing.
The firmware mismatch is therefore confirmed, and the newer firmware successfully boots. However, speaker output is still not working, so there is likely a separate ALSA/codec/output issue remaining.
@arkybruh7 this mismatch is cropping with other users too, we are doing a script to help: thesofproject/sof-bin#208
The firmware mismatch is therefore confirmed, and the newer firmware successfully boots. However, speaker output is still not working, so there is likely a separate ALSA/codec/output issue remaining.
Adding @shumingfan for speakers/codec.
Root of mismatch found. An update to 25.10 Ubuntu package has caused a regression and ships with the wrong LNL binary. The source Ubuntu package has the right binary, but incorrect one is put into the binary package. This was not present in original 25.10 package and seems to not be present in 26.04LST package.
Upstream Ubuntu bug to track: https://bugs.launchpad.net/ubuntu/+source/firmware-sof/+bug/2161105
The firmware mismatch is therefore confirmed, and the newer firmware successfully boots. However, speaker output is still not working, so there is likely a separate ALSA/codec/output issue remaining.
Adding @shumingfan for speakers/codec.
Adding HDA driver owner @KailangYang.
Do you have any idea about this issue?Possibly relevant data point from a different LNL board (ThinkPad X1 Carbon Gen 13, SoundWire RT713/RT1318): with matched 2.14.1 base firmware + drc.llext (md5 9d66bffa... / 9456b541...) on kernel 6.16, "failed to create module drc.21.1" / error 104 / DSP panic reproduces deterministically after the first runtime resume, and never while the DSP is kept from suspending (power/control=on) or right after a full firmware boot. That would also fit "the panic stopped after enabling sof_debug", since tracing keeps the DSP awake. Write-up with the experiment table and code references: #11229.
@deep-name, the tracing does not keeps the DSP awake.
Description
sof-audio-pci-intel-lnlcan't bring up any PCM on this machine. Firmware boots fine, but creating thedrc.2.1module always fails with error 104, which panics the DSP and times out the IPC. Once that happens, every other pipeline fails too not just analog playback, capture and DMIC go down with it.100% reproducible. Same failure happened 3 times in one boot's dmesg, on the first playback attempt each time.
Hardware
8086:a828, codec ALC294sof-audio-pci-intel-lnlSoftware
6.17.0-40-genericfirmware-sof-signed2025.05.1-1ubuntu0.1 (SOF fw 2.14.1.1)sof-hda-generic-2ch.tplgTo Reproduce
Expected behavior
drc.2.1initializes successfully and analog playback works.Actual behavior
drc.2.1fails to initialize (error 104), which panics the DSP and times out the IPC. This cascades:pipeline.1(analog playback),pipeline.4(analog capture),pipeline.12(DMIC), andpipeline.15(deepbuffer analog) all subsequently failto build for the same reason. So this isn't a speakers-only bug — capture and DMIC are down too.
The exact same sequence repeats word-for-word at t=19.6s and t=271.8s in the same boot, so it's not a one-off race at driver probe it fails every single time something tries to open the analog pipeline.
dmesg
Duplicate teardown lines for
pipeline.1,pipeline.4,pipeline.12, andpipeline.15omitted here same create-fails-then-cascades pattern repeated for each, happy to paste in full if useful.Additional context
Let me know what else would help, I can pull a full
alsa-infodump or a sof-logger trace if that narrows it down further.