-
Notifications
You must be signed in to change notification settings - Fork 324
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
[RFC] clarify firmware errors and warnnings #2678
Comments
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. |
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? |
close for the issue is not valid anymore |
Tests check for neither errors not warnings... anything goes. thesofproject/sof-test#799 |
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 text was updated successfully, but these errors were encountered: