-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible missed trace logs at the beginning #3448
Comments
I haven't look at this in detail yet but the description already rings a few bells:
This is just from the top of my head, sorry about the unrelated ones. |
On Intel platforms the copy to host buffer can only work after the Now the dtrace in firmware uses sync dma copy, so this should be fine. But on architectures where the DMA is not split like it is with HDA, this could cause ignored updates. @dbaluta, in sof-dev we now have three states for the dtrace: enum sof_dtrace_state {
SOF_DTRACE_DISABLED,
SOF_DTRACE_STOPPED,
SOF_DTRACE_ENABLED,
}; I think we could try to change the logic that we switch from DISABLED to STOPPED before sending the PARAMS_EXT and we only ignore the position update notification if the state is DISABLED. |
I added this wait for D3 in commit 6a8871f ("check-sof-logger: reload drivers first") that made the test more deterministic but I'm not 100% sure why it's now waiting for D3. Probably to minimize changes because before the addition of reload_drivers() the DSP was most likely in D3. While I recently made cavstool compatible with D3, the protocol used by cavstool is still different from the other traces: it won't print ANY log while the DSP is off. So change the test behavior to grab logs immediately after reloading the drivers / rebooting the DSP. This may also help with thesofproject/sof#4333, thesofproject/linux#3448 and others linked from there. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
I added this wait for D3 in commit 6a8871f ("check-sof-logger: reload drivers first") that made the test more deterministic but I'm not 100% sure why it's now waiting for D3. Probably to minimize changes because before the addition of reload_drivers() the DSP was most likely in D3. While I recently made cavstool compatible with D3, the protocol used by cavstool is still different from the other traces: it won't print ANY log while the DSP is off. So change the test behavior to grab logs immediately after reloading the drivers / rebooting the DSP. This may also help with thesofproject/sof#4333, thesofproject/linux#3448 and others linked from there. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
I added this wait for D3 in commit 6a8871f ("check-sof-logger: reload drivers first") that made the test more deterministic but I'm not 100% sure why it's now waiting for D3. Probably to minimize changes because before the addition of reload_drivers() the DSP was most likely in D3. While I recently made cavstool compatible with D3, the protocol used by cavstool is still different from the other traces: it won't print ANY log while the DSP is off. So change the test behavior to grab logs immediately after reloading the drivers / rebooting the DSP. This may also help with thesofproject/sof#4333, thesofproject/linux#3448 and others linked from there. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Looking at the code in
snd_sof_init_trace_ipc
we have:Then at
snd_sof_trace_update_pos
we have:It is possible that the reply for SOF_IPC_TRACE_DMA_PARAMS_EXT to arrive at the marker
<<<HERE>>
so,snd_sof_trace_update_pos
will miss the DMA trace position update becausedtrace_is_enabled
is set too late.This happens all the time on i.MX with the result that we cannot see the DMA trace boot logs until later when some other log messages are generated.
Is this a known issue on other platforms?
Cc: @marc-hb
The text was updated successfully, but these errors were encountered: