Repository navigation
[BUG] ipc timed out for 0x13000004|GLB_SET_PIPELINE_STATE on ADLP-NOCODEC #8072
Description
Activity
- addedbugSomething isn't working as expectedSomething isn't working as expectedP2Critical bugs or normal featuresCritical bugs or normal featuresIPC timeoutIPC timeout observedIPC timeout observedADLApplies to Alder Lake platformApplies to Alder Lake platformIntel Linux Daily testsThis issue can be found in internal Linux daily testsThis issue can be found in internal Linux daily testsIPC4Issues observed with IPC4 (same IPC as Windows)Issues observed with IPC4 (same IPC as Windows)
on Aug 22, 2023 Observed this issue on TGLH_SKU0A70_HDA_IPC4ZPH. Inner test ID:30594. The error is the same as ADLP_RVP_NOCODEC_IPC4ZPH.
- addedP1Blocker bugs or important featuresBlocker bugs or important featuresand removedP2Critical bugs or normal featuresCritical bugs or normal features
on Aug 25, 2023 Changing the priority to P1 due to this issue occurring on different platforms every day.
Having trouble to reproduce this locally. Have tried a also a few older/newer kenrels and firmware, plus the latest of both, but so far no luck. Will continue attempt to reproduce (as logs in the CI cases don't really reveal much).
@kv2019i its' possible we have some loops iterating over HW IP state changes (e.g. in Zephyr driver for clocks, PM etc). @abonislawski and I discussed and we need to add some time outs with legging to help undcover correctly log these issues.
Still no luck to reproduce this locally. Will try on more machines.
@keqiaozhang do you think this issue is only showing via CI automated testing only ? i.e. manual test is too slow to reporduce ?
Looking back at our Intel daily tests, this was last seen on the 25th Aug daily, and on a sof-hda-generic-4ch tplg system (not nocodec like this bug was originally). This does seem to occur with dmic, so potentially any tplg with the dmics could trigger this.
@keqiaozhang do you think this issue is only showing via CI automated testing only ? i.e. manual test is too slow to reporduce ?
This issue occurred three times in ci testing, I cannot manually reproduce it either.

@fredoh9 also observed this issue with SOF v2.7-rc1
on TGLU_UP_HDA (sh-tglu-up-hda-01). First failure is check-capture-300times.sh (31/300). But he couldn't manually reproduce this issue on the same device and another pne.[10359.326096] kernel: snd_sof:sof_ipc4_log_header: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc tx : 0x13000004|0x1: GLB_SET_PIPELINE_STATE [data size: 12] [10359.828018] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc timed out for 0x13000004|0x1 [10359.828142] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: Attempting to prevent DSP from entering D3 state to preserve context [10359.828147] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: ------------[ IPC dump start ]------------ [10359.828160] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: hda irq intsts 0x00000000 intlctl 0xc0000000 rirb 00 [10359.828165] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: dsp irq ppsts 0x00000000 adspis 0x00000000 [10359.828184] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: Host IPC initiator: 0x93000004|0x1|0x0, target: 0x0|0x0|0x0, ctl: 0x3 [10359.828189] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: ------------[ IPC dump end ]------------ [10359.828193] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: ------------[ DSP dump start ]------------ [10359.828196] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: IPC timeout [10359.828200] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: fw_state: SOF_FW_BOOT_COMPLETE (7) [10359.828207] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: 0x00000005: module: ROM, state: FW_ENTERED, running [10359.828236] kernel: snd_sof:sof_ipc4_find_debug_slot_offset_by_type: sof-audio-pci-intel-tgl 0000:00:1f.3: Slot type 0x4c455400 is not available in debug window [10359.828239] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: ------------[ DSP dump end ]------------ [10359.828258] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: failed to set final state 4 for all pipelines [10359.828263] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: ASoC: error at soc_component_trigger on 0000:00:1f.3: -110 [10359.828270] kernel: DMIC Raw: ASoC: trigger FE cmd: 1 failed: -110- addedP2Critical bugs or normal featuresCritical bugs or normal featuresand removedP1Blocker bugs or important featuresBlocker bugs or important features
on Sep 19, 2023 Observed this issue again on TGLU_RVP_NOCODEC-cavs2_5-ipc4-nocodec. Inner test ID: 32810.
Reproduced today,
planresultdetail/33110?model=ADLP_RVP_NOCODEC-cavs2_5-ipc4-nocodec&testcase=check-capture-50roundsReproduced today again,
Intel internal daily test: planresultdetail/33322?model=ADLP_RVP_NOCODEC-cavs2_5-ipc4-nocodec&testcase=check-capture-50roundsReproduced on ww41.4 https://sof-ci.ostc.intel.com/#/result/planresultdetail/32914
and ww42.4 https://sof-ci.ostc.intel.com/#/result/planresultdetail/33322Not reproduced in ww43, ww44, ww45 (till ww45.3) FYI @keqiaozhang @fredoh9 @kv2019i @RanderWang
This issue cannot be reproduced in CI. Closing this bug.
Describe the bug
Observed this issue in CI daily test, this issue happened when checking capture 100 times. But this issue cannot be reproduced manually and there's no error in mtrace.
** dmesg**
To Reproduce
~/sof-test/test-case/check-capture.sh -d 1 -l 100 -r 1
Reproduction Rate
Only happened once in CI, no reproductions so far.
Environment
dmesg.txt
mtrace.txt