On Mon, 2018-05-28 at 10:54 +0800, Pan, Xiuli wrote:
On 5/27/2018 00:26, Ranjani Sridharan wrote:
On Sat, 2018-05-26 at 10:16 +0100, Liam Girdwood wrote:
On Fri, 2018-05-25 at 21:02 -0700, Ranjani Sridharan wrote:
While trying to send an IPC message to configure the DMIC params, I forgot to add the message size in the in the IPC header. The FW ran into an exception and seemed like it was stuck in an infinite loop.
Is there way to exit gracefully in such cases? The dmesg log (partial)is shown below.
The driver will eventually reboot the FW when a FW exception occurs.
But it doesnt seem to be happening in this case? The dmesg log overflows with the same FW exception message over and over again.
The driver will not reset the DSP when PANIC happen now. Should we add this to reset the DSP? Actually the PANIC info will dump in two situation:
- Panic happen will send a IPC message to driver and we will handle
that 2. When timeout happen, we will also try to dump PANIC info
So for your situation, the panic happen for the first time, but the driver had no idea that the DSP is panic and continue send IPCs to DSP. These IPCs all timeout and had these panic infos. I think you get a very complex topology?
The topology is quite simple in fact. I've got a passthrough topology with a DMIC DAI instead of SSP.
I'm guessing we should be able to reproduce my problem with any ipc message if you remove the line where we set the size of the ipc message. I'll look into debugging this.
Thanks Xiuli
Liam _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmw are
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmwar e