[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 <[email protected]>
…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 <[email protected]>
|
@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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Liam Girdwood <[email protected]> Reviewed-by: Bard Liao <[email protected]>
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") Cc: [email protected] Closes: thesofproject/sof#9695 Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Liam Girdwood <[email protected]> Reviewed-by: Bard Liao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
commit e8d0ba1 upstream. 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") Cc: [email protected] Closes: thesofproject/sof#9695 Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Liam Girdwood <[email protected]> Reviewed-by: Bard Liao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit e8d0ba1 upstream. 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") Cc: [email protected] Closes: thesofproject/sof#9695 Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Liam Girdwood <[email protected]> Reviewed-by: Bard Liao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit e8d0ba1 upstream. 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") Cc: [email protected] Closes: thesofproject/sof#9695 Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Liam Girdwood <[email protected]> Reviewed-by: Bard Liao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
I also had this bug on my Lenovo X1 Carbon gen 12 with Build in Audio (Meteor Lake-P HD) I could reproduce this by start-stopping the Audio-Test in WebEx-settings multiple times after each other I Installed the experimental kernel 6.13.0-0.rc4.36.fc42.x86_64 (hoping this work was already merged), but unfortunately this didn't fix the problem. Thanks! |
commit e8d0ba1 upstream. 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") Cc: [email protected] Closes: thesofproject/sof#9695 Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Liam Girdwood <[email protected]> Reviewed-by: Bard Liao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit e8d0ba1 upstream. 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") Cc: [email protected] Closes: thesofproject/sof#9695 Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Liam Girdwood <[email protected]> Reviewed-by: Bard Liao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
@lvanderree, 6.13-rc4 should include the patch and should be working (6.12.8 will also have the backport). I wonder what are we missing... Let me test 6.13-rc5 here. |
6.13-rc5 is working fine and indeed the patch is first available in -rc5, -rc4 should still fail (confirmed: it fails), @lvanderree, can you re-test with -rc5 if you have time to confirm that you no longer need to do git merges to get things working? |
commit e8d0ba1 upstream. 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") Cc: [email protected] Closes: thesofproject/sof#9695 Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Liam Girdwood <[email protected]> Reviewed-by: Bard Liao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
Unfortunately I immediately was able to reproduce an audio problem with WebEx under kernel 6.13.0-0.rc5.42.fc42.x86_64
Besides that I didn't have any audio when setting output over HDMI (1). Spotify would play over the Internal speakers, but when switching to HDMI(1) I couldn't hear anything anymore. Switching back to Internal and music was back. However after rebooting again with my custom kernel 6.13.0-rc3-sof I could reproduce both problems (crashing audio when testing with WebEx, and no audio over HDMI1 until sleep/wake-up), I don' t know why I didn't had this problem 3 days ago, but now I can reproduce this broken-pipe errors and missing audio over hdmi(1) until awake-from-sleep every time. with both kernels. I found out about the WebEx issue, because the audio disappeared when haveing WebEx-calls after some minutes. Then after some testing in the WebEx-settings, when tailing journalctl I saw the DSP Panic. I usually have my WebEx calls audio over the internal build in speakers and Microphone of my X1 gen12 (something that works out fine on my previous X1 Yoga gen3). And music I play over my HDMI-out.
If there is anything else I can do to provide more insights please say so (and maybe point me in the right direction how to get this info). Or if this is not directly related to the original DSP Panic, and release DMA solution, but I should open a new ticket I can do that as well. |
|
I am also experiencing this issue. Also on a 12th Gen X1 Carbon. If you need someone else to test--please let me know. |
|
@carlinigraphy, also triggered by WebEx? |
|
@lvanderree, can you clarify these:
When the audio broke, can it be resurrected by stopping all audio activities and letting PA/PW to close the PCM devices? |
|
@lvanderree, @carlinigraphy, please follow #9695 (comment) and provide raw dmesg log without filtering which contains the events around the time the issue happens, but as long as possible to see the prior events. If you don't see the DSP panic with 6.13-rc5 / 6.12.8 / sof-dev kernel then please open a new issue to track this, thank you. |
When I play music (Spotify) and then start/stop/start/stop/start... the audio-test in WebEx I can break alle audio. I let Spotify continue playing, but close the (already stopped test) WebEx settings-window, letting WebEx itself continu to run, and the music starts playing again. So in short , I don't even have to close all audio activity to restore audio. Only closing the Web-Ex streams seem to be enough. I haven' t had time to reboot with the sof-dyndbg.conf.txt config, but I can do that in a new ticket, which probably is more suitable than continue in this thread. Some debug results:When I've closed both Spotify and WebEx no PCM streams are opened: for pcm in /proc/asound/card*/pcm*; do echo ${pcm}; cat ${pcm}/sub0/status; done
/proc/asound/card0/pcm0c
closed
/proc/asound/card0/pcm0p
closed
/proc/asound/card0/pcm31p
closed
/proc/asound/card0/pcm3p
closed
/proc/asound/card0/pcm4p
closed
/proc/asound/card0/pcm5p
closed
/proc/asound/card0/pcm6c
closedand after starting both (Spotify and WebEx), but not starting sound yet, the PCM streams remain closed. Then when playing only in Spotify over the internal speaker I see: for pcm in /proc/asound/card*/pcm*; do echo ${pcm}; cat ${pcm}/sub0/status; done
/proc/asound/card0/pcm0c
closed
/proc/asound/card0/pcm0p
state: RUNNING
owner_pid : 3530
trigger_time: 10541.693975450
tstamp : 10576.476283753
delay : 3702
avail : 29280
avail_max : 32304
-----
hw_ptr : 1669728
appl_ptr : 1673216
/proc/asound/card0/pcm31p
closed
/proc/asound/card0/pcm3p
closed
/proc/asound/card0/pcm4p
closed
/proc/asound/card0/pcm5p
closed
/proc/asound/card0/pcm6c
closedThen opening the Audio-settings in WebEx, while Spofity remains playing, but without starting tests I see: for pcm in /proc/asound/card*/pcm*; do echo ${pcm}; cat ${pcm}/sub0/status; done
/proc/asound/card0/pcm0c
closed
/proc/asound/card0/pcm0p
state: RUNNING
owner_pid : 3530
trigger_time: 10693.413010349
tstamp : 10740.771640427
delay : 374
avail : 32608
avail_max : 32736
-----
hw_ptr : 2273376
appl_ptr : 2273536
/proc/asound/card0/pcm31p
closed
/proc/asound/card0/pcm3p
closed
/proc/asound/card0/pcm4p
closed
/proc/asound/card0/pcm5p
closed
/proc/asound/card0/pcm6c
state: RUNNING
owner_pid : 3530
trigger_time: 10738.352621064
tstamp : 10740.775385002
delay : 2305843009213578122
avail : 540
avail_max : 572
-----
hw_ptr : 116252
appl_ptr : 115712
So an additional stream have started. I guess that is the microphone being read Then I start/stop/start/stop/.... the WebEx audio test, unit audio completely breaks, and the result is: for pcm in /proc/asound/card*/pcm*; do echo ${pcm}; cat ${pcm}/sub0/status; done
/proc/asound/card0/pcm0c
closed
/proc/asound/card0/pcm0p
state: RUNNING
owner_pid : 3530
trigger_time: 10864.060850351
tstamp : 10864.060873695
delay : 0
avail : 32832
avail_max : 32832
-----
hw_ptr : 192
appl_ptr : 128
/proc/asound/card0/pcm31p
closed
/proc/asound/card0/pcm3p
closed
/proc/asound/card0/pcm4p
closed
/proc/asound/card0/pcm5p
closed
/proc/asound/card0/pcm6c
state: RUNNING
owner_pid : 3530
trigger_time: 10862.674775343
tstamp : 10864.068168377
delay : 2305843009213658112
avail : 31020
avail_max : 31292
-----
hw_ptr : 66860
appl_ptr : 35840with this in journalctl: When I keep the windows like this, and rerun the cat of Then closing the audio-settings screen in WebEx, restores the audio, letting the music from Spotify hear again. /proc/asound/card0/pcm0p
state: RUNNING
owner_pid : 3530
trigger_time: 11043.459009206
tstamp : 11154.669993750
delay : 3267
avail : 29728
avail_max : 30752
-----
hw_ptr : 5338272
appl_ptr : 5341312What I also noticed is that when playing Spotify over HDMI, I see that it uses for pcm in /proc/asound/card*/pcm*; do echo ${pcm}; cat ${pcm}/sub0/status; done
/proc/asound/card0/pcm0c
closed
/proc/asound/card0/pcm0p
closed
/proc/asound/card0/pcm31p
closed
/proc/asound/card0/pcm3p
state: RUNNING
owner_pid : 3530
trigger_time: 11249.070593003
tstamp : 11273.013007550
delay : 3540
avail : 29228
avail_max : 30956
-----
hw_ptr : 1149484
appl_ptr : 1153024
/proc/asound/card0/pcm4p
closed
/proc/asound/card0/pcm5p
closed
/proc/asound/card0/pcm6c
closedand when I then open the WebEx audio settings, it opens again on for pcm in /proc/asound/card*/pcm*; do echo ${pcm}; cat ${pcm}/sub0/status; done
/proc/asound/card0/pcm0c
closed
/proc/asound/card0/pcm0p
state: RUNNING
owner_pid : 3530
trigger_time: 11331.773588943
tstamp : 11334.647066680
delay : 470
avail : 32544
avail_max : 32704
-----
hw_ptr : 138144
appl_ptr : 138368
/proc/asound/card0/pcm31p
closed
/proc/asound/card0/pcm3p
state: RUNNING
owner_pid : 3530
trigger_time: 11249.070593003
tstamp : 11334.649165490
delay : 2332
avail : 30436
avail_max : 30748
-----
hw_ptr : 4108004
appl_ptr : 4110336
/proc/asound/card0/pcm4p
closed
/proc/asound/card0/pcm5p
closed
/proc/asound/card0/pcm6c
state: RUNNING
owner_pid : 3530
trigger_time: 11331.706623783
tstamp : 11334.651337670
delay : 2305843009213552988
avail : 508
avail_max : 604
-----
hw_ptr : 141308
appl_ptr : 140800BUT when I then start/stop the tests, to break the audio, The webex audio will mute, but the Spotify audio over HDMI will start stuttering. for pcm in /proc/asound/card*/pcm*; do echo ${pcm}; cat ${pcm}/sub0/status; done
/proc/asound/card0/pcm0c
closed
/proc/asound/card0/pcm0p
state: RUNNING
owner_pid : 3530
trigger_time: 11473.847726298
tstamp : 11473.847742545
delay : 0
avail : 32832
avail_max : 32832
-----
hw_ptr : 192
appl_ptr : 128
/proc/asound/card0/pcm31p
closed
/proc/asound/card0/pcm3p
state: RUNNING
owner_pid : 3530
trigger_time: 11472.809807060
tstamp : 11473.851675325
delay : 936
avail : 31832
avail_max : 31832
-----
hw_ptr : 50264
appl_ptr : 51200
/proc/asound/card0/pcm4p
closed
/proc/asound/card0/pcm5p
closed
/proc/asound/card0/pcm6c
state: RUNNING
owner_pid : 3530
trigger_time: 11472.750559634
tstamp : 11473.853639429
delay : 2305843009213662768
avail : 21660
avail_max : 22028
-----
hw_ptr : 52892
appl_ptr : 31232And it keeps on stuttering, even while /proc/asound/card0/pcm0c
closed
/proc/asound/card0/pcm0p
state: SETUP
owner_pid : 3530
trigger_time: 11610.694379598
tstamp : 11610.700505371
delay : 0
avail : 32832
avail_max : 0
-----
hw_ptr : 192
appl_ptr : 128
/proc/asound/card0/pcm31p
closed
/proc/asound/card0/pcm3p
state: RUNNING
owner_pid : 3530
trigger_time: 11609.675993003
tstamp : 11610.702031185
delay : 1660
avail : 31108
avail_max : 31828
-----
hw_ptr : 49540
appl_ptr : 51200
/proc/asound/card0/pcm4p
closed
/proc/asound/card0/pcm5p
closed
/proc/asound/card0/pcm6c
state: RUNNING
owner_pid : 3530
trigger_time: 11609.634805019
tstamp : 11610.704091548
delay : 2305843009213663792
avail : 21100
avail_max : 21132
-----
hw_ptr : 51308
appl_ptr : 30208until I close the Webex audio-settings window, and the audio recovers again wihtout stuttering: for pcm in /proc/asound/card*/pcm*; do echo ${pcm}; cat ${pcm}/sub0/status; done
/proc/asound/card0/pcm0c
closed
/proc/asound/card0/pcm0p
closed
/proc/asound/card0/pcm31p
closed
/proc/asound/card0/pcm3p
state: RUNNING
owner_pid : 3530
trigger_time: 11661.147549638
tstamp : 11665.175596114
delay : 2988
avail : 29780
avail_max : 32732
-----
hw_ptr : 193620
appl_ptr : 196608
/proc/asound/card0/pcm4p
closed
/proc/asound/card0/pcm5p
closed
/proc/asound/card0/pcm6c
closed |
|
@lvanderree, thank you for the details! I don't have WebEx account and it looks like that the configuration is account-walled. That is really surprising that WebEx using analog out+DMIC can break HDMI playback...
What is even more strange is that when you play audio to speaker and start WebEx (which will use the same PCM device) it will break. Unless WebEx takes over the audio somehow... |
|
OK, I can reproduce this with WebEx now, wow. |
|
For now WebEx was the only app I've experienced issues with. Good to hear you are able to install it as well, and can enjoy this wonderful product as well 🤞 The web app doesn't have a settings window, so I cannot test the settings via the web app. However I made a call via web to the native (linux) app and that did made my audio system crash (with broken pipes) again. But as soon as I ended the app-side my spotify sound restored again. So it definitely is some magic the app does. I can partly follow what you say and that indeed sounds surprising that they somehow interfere with PA/PW. Please let me know what else I can do, now you can test and see for yourself as well. |
|
I am not experiencing with WebEx. I can reproduce fairly consistently by just opening Please allow me some time, I'll try to follow the guide in the referenced comment and post the output. |
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") Cc: [email protected] Closes: thesofproject/sof#9695 Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Liam Girdwood <[email protected]> Reviewed-by: Bard Liao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
|
@lvanderree , @carlinigraphy , quick update: something odd is going on when pipewire is in use, we are still debugging what could be the reason. |
|
thank for the update @ujfalusi I did a sudo dnf swap --allowerasing pipewire-pulseaudio pulseaudio
systemctl --user stop pipewire.socket pipewire-pulse.service
pulseaudio -Dand eventually a reboot After that my audio did not came out my internal speakers, nor my HDMI (via USB-C). Then I played Spotify over HDMI, while testing WebEx settings and everything went on fine. So for now I can confirm the issue is related to PipreWire, and switch to Pulseaudio is a perfectly fine fix for me for the moment (better than the web-implementation of WebEx that I used today, which worked good with PipeWire). |
|
I've got the same freezes on my laptop: |
|
Changing to pulseaudio didn't help with the problem for me, I am still getting that errors and experience freezes |
|
@vanushwashere, I think your issue is different and unrelated but I cannot see what goes wrong. Please also attach the output of Thank you. |
|
It just spams that messages to log every millisecond :/ |
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") Cc: [email protected] Closes: thesofproject/sof#9695 Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Liam Girdwood <[email protected]> Reviewed-by: Bard Liao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
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") Cc: [email protected] Closes: thesofproject/sof#9695 Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Liam Girdwood <[email protected]> Reviewed-by: Bard Liao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
commit e8d0ba147d901022bcb69da8d8fd817f84e9f3ca upstream. 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") Cc: [email protected] Closes: thesofproject/sof#9695 Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Liam Girdwood <[email protected]> Reviewed-by: Bard Liao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
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: