Repository navigation
could not access debugfs when DSP panic or IPC failed #233
Description
When DSP panic or IPC failed. If we use sof-logger or rmbox we will see
sof-audio sof-audio: error: debugFS failed to resume -13
In dmesg.
Or if we want to access any debugfs exculde trace, the dmesg shows same thing and terminal refuse to open the file
sudo cat /sys/kernel/debug/sof/etrace
cat: /sys/kernel/debug/sof/etrace: Permission denied
Analysis:
trace and etrace used different read ops
For trace we used sof_dfsentry_read
static const struct file_operations sof_dfs_fops = {
.open = sof_dfsentry_open,
.read = sof_dfsentry_read,
.llseek = default_llseek,
};And the above dmesg is coming from
Line 64 in 2af9599
So the guess is here, when DSP panic or IPC failed, how would our pm_runtime_get_sync pm_runtime_put behavior?
We may need some fallback handler for this case.
The debugfs is very valuable and critical for our debug when error happens. But now it could not work.
Activity
xiulipan commentedon Oct 31, 2018
@libinyang
Could you share the workaround to get etrace on UP2?
mengdonglin commentedon Oct 31, 2018
@ranj063 This issue is observed when debugging thesofproject/sof#443 on UP2. But it should be a generic issue.
keyonjie commentedon Oct 31, 2018
when DSP is panic, we should let reading trace debugFS entries(with old value at worst case) possible, let me try some fix to it.
ranj063 commentedon Oct 31, 2018
@Keyon agree with you. Let me know if you need help
mengdonglin commentedon Nov 1, 2018
@keyonjie please check if thesofproject/sof#518 could improve the logger health for your debugging.
xiulipan commentedon Nov 1, 2018
@keyonjie @ranj063
What about tplg load fail?
This will also make resume fail, right?
So we may also want the debugfs can be read or just disable pm when error happen.
keyonjie commentedon Nov 1, 2018
@xiulipan why tplg load fail? we will not destroy the entry, so it should be still readable when resume fails.
xiulipan commentedon Nov 1, 2018
@keyonjie
The resume fail will return error code to kernel. Thought you have copy the data to the right place, the error code will forbidden the normal read or open.
#237 is the workaround we are using now.
I will close this issues when #237 is merged.
markyang commentedon Nov 13, 2018
Summary:
This issue can be reproduced on MinnowBoard when DSP panic.
dmesg:
Test steps:
sudo sof-logger-2cd668c -l sof-apl.ldc-master-gcc-73475e3f
CORE LEVEL COMP_ID TIMESTAMP DELTA FILE_NAME CONTENT
sudo sof-logger-2cd668c -l sof-apl.ldc-master-gcc-73475e3f -t
CORE LEVEL COMP_ID TIMESTAMP DELTA FILE_NAME CONTENT
Test env:
sof master: 73475e3
sof tool: 2cd668c
kernel sof-dev: 165b34d
tplg: sof-byt-rt5651.tplg-2cd668c
Log:
dmesg-byt.log
plbossart commentedon Nov 13, 2018
@ranj063 does pm_runtime work on MinnowBoard? If not, maybe we should remove this capability for now to unlock such blocking issues?
plbossart commentedon Nov 14, 2018
Can we check if #237 fixes this issue?
Also can I get clarity on MinnowBoard support for pm_runtime, the issue above mentions debugFS failing to resume so things are not clear to me...
tracing: Do not allow mmap() of persistent ring buffer
drm/amd/display: Fix slab-use-after-free in hdcp
selftests/bpf: Add mprog API tests for BPF tcx links
selftests/bpf: Add selftest for allow_ptr_leaks
drm/amd/display: Fix slab-use-after-free in hdcp