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
On CI, we have a test case to check firmware trace log, and grep "error" from the log. But sometimes, we see the key word "error" in the trace log, but the error is not actually a really error.
For example: ERROR validate(), ll drift detectec, data = 25549 and other block alloc errors.
We are not sure we should fail the test case or not. We can make a white list to ignore those "errors", but before that, we want to have a discussion with FW folks.
Maybe you guys can clarify errors and warnings, or give some white list to us?
The ll drift detected one should be transient, maybe a reason of concern but could happen when the load is high (multiple pipelines stress test). I think this one is fine to ignore for the most part (when the drift is too high you get a panic though)
Allocation errors may be considered errors, however there was a rejected proposal to mark certain allocations as not giving out an error (via usage of a flag) so that only the important errors in allocation can be considered as errors. I don't think this one should be ignored but instead check on a case by case basis.
No error should be whitelisted imo. Unexpected events that do not reduce any functionality as the system is able to recover should not be logged as errors. The latter is sth to stop, investigate and fix.
There is a PR (see link above) that addresses the agent message.
Thanks, I agree non-errors should not lie and pretend they are errors, this is confusing not just for validation but for everyone :-) I can think of one exception though: when testing error handling itself (the area that consistently has the least test coverage). In that particular case the tests are ideally smart enough to trap the logs?
Activity
aiChaoSONG commentedon Apr 1, 2020
@lgirdwood @tlauda @ktrzcinx @mmaka1 @bkokoszx @dbaluta @jajanusz @slawblauciak @wwittbrx @xiulipan @Bin-QA
paulstelian97 commentedon Apr 1, 2020
The ll drift detected one should be transient, maybe a reason of concern but could happen when the load is high (multiple pipelines stress test). I think this one is fine to ignore for the most part (when the drift is too high you get a panic though)
Allocation errors may be considered errors, however there was a rejected proposal to mark certain allocations as not giving out an error (via usage of a flag) so that only the important errors in allocation can be considered as errors. I don't think this one should be ignored but instead check on a case by case basis.
mmaka1 commentedon Apr 1, 2020
No error should be whitelisted imo. Unexpected events that do not reduce any functionality as the system is able to recover should not be logged as errors. The latter is sth to stop, investigate and fix.
There is a PR (see link above) that addresses the agent message.
marc-hb commentedon Apr 1, 2020
Thanks, I agree non-errors should not lie and pretend they are errors, this is confusing not just for validation but for everyone :-) I can think of one exception though: when testing error handling itself (the area that consistently has the least test coverage). In that particular case the tests are ideally smart enough to trap the logs?
aiChaoSONG commentedon Jan 24, 2022
close for the issue is not valid anymore
marc-hb commentedon Jan 24, 2022
Tests check for neither errors not warnings... anything goes. thesofproject/sof-test#799