[BUG] [CML] Infinite ipc tx error loop after suspend/resume floods journal
Describe the bug
After suspend/resume, the SOF driver enters an infinite error loop when PipeWire attempts to use the audio device. The driver repeatedly fails with -22 (EINVAL) on sof_pcm_prepare, flooding the journal with thousands of errors per second. The system does not recover automatically.
I diagnosed this by checking journalctl -r which showed the error spam. The errors occur at a rate high enough that systemd-journald reports "Missed N kernel messages".
To Reproduce
- Have PipeWire running with an active audio client (e.g., browser, Discord)
- Suspend the system (S3)
- Resume
- Observe error flood in
journalctl -f
Reproduction Rate Unable to determine exact rate as suspend/resume normally works. This occurred once so far, but when it does occur, the error loop is 100% consistent until PipeWire is restarted.
Expected behavior The driver should either:
- Successfully reinitialize after resume, or
- Fail gracefully with rate-limited errors, allowing userspace to recover without manual intervention
Impact Annoyance, but significant when it occurs:
- High CPU usage from systemd-journald processing the flood
- Journal grew by ~4GB in minutes before I noticed
- Requires manual restart of PipeWire to recover
Environment
- Branch name and commit hash:
- Kernel: 6.17.9-arch1-1 (Arch Linux mainline kernel)
- SOF: sof-firmware 2025.05.1-1 (Arch Linux package)
- Name of the topology file
- Topology: (default, using
skl_hda_dsp_genericas shown in logs)
- Topology: (default, using
- Name of the platform(s)
- Platform: Comet Lake PCH-LP cAVS (device
0000:00:1f.3) - Driver:
snd_sof_pci_intel_cnl - Audio server: PipeWire 1.4.9
- Platform: Comet Lake PCH-LP cAVS (device
Screenshots or console output
Error log from journalctl (repeats hundreds of times per second):
sof-audio-pci-intel-cnl 0000:00:1f.3: ipc tx error for 0x60010000 (msg/reply size: 108/20): -22
sof-audio-pci-intel-cnl 0000:00:1f.3: sof_ipc3_pcm_hw_params: pcm0 (HDA Analog), dir 1: STREAM_PCM_PARAMS ipc failed for stream_tag 2
sof-audio-pci-intel-cnl 0000:00:1f.3: sof_pcm_prepare: pcm0 (HDA Analog), dir 1: failed to set hw_params after resume
sof-audio-pci-intel-cnl 0000:00:1f.3: ASoC error (-22): at snd_soc_pcm_component_prepare() on 0000:00:1f.3
systemd-journald[284]: Missed 2 kernel messages
Workaround - restarting PipeWire clears the error state:
systemctl --user restart pipewire pipewire-pulse wireplumber
Additional context The bug appears to be in the driver's resume path failing to restore DSP state properly. PipeWire repeatedly retries the broken device, triggering the kernel error on each attempt. There is no rate limiting on the kernel side, causing the journal flood.
I do not have sof-logger output as the issue has been worked around and I cannot reliably reproduce it.
@ujfalusi @bardliao fyi - btw do we have any rate limiting on PCM ops, that would help with the logs.
@ABHIRAMSHIBU re the resume path, I suspect the Pipewire behavior is possibly different to Pulseaudio, do you have any logs from Pipewire around this event as it sound like the PCM state is not aligned between driver and Pipewire at resume.
@ABHIRAMSHIBU, is this a new install or a regression after a kernel/sof/pipewire update?
Can you share the output of alsa-info.sh --no-upload
sof_ipc3_pcm_hw_params: pcm0 (HDA Analog), dir 1: STREAM_PCM_PARAMS ipc failed for stream_tag 2
indicates that the Capture stream on HDA Analog is failing, do you have wired headset connected and you are using the Headset's mic?
Can you rename sof-dyndbg.conf.txt to sof-dyndbg.conf and put it in the /etc/modprobe.d/ folder and share the full dmesg log after rebooting?
Keep this enabled and when you reproduce the issue can you share the full kernel log?