[BUG] DSP Panic on Intel MTL #9695
Comments
|
As usual, @as400l: In case the log is truncated because of a small log buffer, please add |
|
Here is dmesg with the error and sof-dyndbg.conf enabled. BTW - isn't it strange that it uses sof-hda-generic-2ch.tplg file ? @lgirdwood - I tried with alsamixer but can't reproduce it. But, on the other hand, with alsamixer I can't unmute the mic. I have this LED on keyboard and no matter what I tried with alsamixer it's just constantly on. Which means that the mic was not unmuted. |
|
@as400l, for some reason the dyndbg did not enabled the debug prints, we don't see what was the last message that was sent to the firmware, we know that the next would have been 0xe010002|0x0, which is not sent as the firmware has crashed. sof-hda-generic-2ch.tplg is chosen, because you have DMIC in your system you also have BT offload advertised: I'm not sure if that can cause any issues. You can disable the dmic for testing the analog path (you will loose the laptop microphones) : in for example /etc/modprobe.d/no-dmic.conf |
|
I tried multiple times with "wpctl set-mute @DEFAULT_AUDIO_SOURCE@ toggle". But could not reproduce this behaviour. So maybe the real cause of this is actually XE drm module crash or hang related to pavucontrol ? Which may be seen at the end of dmesg I've sent ? Is this even possible ? As to the debug prints. My kernel may is really slimmed down. So that may be the reason. May have to try with default distro kernel. |
Ok, its strange that alsamixer wont unmute the mic, I assume you tried Btw, is the keyboard LED on a key ? i.e. can it be pressed with Fn/Alt/Ctrl/shift combinations to switch LED on/off ? This should be mapped to the kcontrol that will mute/unmute the mic. Please do try the stock kernel. We need to figure out what has happened here with stock kernel logs. |
|
@lgirdwood - as I mentioned above - I tried with "wpctl" and it correctly mutes/unmutes microphone. LED goes off/on as it should. But I could not reproduce this error. I'm leaning towards something else causing this panic. Stock Alpine kernel was also not helpful since it's probably also stripped. |
|
I compiled a kernel with DYNAMIC_DEBUG and here are logs with the error. I had to try to trigger it mutliple times as this time it wasn't so eager to panic. |
|
Based on the log I think it is the ChainDMA (HDMI audio) which is causing the firmware panic: 0xe030001 is ChainDMA with ALLOCATE and ENABLE bit set, but what is not right is that the Host DMA ID is 1 while the Link DMA ID is 0. There are lots of things happening in the log, but looks like something (PW?) is trying PCMs at random keeping them open and stopping, starting, reconfiguring them. |
|
@ujfalusi - just to remind - this happens only while using pavucontrol which is actually PulseAudio tool. |
|
OK, so to reproduce the issue: Press < wait a sec or two then start a new HDMI playback (while the :0,3 is frozen): |
|
Reverting That patch was part of thesofproject/linux#5197, which was fixing various metallic noise issues around similar sequences. The issue is not limited to ChainDMA or will cause fw panic: On LNL sdw it is the same with all endpoints: Only the ChainDMA PCMs will cause panic, others will fail. @ranj063, I think it might be because we release the LinkDMA channel in sof/intel/ but we don't inform the firmware about this (we don't do a full stop) and this is causing a race if a new PCM comes in between the stop and the prepare/hw_params/start of the other PCM. |
…IPC4 We need to reclaim the link DMA channel after clearing it with IPC4 as the pipelines are not cleared in firmware, the Link DMA channel is preserved. This issue is not easy to reproduce under normal conditions as usually after stop the stream is closed, or the same stream is restarted, but if another stream got in between the stop and start, like this: aplay -Dhw:0,3 -c2 -r48000 -fS32_LE /dev/zero -d 120 CTRL+z aplay -Dhw:0,0 -c2 -r48000 -fS32_LE /dev/zero -d 120 then the link DMA channels will be mixed up resulting firmware error or crash. Fixes: ab55937 ("ASoC: SOF: Intel: hda: Always clean up link DMA during stop") Closes: thesofproject/sof#9695 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
…IPC4 We need to reclaim the link DMA channel after clearing it with IPC4 as the pipelines are not cleared in firmware, the Link DMA channel is preserved. This issue is not easy to reproduce under normal conditions as usually after stop the stream is closed, or the same stream is restarted, but if another stream got in between the stop and start, like this: aplay -Dhw:0,3 -c2 -r48000 -fS32_LE /dev/zero -d 120 CTRL+z aplay -Dhw:0,0 -c2 -r48000 -fS32_LE /dev/zero -d 120 then the link DMA channels will be mixed up resulting firmware error or crash. Fixes: ab55937 ("ASoC: SOF: Intel: hda: Always clean up link DMA during stop") Closes: thesofproject/sof#9695 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
|
@ranj063, @as400l, this patch fixes the issue for me: thesofproject/linux#5267 |
|
@abonislawski fyi - for FW panic, it probably worth checking if this panic is due to HW state transition (fixed above in SW) and if it needs a FW fix too. Thanks ! |
We need to reclaim the link DMA channel after clearing it with IPC4 as the pipelines are not cleared in firmware, the Link DMA channel is preserved. This issue is not easy to reproduce under normal conditions as usually after stop the stream is closed, or the same stream is restarted, but if another stream got in between the stop and start, like this: aplay -Dhw:0,3 -c2 -r48000 -fS32_LE /dev/zero -d 120 CTRL+z aplay -Dhw:0,0 -c2 -r48000 -fS32_LE /dev/zero -d 120 then the link DMA channels will be mixed up resulting firmware error or crash. Fixes: ab55937 ("ASoC: SOF: Intel: hda: Always clean up link DMA during stop") Closes: thesofproject/sof#9695 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
We need to reclaim the link DMA channel after clearing it with IPC4 as the pipelines are not cleared in firmware, the Link DMA channel is preserved. This issue is not easy to reproduce under normal conditions as usually after stop the stream is closed, or the same stream is restarted, but if another stream got in between the stop and start, like this: aplay -Dhw:0,3 -c2 -r48000 -fS32_LE /dev/zero -d 120 CTRL+z aplay -Dhw:0,0 -c2 -r48000 -fS32_LE /dev/zero -d 120 then the link DMA channels will be mixed up resulting firmware error or crash. Fixes: ab55937 ("ASoC: SOF: Intel: hda: Always clean up link DMA during stop") Closes: thesofproject/sof#9695 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
We need to reclaim the link DMA channel after clearing it with IPC4 as the pipelines are not cleared in firmware, the Link DMA channel is preserved. This issue is not easy to reproduce under normal conditions as usually after stop the stream is closed, or the same stream is restarted, but if another stream got in between the stop and start, like this: aplay -Dhw:0,3 -c2 -r48000 -fS32_LE /dev/zero -d 120 CTRL+z aplay -Dhw:0,0 -c2 -r48000 -fS32_LE /dev/zero -d 120 then the link DMA channels will be mixed up resulting firmware error or crash. Fixes: ab55937 ("ASoC: SOF: Intel: hda: Always clean up link DMA during stop") Closes: thesofproject/sof#9695 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
The linkDMA should not be released on stop trigger since a stream re-start might happen without closing of the stream. This leaves a short time for other streams to 'steal' the linkDMA since it has been released. This issue is not easy to reproduce under normal conditions as usually after stop the stream is closed, or the same stream is restarted, but if another stream got in between the stop and start, like this: aplay -Dhw:0,3 -c2 -r48000 -fS32_LE /dev/zero -d 120 CTRL+z aplay -Dhw:0,0 -c2 -r48000 -fS32_LE /dev/zero -d 120 then the link DMA channels will be mixed up, resulting firmware error or crash. Fixes: ab55937 ("ASoC: SOF: Intel: hda: Always clean up link DMA during stop") Closes: thesofproject/sof#9695 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Describe the bug
DSP Panic seen and full freeze of the OS.
To Reproduce
Open pavucontrol mute/unmute microphone few times. Close pavucontrol. Wait for freeze.
Reproduction Rate
100%
Expected behavior
No DSP Panic.
Impact
Cannot use builtin microphone.
Environment
Screenshots or console output
Full dmesg in attachment.
dmesg.txt
The text was updated successfully, but these errors were encountered: