Repository navigation
can't get any FW error logs once dsp is powered off #724
Description
once we power off the Audio DSP (tplg load failed or DSP panic or any other causes that will lead to powering off audio dsp cores), we can't get any error logs from sof-logger, this make debugging to this kind of firmware issues(e.g. ipc time out) very difficult, we need to fix this issue ASAP.
[ 56.330869] sof-audio-pci 0000:00:0e.0: error : DSP panic!
[ 56.330875] sof-audio-pci 0000:00:0e.0: panic: dsp_oops_offset 788480 offset 788480
[ 56.330887] sof-audio-pci 0000:00:0e.0: status: fw entered - code 00000005
root@test-apl:~# sof-logger -l sof-apl.ldc
CORE LEVEL COMP_ID TIMESTAMP DELTA FILE_NAME CONTENT
root@test-apl:~#
Activity
[-][regression] can't get any FW trace once dsp panic happened.[/-][+][regression] can't get any FW trace logs once dsp panic happened.[/+]keyonjie commentedon Mar 15, 2019
I believe we have the same issue with topic/sof-dev branch, @ranj063 can you take a look?
ranj063 commentedon Mar 15, 2019
@keyonjie is this really a regression? If I remember correctly @dabekjakub confirmed that he can read the exception debugfs entry in case of a panic
xiulipan commentedon Mar 15, 2019
@ranj063
checked and try to reproduce a lot failing cases in CI. Let me give some explanation here and later I will a fix for it and have some test later.
kconfig for
ENABLE_DEBUGFS_CACHEis set.Otherwise we can only get more error in demsg
Situation here:
etrace is empty as expected.
trace have logs
etrace is empty, because
hda_dsp_core_reset_power_downis called to power memory bank off. memory window is un-readabletrace is also empty, because of DSP is powered off, no more update can be done to host.
etrace should have some logs with part of dma traces.
not sure if the cache handled the memory window cache read rightly.
trace have some old logs
@ranj063 could you share the PR that
hda_dsp_core_reset_power_downis enabled for fail cases?I can see about 5-6 times it is calls when I got some tplg failed.
I need to check why the power off is done so quick in some fail cases.
ranj063 commentedon Mar 15, 2019
@xiulipan DSP is powered off is when topology widgets are unloaded which would be the case when a topology loading error occurs.
ranj063 commentedon Mar 15, 2019
This patch takes care of unloading the component when tplg loading fails.
[-][regression] can't get any FW trace logs once dsp panic happened.[/-][+]can't get any FW error logs once dsp is powered off[/+]keyonjie commentedon Apr 30, 2019
mark it to P1 as it blocks debugging for critical FW issue.
RanderWang commentedon May 8, 2019
I tested on two different Whiskylake today based on latest kernel and FW, and found there is no such issue now. @keyonjie what is your platform ?
RanderWang commentedon May 10, 2019
I reproduced it in a corner case. It should be fixed by #888
plbossart commentedon Jan 9, 2020
@keyonjie this has been filed 10 months ago, can we close, and what's the status if not?
keyonjie commentedon Jan 9, 2020
@plbossart I believe the issue still exist, and nobody has been working on it for this recent half year.
keyonjie commentedon Jan 9, 2020
It should not be P1 as it is not so critical to anybody, I think it is only an enhancement now.
lgirdwood commentedon Jan 9, 2020
@keyonjie we have a kconfig option now to prevent D3 entry on FW crash. i.e. all memories are preserved.
plbossart commentedon May 27, 2020
@keyonjie is this still relevant.
plbossart commentedon Jun 10, 2021
ping @keyonjie, we need to either close issues or provide updates/status.
keyonjie commentedon Jun 11, 2021
looks the issue is not existed anymore, let me close it.
bpf, selftests: Add verifier test case for jmp32's jeq/jne
ext4: fix slab-use-after-free in ext4_split_extent_at()