You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@xiulipan you see probably traces cached before logger-run, it's because filtering rejects messages in FW, so messages sent before setting up filters are just shown.
@ktrzcinx I just copy paste the log from the trace debug IPC, so I think the following logs should all follow the filter right?
Could you provide a way for us to test the filter feature? We would like to add a test case for this in sof-test.
PS: could you help to provide a PR to fix the \n parse? I do not think my hack is a good solution.
We would like to add a test case for this in sof-test.
Great idea.
Could you provide a way for us to test the filter feature?
There are two main aspects
optarg parsing - -F option argument has a quite wide possible range of input (1. single component instance 2. single component type 3. single pipeline 4. single component type on pipeline 5. every component)
Check if feature works as a whole
After setting up filters we will expect to receive only traces corresponding to used setup. If something won't be clear just let me know.
PS: could you help to provide a PR to fix the \n parse? I do not think my hack is a good solution.
Activity
logger: fix opt for filter parameter
xiulipan commentedon Oct 19, 2020
Root cause to be
sof/tools/logger/logger.c
Line 164 in 8a5059a
It should be
static const char optstring[] = "ho:i:l:ps:c:u:tv:rd:Lf:gF:nxiulipan commentedon Oct 19, 2020
After the logger fix, still got error from dmesg:
xiulipan commentedon Oct 20, 2020
@ktrzcinx After add some debug logs and find the issue is caused by unhandled
"\n"After add some hack into the kernel it seems the ipc can be send now.
And I got some wired outptut in trace:
ubuntu@sh-apl-up2-pcm512x-03:~/pxl$ sudo ./sof-logger -l /etc/sof/sof-apl.ldc -t -Fc=* -Fi=ipc,pipeI try to filter all error message and only allow ipc and pipe logs, but it seems there are more logs came. Any idea? @ktrzcinx
ktrzcinx commentedon Oct 20, 2020
@xiulipan you see probably traces cached before logger-run, it's because filtering rejects messages in FW, so messages sent before setting up filters are just shown.
xiulipan commentedon Oct 20, 2020
@ktrzcinx I just copy paste the log from the trace debug IPC, so I think the following logs should all follow the filter right?
Could you provide a way for us to test the filter feature? We would like to add a test case for this in sof-test.
PS: could you help to provide a PR to fix the
\nparse? I do not think my hack is a good solution.logger: fix opt for filter parameter
ktrzcinx commentedon Oct 20, 2020
Yes, I've added extra explanation in thesofproject/sof-docs#299
Great idea.
There are two main aspects
-Foption argument has a quite wide possible range of input (1. single component instance 2. single component type 3. single pipeline 4. single component type on pipeline 5. every component)After setting up filters we will expect to receive only traces corresponding to used setup. If something won't be clear just let me know.
Ok, I will do this.
xiulipan commentedon Oct 21, 2020
@ktrzcinx New discussion issue for logger filter test case is thesofproject/sof-test#457
logger: fix opt for filter parameter
logger: fix opt for filter parameter