-
Notifications
You must be signed in to change notification settings - Fork 313
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"DSP panic" when ALSA XRUN recovery #19
Comments
Please detail the trace logs when this happens in both FW and driver. |
Please provide dmesg log from driver. |
@tlauda
|
@xiulipan |
@tlauda |
@tlauda |
[ 21.720926] sof-audio sof-audio: pcm: trigger stream 0 dir 0 cmd 0 after dicuss with @tlauda we find that the last stop send form the kernel maybe the trigger for the DSP panic. |
When this stop command is received in firmware, the firmware will try to stop the DMA in dai_comp_trigger(). i wonder why the second stop is coming. from the kernel code, we did not you have to pay attention to this log. Actually before the last stop comes, the firmware is already abnormally, based on the log. |
that is the point
We highly suspect that this stop is the trigger. Thanks for the hint, I will check the macro |
I suspect the last stop is coming for the second alsa xrun.
|
@xiulipan this issue does not happen with xcc? |
@jocelyn-li |
@zhigang-wu But with xcc we don't have panic. From what we've seen with @xiulipan, hang on xcc is due to the wrong state machine, after trying to stop the ppl during xrun recovery. I'm not sure how big are the default interrupt stacks in xtos and how they are handled with multiple irqs execution at once, but maybe the panic is due to tha stack overflow. Xrun recovery is done on some software interrupt level and the function itself is recursive. In the same time GPDMA and IPC interrupts are triggered. I think that we should have different handling mechanism for the xruns, which doesn't involve endless retriggering. |
@tlauda
we could make the case more simply: from the xiuli's log, there might be two alsa xrun happen. firmware's xrun recover process will stop each component in the pipeline first, then do prepare operation on each component in the pipeline, last it will schedule the pipeline start again. |
@zhigang-wu if you suspect infinite recursion, then put a limit on the call depth of this function. Does the problem go away or is different ? |
@lgirdwood |
@zhigang-wu I'm not proposing a solution, I'm asking a question about a potential problem you have raised and you never answered. Is this related to infinite recursion or not ? |
@lgirdwood |
There is an even easier way to reproduce the issue on Up^2: start one playback, hit Control-z to suspend the app, restart with fg. The timeout and panic errors are not recoverable without removing/reloading kernel modules. root@ubilinux4:~# speaker-test -Dhw:0,0 -c2 -r48000 -FS32_LE -t sine speaker-test 1.1.3 Playback device is hw:0,0 speaker-test 1.1.3 Playback device is hw:0,0 speaker-test 1.1.3 Playback device is hw:0,0 root@ubilinux4: |
Please verify with 4ba4aa8. |
@tlauda |
dmesg: [ 216.321335] sof-audio sof-audio: error : DSP panic! rmbox It seems we still get into dai xrun in capture start/stop pattern and need pipeline recovery, |
Test with DMIC capture and SSP playback on APL with DMIC test topology Still get panic when inject XRUN into capture [ 900.643956] sof-audio sof-audio: ipc: send 0x60040000 0x3c0 [887.325593] delta [3.172558] dai xro It seems this bug is non related to ssp driver. |
Confirmed that this issue is fixed in sof-master. |
When ALSA detect a xrun, a stop/start pattern for the recovery is send to firmware. This pattern is not supported now and will cause the DSP to have some error.
The text was updated successfully, but these errors were encountered: