-
Notifications
You must be signed in to change notification settings - Fork 6.9k
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
reel_board: tests/kernel/sched/schedule_api/ fails on multiple boards #29705
Comments
Fails on the mec15xxevb_assy6853 too. In multiq configuration and in standard without it. |
This is specific to Given that the previous sync waited for a "millisecond" boundary I'm wondering if the test has an implicit assumption that milliseconds can be precisely represented, which is not true on Nordic hardware. |
Was just pointed to this. Indeed, this test looks to me like it's doing ms math on its timeouts. |
What time you can expect to submit a PR? Do you need any help? |
Adjusting the tick alignment of this test caused it to start breaking on nRF5 platforms, which use a 32768 Hz clock that doesn't divide evenly into the millisecond precision used by the test. The "half slice" math ended up being wrong by a bit. Convert to ticks first before computing the cycle delay needed. Fixes zephyrproject-rtos#29705 Signed-off-by: Andy Ross <[email protected]>
Adjusting the tick alignment of this test caused it to start breaking on nRF5 platforms, which use a 32768 Hz clock that doesn't divide evenly into the millisecond precision used by the test. The "half slice" math ended up being wrong by a bit. Convert to ticks first before computing the cycle delay needed. Fixes zephyrproject-rtos#29705 Signed-off-by: Andy Ross <[email protected]>
On STM32 boards, I found that this test fails depending on clock frequency, |
Adjusting the tick alignment of this test caused it to start breaking on nRF5 platforms, which use a 32768 Hz clock that doesn't divide evenly into the millisecond precision used by the test. The "half slice" math ended up being wrong by a bit. Convert to ticks first before computing the cycle delay needed. Fixes zephyrproject-rtos#29705 Signed-off-by: Andy Ross <[email protected]>
Adjusting the tick alignment of this test caused it to start breaking on nRF5 platforms, which use a 32768 Hz clock that doesn't divide evenly into the millisecond precision used by the test. The "half slice" math ended up being wrong by a bit. Convert to ticks first before computing the cycle delay needed. Fixes #29705 Signed-off-by: Andy Ross <[email protected]>
EDIT: Affects multiple Nordic boards and mec15xxevb_assy6853
Describe the bug
Running tests/kernel/sched/schedule_api/ on reel board. Assertion in test_slice_reset failed in both kernel.scheduler and kernel.scheduler.multiq testcases.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Test should pass.
Impact
Test suite fails.
Logs and console output
Environment (please complete the following information):
The text was updated successfully, but these errors were encountered: