-
Notifications
You must be signed in to change notification settings - Fork 133
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
[BUG] delayed mtrace collection #4618
Comments
Thanks @aiChaoSONG good catch. mtrace-reader.py is stopped and restarted between each test and redirected to a new log file every time. So at first sight this does not look like a bug in sof-test but an issue in the logging system itself. An unsolved mtrace flushing issue was mentioned in: @kv2019i, @plbossart , @lyakh , @RanderWang any insight? |
@marc-hb The timestamp is generated by Zephyr OS. If the DSP is not powered off between test cases, the timestamp will continue and will not be reset to zero. So this is expected behaviour. |
I suspect there is one/many of following happening:
|
It should not be the case, because this is also see in PASSED test case, just check any test case in our daily test.
This is possible, the test interval between test case is 5 seconds, and in the kernel, the time for DSP to enter D3 is also 5s, let me try to make the test interval bigger. |
I think having the latter always longer than the former is a good idea in CI. It should not be enforced on personal devices though :-) |
I have made the test case interval 10 seconds, which is far enough for DSP to enter D3, however, I still see the issue. check the internal report with ID:28982. |
This sounds like a https://github.com/thesofproject/linux issue
This sounds like a https://github.com/thesofproject/sof issue Either way this is not a sof-test issue. Transferring in 5..., 4..., 3... |
Maybe because of |
Some mtrace in the test case are expanded to next test case, this is spotted in daily test.
for example, in internal daily test 28474, on any test config(model), the timestamp in mtrace for check-playback-all-formats.sh test case is started from 0, but for its next test case (check-capture-all-formats.sh), the timestamp is the continuation of the previous test case, which is unexpected.
This issue is also found in PR tests.
End of mtrace for check-playback-all-formats.sh on MTLP_RVP_SDW
Start of mtrace for check-capture-all-formats.sh on MTLP_RVP_SDW
cc:
The text was updated successfully, but these errors were encountered: