sof icon indicating copy to clipboard operation
sof copied to clipboard

[BUG][IPC4]Error “Unknown error while processing the request“ happens when testing suspend/resume with capture on TGL/ADL

Open keqiaozhang opened this issue 2 years ago • 3 comments

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

  1. Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
  2. Name of the topology file
    • Topology: cavs-tgl-nocodec.tplg/cavs-sdw.tplg
  3. 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

dmesg.txt

keqiaozhang avatar Aug 10 '22 13:08 keqiaozhang

@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)?

lgirdwood avatar Aug 10 '22 14:08 lgirdwood

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 avatar Aug 11 '22 08:08 keqiaozhang

@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.

lgirdwood avatar Aug 11 '22 12:08 lgirdwood

Still occuring 15th Sep.

kv2019i avatar Sep 15 '22 06:09 kv2019i

This test and scenario has been passing for multiple days (Intel testing rounds 15889 and 15851). Closing the issue to.

kv2019i avatar Oct 03 '22 06:10 kv2019i