-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
ehl_crb: tests/kernel/timer/timer_api/timer_api/test_sleep_abs (kernel.timer.tickless) failed. #32816
Comments
@pabigot Does this relate to #32339 ?
|
I created that as a bug in hopes that we could avoid wasting so much time on this test. But if the preferred path is to play whack-a-mole, there needs to be separate bugs as they come up. |
I never liked that game... 😦 |
what is blocking you now from re-implementing the test? The fact that it was changed from 'bug' to 'enhancement'? What difference does this make? if you filed a specific bug against the existing test that could be addressed in the current test, it is a bug. Re-implementation of something in my dictionary counts as enhancement because you are not addressing a single issue, you are enhancing the test overall. If you think this test needs to be re-implemented and it will fix all the issues, the label of the issue should not really block you from moving forward. If a bug label makes you more comfortable, be my guest and change it back... |
@pabigot The test case in question here is actually brand new, it contains no tick/ms math at all. I don't argue that this test deserves rework, I just don't see how that's going to help the issue in question. At the end of the day timing tests require tuning because (1) real time cannot be "locked", requiring careful initialization timing and slop and forgiveness in results (2) real systems have wildly different performance and tick rate behavior, which impacts those tolerances, and (3) we naturally want timing to be "precise", so have a built-in incentive to overtighten those values. And we reliably find systems where a combination of hardware, configuration, and occasional bugs bust the limits and show failures. A rewrite can fix some stuff (the tick/ms math in timer_api is indeed a big problem) but it can't fix the fundamentals. |
This issue also found in EHL ACRN platform and show the same log as ehl_crb bare metal, so I comment here instead of filing a new issue for it. And the issue happened starting from this version: |
Excuse me, their failure test case was different, so I file another issue for this: |
How is this different? This is failing in the same testcase. |
They failed in different case, ehl crb bare metal is falied on test_sleep_abs(), arcn ehl is failed test_timeout_abs(). But they are indeed belong to the same testsuite. Should I close the another one for better tracking it? |
@andyross any updates? |
Can not reproduce this failure anymore on EHL_CRB or ACRN. Confirmed it with @enjiamai as well on ACRN. So closing this out. |
To Reproduce
Steps to reproduce the behavior:
Logs and console output
Environment (please complete the following information):
The text was updated successfully, but these errors were encountered: