Stress test: pause/release playback or capture when both playback and capture are running will cause IPC timed out error

[zhuqingliang]

environment:
on UP^2
sof-dev: a3a39f21218c074c71cd28b0c2c782b1626df3e3
sof: 2d92796
soft: 47339d2
tplg file name :
topology/test/test-ssp5-mclk-0-I2S-volume-s16le-s16le-48k-24576k-nocodec.tplg

reproduce steps:
run aplay and arecord at same time , pressing space key ,don't release . A few seconds later ' input/output error' . check dmesg log.

log:

dmesg6.log
rmbox6.log

[lgirdwood]

please also add rmbox error log. just run "rmbox". How reproducible in % ?

[tlauda]

Please verify with fd55d5f.

[xiulipan]

after run aplay and arecord at same time
inject XRUN for ALSA
echo 1 > /proc/asound/card0/pcm0p/sub0/xrun_injection

[ 336.761868] sof-audio sof-audio: error : DSP panic!
[ 336.761886] sof-audio sof-audio: panic: dsp_oops_offset 788480 offset 788480
[ 336.761894] sof-audio sof-audio: status: fw entered - code 00000005
[ 336.761920] sof-audio sof-audio: error: runtime exception
[ 336.761927] sof-audio sof-audio: error: trace point 00004000
[ 336.761934] sof-audio sof-audio: error: DSP Firmware Oops
[ 336.761942] sof-audio sof-audio: error: Exception Cause: LoadStorePIFDataErrorCause, Synchronous PIF data error during LoadStore access
[ 336.761951] sof-audio sof-audio: EXCCAUSE 0x0000000d EXCVADDR 0x00060534 PS 0x00060025 SAR 0x00000020
[ 336.761959] sof-audio sof-audio: EPC1 0xbe014732 EPC2 0xbe014724 EPC3 0xbe014724 EPC4 0x00000000
[ 336.761967] sof-audio sof-audio: EPC5 0xbe01c28e EPC6 0x00000000 EPC7 0x00000000 DEPC 0x00000000
[ 336.761999] sof-audio sof-audio: EPS2 0x00060720 EPS3 0x00060720 EPS4 0x00000000 EPS5 0x00060520
[ 336.762007] sof-audio sof-audio: EPS6 0x00000000 EPS7 0x00000000 INTENABL 0x000101d8 INTERRU 0x00000222
[ 336.762090] sof-audio sof-audio: stack dump from 0xbe07fee0
[ 336.762125] sof-audio sof-audio: 0xbe07fee0: 0xbe014732 0x00000000 0x00000020 0x00000000
[ 336.762139] sof-audio sof-audio: 0xbe07fee4: 0x00060520 0x00000000 0x00060534 0x00000000
[ 336.762153] sof-audio sof-audio: 0xbe07fee8: 0x0000000d 0x00000000 0xbe0237d9 0xbe0237df
[ 336.762190] sof-audio sof-audio: 0xbe07feec: 0x00000000 0x00000000 0xbe0468c4 0x00000000
[ 336.762248] sof-audio sof-audio: 0xbe07fef0: 0xbe01743e 0x00000000 0xbe0237d9 0x00000000
[ 336.762267] sof-audio sof-audio: 0xbe07fef4: 0xbe012cb0 0x00000000 0x00060520 0x00000000
[ 336.762288] sof-audio sof-audio: 0xbe07fef8: 0xe0040000 0x00000000 0x00000000 0x00000000
[ 336.762307] sof-audio sof-audio: 0xbe07fefc: 0xbe011385 0x00000000 0x00000000 0x00000000
[ 336.762327] sof-audio sof-audio: error: waking up any trace sleepers

After the dsp panic happen, the headset still play out noise.
Suspect that we have problem with dai DMA or SSP.

[lgirdwood]

@xiulipan you have some memory dereference of 0x00060534 around the code at 0xbe014732, looks like it's crashed when running at level 1 (IPC idle level)

[xiulipan]

@lgirdwood this is very similar to issue #19 panic message.
How could you tell it

crashed when running at level 1 (IPC idle level)
I found that the PS is modified by our panic_rewind function and always disable all interrupts.

[lgirdwood]

@xiulipan it looks like level 5 actually, I misread PS. i.e level 1 -> 5 sequence and possibly the same corruption problem as #19. Have you managed to do any binary chop of code yet to find the issue ?

[xiulipan]

@lrgirdwood
I checked the xtensa manual and found that the PS is actually be changed by the panic_rewind function. In that function we disable all interrupt by setting the PS.INTLEVEL to 5 to disable all interrupt level below and equal 5.
asm volatile("rsil %0, 5" : "=a" (flags) :: "memory");
So I found it is hard to know which interrupt is coming as we got into panic.

Have you managed to do any binary chop of code yet to find the issue ?

Find that simple remove will make status error, will done that with more modification.

[tlauda]

@xiulipan
Capture xrun should be fixed on top of c65d733.

[keqiaozhang]

Verified with latest code base(sof-master: a2cfd8c), this issue still exists.

[keqiaozhang]

Confirmed that this issue is fixed by PR#178.