Skip to content
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

Closed
aiChaoSONG opened this issue Apr 1, 2020 · 6 comments
Closed

[RFC] clarify firmware errors and warnnings #2678

aiChaoSONG opened this issue Apr 1, 2020 · 6 comments
Labels
enhancement New feature or request

Comments

@aiChaoSONG
Copy link
Collaborator

aiChaoSONG commented Apr 1, 2020

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?

@aiChaoSONG aiChaoSONG added the bug Something isn't working as expected label Apr 1, 2020
@aiChaoSONG
Copy link
Collaborator Author

aiChaoSONG commented Apr 1, 2020

@paulstelian97
Copy link
Collaborator

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
Copy link

mmaka1 commented 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
Copy link
Collaborator

marc-hb commented Apr 1, 2020

No error should be whitelisted imo.

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?

@slawblauciak slawblauciak added enhancement New feature or request and removed bug Something isn't working as expected labels Aug 10, 2020
@aiChaoSONG
Copy link
Collaborator Author

close for the issue is not valid anymore

@marc-hb
Copy link
Collaborator

marc-hb commented Jan 24, 2022

Tests check for neither errors not warnings... anything goes. thesofproject/sof-test#799

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants