sof
sof copied to clipboard
[BUG][IPC4]Error “Unknown error while processing the request“ happens when testing suspend/resume with capture on TGL/ADL
Describe the bug We observed this issue on TGL/ADL when testing IPC4+SOF Zephyr firmware. The reproduction is high, it may happens at the first round of test on some platforms. But it only happens when testing suspend/resume with capture, no such issue when testing the suspend/resume with playback.
[ 1119.289551] kernel: snd_sof:sof_ipc4_log_header: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc tx : 0x13080003|0x0: GLB_SET_PIPELINE_STATE
[ 1119.300216] kernel: snd_sof:sof_ipc4_log_header: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc tx reply: 0x33000006|0x0: GLB_SET_PIPELINE_STATE
[ 1119.300241] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: FW reported error: 6 - Unknown error while processing the request
[ 1119.300385] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc error for msg 0x13080003|0x0
[ 1119.300410] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: ASoC: error at soc_dai_trigger on SSP0 Pin: -22
[ 1119.300428] kernel: Port0: ASoC: dpcm_be_dai_trigger() failed at NoCodec-0 (-22)
[ 1119.300437] kernel: Port0: ASoC: trigger FE cmd: 0 failed: -22
To Reproduce For example on ADLP_RVP_NOCODEC_IPC4: TPLG=/lib/firmware/intel/avs-tplg/cavs-tgl-nocodec.tplg MODEL=ADLP_RVP_NOCODEC_IPC4 ~/sof-test/test-case/check-suspend-resume-with-audio.sh -l 5 -m capture
Reproduction Rate Almost 100%
Environment
- Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
- Kernel: sof-dev/67fc9186384f
- SOF: main/a10e118a4d25
- Zephyr:8e55e59c5917
- Name of the topology file
- Topology: cavs-tgl-nocodec.tplg/cavs-sdw.tplg
- Name of the platform(s) on which the bug is observed.
- Platform: ADLP_RVP_NOCODEC_IPC4 | ADLP_RVP_SDW_IPC4ZPH | TGLU_RVP_NOCODEC_IPC4ZPH | TGLU_RVP_SDW_IPC4ZPH
@keqiaozhang can you try with trace on/off (as this is a capture stream too). @plbossart could be a timing difference with IPC3 flow (its very similar to the issue with the old DMA stop / suspend flow before @ranj063 fixed the flows)?
can you try with trace on/off (as this is a capture stream too)
This issue can still be reproduced after disabling trace in kernel.
@keqiaozhang ok, thanks so it seems similar to the issue that @kv2019i and @ranj063 looked at in the past where 1 capture stream is enough to block suspend/resume in some situations.
Still occuring 15th Sep.
This test and scenario has been passing for multiple days (Intel testing rounds 15889 and 15851). Closing the issue to.