Successive 46 times 4ch DMIC captures crashes firmware #487
Comments
|
Also witnessed a crash of the DSP via arecord on the V0.5 drop using 2ch on glk |
|
Excerpt of initial crash |
This panic happens on static uint64_t validate(void *data, uint64_t delay)
{
struct sa *sa = data;
uint64_t current;
uint64_t delta;
current = platform_timer_get(platform_timer);
delta = current - sa->last_idle;
/* were we last idle longer than timeout */
if (delta > sa->ticks) {
trace_sa("tim");
trace_sa_value(delta);
panic(SOF_IPC_PANIC_IDLE);
}
return PLATFORM_IDLE_TIME;
}
|
|
The crash does not happen if there's a "sleep 2" between captures. The suspend-resume cycle likely clears the issue in FW. I tried to disable the gain ramp code that I suspected but it didn't prevent the crash. I also read trough the alloc & free code in dmic.c but I could not spot any hazards. |
|
The errors trace looks like this after the crash has happened: The sequence that starts from the middle with "Cmd, SAl, Par" looks normal capture start until dai tsa. Normally there should be a dmic tri (trigger) but instead there's eM1. It's from rmalloc_sys() heap free test fail. |
|
@xiulipan @lgirdwood Work queue is on lower interrupt level than DMA (2 < 5). Agent doesn't take any additional threshold between the expected value and current idle difference, so I would expect there could be potential mismatch during data transfer. |
|
Hmm, SA should be scheduling work at highest level. i.e. 5 - Let me check this. Fwiw SA function should be rolled into scheduler logic in the future. |
|
@lgirdwood @singalsu The alloc.c eM1 failure may be a mem leak I recently found exercising pause/resume scenarios. The dai stops the dw-dma which enters COMP_STATE_PREPARE state (COMP_TRIGGER_PAUSE handler calls dma_stop(), not _pause()). Then when the dai is 'released', calls dw_dma_start() which being in 'prepare' registers the interrupt handlers and calls another alloc in the sys heap. After a while fw runs out of the sys heap. |
mengdonglin
added
bug
|
@singalsu patch now merged, can you retest. |
|
@keqiaozhang @mengdonglin @lgirdwood I'm no more getting this error, the capture loop is now past iteration 200 and still works OK! Thank you @mmaka1 !!! I'll close this issue. |
|
Closing. |
A loop of "arecord -Dhw:0,6 -c 4 -f S32_LE -r 48000 -t raw -d 1 capture.raw" done 46 times causes a crash.
The actual number of loops may vary depending on platform, topology, etc. but that's what I see currently in UP2 board (APL). I'll assign this to myself and provide more information to repeat this if I need help.
Need to check if this happens also with 2ch.
The text was updated successfully, but these errors were encountered: