Skip to content

[RFC] clarify firmware errors and warnnings #2678

Closed

Description

@aiChaoSONG

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?

Activity

  1. added
    bugSomething isn't working as expected
    on Apr 1, 2020
  2. aiChaoSONG commented on Apr 1, 2020

    @aiChaoSONG
    CollaboratorAuthor
  3. paulstelian97 commented on Apr 1, 2020

    @paulstelian97
    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.

  4. mmaka1 commented on Apr 1, 2020

    @mmaka1

    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.

  5. marc-hb commented on Apr 1, 2020

    @marc-hb
    Collaborator

    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?

  6. added
    enhancementNew feature or request
    and removed
    bugSomething isn't working as expected
    on Aug 10, 2020
  7. aiChaoSONG commented on Jan 24, 2022

    @aiChaoSONG
    CollaboratorAuthor

    close for the issue is not valid anymore

  8. marc-hb commented on Jan 24, 2022

    @marc-hb
    Collaborator

    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

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions