Repository navigation
[BUG]xrun and ipc timeout in multiple-pause-resume on ADLP_RVP_NOCODEC #4372
Description
Describe the bug
xrun happens and ipc timed out when PCM_PARAMS
in inner daily ADL 4679
To Reproduce
TPLG=sof-tgl-nocodec-ci.tplg ~/sof-test/test-case/multiple-pause-resume.sh -r 25
Reproduction Rate
almost 100% with inner daily ADL 4679 recipe
Environment
Kernel Branch: topic/sof-dev
Kernel Commit: 56ab165b
SOF Branch: main
SOF Commit:fdcf636530f5
Topology:sof-tgl-nocodec-ci.tplg
Platform:8 ADLP_RVP_NOCODEC
Screenshots or console output
[console]
aplay: pcm_write:2061: write error: Input/output error
#+ | 00%
=== PAUSE ===
(6/25) pcm'DMIC16kHz' cmd'arecord' id'7': Wait for 111 ms before pause
(6/25) pcm'DMIC16kHz' cmd'arecord' id'7': Wait for 179 ms before resume
error: in logger_read(), fread(..., /sys/kernel/debug/sof/trace) failed: Operation not permitted(-1)
arecord: do_pause:1545: pause push error: Connection timed out[etrace]
[ 395301920.229613] ( 3884852.000000) c3 dw-dma src/drivers/dw/dma.c:1102 ERROR dw_dma_get_data_size(): xrun detected
[ 395301937.990029] ( 17.760416) c3 dai 3.16 src/audio/dai.c:886 ERROR dai_report_xrun(): underrun due to no data available
[ 395301955.125445] ( 17.135416) c3 dai 3.16 src/audio/dai.c:661 ERROR comp_underrun(): dev->comp.id = 16, source->avail = 192, copy_bytes = 0
[ 395302070.281690] ( 115.156242) c3 pipe 3.17 ....../pipeline-stream.c:168 ERROR pipeline_copy(): ret = -61, start->comp.id = 16, dir = 1
[ 395302089.396273] ( 19.114582) c3 pipe 3.17 ..../pipeline-schedule.c:63 ERROR pipeline_task(): xrun recover failed! pipeline will be stopped!
[ 395313177.156249] ( 11087.759766) c2 dmic-dai 2.0 src/drivers/intel/dmic.c:1557 ERROR dmic_irq_handler(): full fifo B or PDM overrun
Activity
keyonjie commentedon Jun 22, 2021
This happens on TGL also, according to today's daily 4778
keyonjie commentedon Jun 22, 2021
It works with 1.8, looks like a regression.
[-][BUG][ADL]xrun and ipc timeout in multiple-pause-resume on ADLP_RVP_NOCODEC[/-][+][BUG]xrun and ipc timeout in multiple-pause-resume on TGLU_RVP_NOCODEC / ADLP_RVP_NOCODEC[/+]lgirdwood commentedon Jun 30, 2021
@keyonjie @kv2019i Are we sure we are masking/clearing the DMIC IRQ ? as we are getting an IPC timout here and AFAICT not a crash (i.e. are we spinning in DMIC IRQ) ?
kv2019i commentedon Jun 30, 2021
@keyonjie @lgirdwood Given this does not happen on 1.8 and happens on multicore tplg, I wonder if it's related to this dmic commit "Drivers: Intel: DMIC: Run dmic_work() in the same core as other driver". The fix this does seems correct and I'd actually expect the reverse result, but given the results, this could be related. I could not reproduce this locally yet. Bisect is probably the best option here and this dmic patch is a good starting point.
@lgirdwood we do stop the fifo packers in the IRQ, so we should not be getting floods anymore (and even if we did, this should show up in the log).
lgirdwood commentedon Jul 6, 2021
@singalsu any comment here ? Can the DMIC work be "EDF" work ?
[-][BUG]xrun and ipc timeout in multiple-pause-resume on TGLU_RVP_NOCODEC / ADLP_RVP_NOCODEC[/-][+][BUG]xrun and ipc timeout in multiple-pause-resume on ADLP_RVP_NOCODEC[/+]XiaoyunWu6666 commentedon Jul 7, 2021
I guess this is related to multicore and we only test multicore with sof-tgl-nocodec-ci.tplg on ADLP_RVP_NOCODEC ,right , so I remove TGL from the title and the label @keyonjie @keqiaozhang thanks
singalsu commentedon Jul 21, 2021
@lgirdwood Sorry for slow response, I missed this. The scheduling of dmic work is not critical. The execution of HW gain updates do not need to be in exact grid, some jitter is allowed. I don't think it would make the zipper noise from gain updates audible. Also if a 200 ms ramp is 200 +/- 5 ms something or maybe even +/- 10 ms it does not impact use cases. I can test this, how is the work type changed?
singalsu commentedon Jul 21, 2021
@lgirdwood @RanderWang We could eliminate HW gain ramping in dmic driver if we could ensure there's always volume component in the capture pipeline that could do the unmute ramp. The logaritmic ramp type would need to be added to volume. In DMIC NHLT patch I've replaced the topology defined ramp duration with hard-coded sample rate dependent ramp. It's not nice but currently there's no other way since IPC4 for DMIC does not contain unmute ramp information. So, combined this issue and IPC4 could be a justification to implement the unmute ramp in volume with pipeline like DMIC -> volume -> IIR -> host. The DMIC umute sequence without ramp would take only 3 dmic_work() calls. It could also be scheduled at lower rate.
lgirdwood commentedon Jul 21, 2021
@singalsu can the unmute ramp steps be part of the copy() callback. e.g. every copy() increment the volume ?
XiaoyunWu6666 commentedon Aug 3, 2021
did not see this in CI daily tests , was there any possible solutions that has solved it?
I lower the priority , shall we close it?
lgirdwood commentedon Aug 3, 2021
Lets monitor and close if not reproducing over next few days.
keqiaozhang commentedon Dec 13, 2021
Confirmed that this issue is fixed with latest main and stable v2.0 branch.