Revert "dma-trace: Preserve logs while dtrace is disabled" #5410
Conversation
This reverts commit 58ce6e6. This commit has caused the DMA trace to be frequently empty on a number of ADL and TGL in daily runs for two days in a row (test runs 10429 and 10459). The DMA trace could be completely empty in the past but that was on different platforms and a very long time ago, this had been fixed in bug thesofproject#4333 and had not happened for many months. The _only_ commit difference between the last successful test run (10402) and the first failing one (10459) is this commit. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
marc-hb
force-pushed
the
revert-trace-preserve
branch
from
369fd10 to
dd9d8f9
Compare
|
https://sof-ci.01.org/sofpr/PR5410/build12119/devicetest/?model=APL_UP2_NOCODEC_ZEPHYR&testcase=multiple-pipeline-all is ipc timeout known issue Not sure why https://sof-ci.01.org/sofpr/PR5410/build12119/devicetest/?model=BDW_WSB_RT286&testcase=check-alsabat-headset-playback failed with Everything else passed. https://sof-ci.01.org/sofpr/PR5410/build12120/devicetest/?model=APL_UP2_NOCODEC_ZEPHYR&testcase=test-speaker is known issue #5352 Everything else passed. |
I have randomly clicked on results in them and by luck I only saw test reports where there is slogger data. 10429 is PASS, 10459 FAILED. and 10459 does not have slogger. I have looked back to try to see what happened in the past when the same test on the same device failed, but I yet to find any.
If the issue has not been seen for many months then what #5329 fixed? It was merged two weeks ago.
It is hard to argue against test results... Now, in sof-dev we can not do this. The dtrace is disabled when before the DSP powers off (we send the IPC) and the only explanation for this is that time to time for some reason the DSP does not power off, retains the local buffer and we overwrite the old banner in there -> sof-logger will not find it anymore. ADLP_RVP_NOCODEC:check-sof-logger.sh is pretty consistent on not having dtrace data and this is what dmesg has to say: The read/write pointer got reset when we sent DMA_FREE and the dtrace got re-enabled with DMA_PARAMS_EXT. I really like to keep my commit, let's see if #5416 works, but if not then I bow before the proof and I need to revisit the issue again to unblock the dtrace client support. |
|
Can one of the admins verify this patch? |
|
@marc-hb, just to point out that the dtrace is still empty randomly with this revert in. Based on my analysis in #5416, that reverted patch had 0 effect on the probability of missing dtrace log. |
|
Indeed, it's still empty in https://sof-ci.01.org/softestpr/PR873/build1001/devicetest/?model=ADLP_RVP_NOCODEC&testcase=check-sof-logger
Sorry about that. I gave the git evidence above showing that this commit was the only change when the probability suddenly jumped from 0% to 10% but it seems we live in a "post-truth" world... :-( I haven't had time to look at your analysis, sorry again. |
I would have came to the same conclusion, likely. |
4 participants
This reverts commit 58ce6e6.
This commit has caused the DMA trace to be frequently empty on a number
of ADL and TGL in daily runs for two days in a row (test runs 10429 and
10459).
The DMA trace could be completely empty in the past but that was on
different platforms and a very long time ago, this had been fixed in
bug #4333 and had not happened for many months.
The only commit difference between the last successful test
run (10402) and the first failing one (10459) is this commit.
Signed-off-by: Marc Herbert marc.herbert@intel.com