tests/kernel/timer/timer_api/test_timeout_abs fails on stm32 boards #32572
Comments
FRASTM
added
bug
|
The failure in details: |
|
This is failing on other boards: |
|
also fails on nxp platforms RT1xxx and RT600, but Ok in Kinetis(FRDM_K64f). @MaureenHelm |
The test_timeout_abs case had baked in similar mistakes to the off-by-one in the absolute timer implementation. FOR THE RECORD: If you have an absolute timeout expiration set for a tick value "N", and the current time returned by k_uptime_ticks() is "T", then the time returned (at the same moment) by any of the *_remaining_ticks() APIs must ALWAYS AND FOREVER BE EXACTLY "N - T" (also: "N - T > 0" always, until the moment the kernel ISR hands off control to the first timeout handler expiring at that tick). The tick math is exact. No slop is needed on any systems, no matter whether their clocks divide by milliseconds or not. The only gotcha is that we need to be sure that the calls don't interleave with a real time tick advance, which we do here with a simple retry loop. But, about slop... This patch also includes a related fix for the test_sleep_abs(). On an intel_adsp (which has 50 kHz ticks, a comparatively slow idle resume and interrupt entry, and even has two CPUs to mess with latency measurements) I would occasionally see the k_sleep() take more than a tick to wake up from the interrupt handler until the return to application code. Add some real time slop there (just 100us) to handle systems like this. Fixes zephyrproject-rtos#32572 Signed-off-by: Andy Ross <[email protected]>
|
Potential fix up at #32683 . There was indeed a bug in the test exposed by the recent absolute timeout fix on high tick rate systems (i.e. hardware, not CI). I caught it happening on the adsp I was working on, so I'm fairly confident this is the issue. If those with affected systems could test and report results, I'd be appreciative. Though I will note that the fact that all those systems are systick-based makes me a tiny bit worried there may be a driver bug in play too. |
The test_timeout_abs case had baked in similar mistakes to the off-by-one in the absolute timer implementation. FOR THE RECORD: If you have an absolute timeout expiration set for a tick value "N", and the current time returned by k_uptime_ticks() is "T", then the time returned (at the same moment) by any of the *_remaining_ticks() APIs must ALWAYS AND FOREVER BE EXACTLY "N - T" (also: "N - T > 0" always, until the moment the kernel ISR hands off control to the first timeout handler expiring at that tick). The tick math is exact. No slop is needed on any systems, no matter whether their clocks divide by milliseconds or not. The only gotcha is that we need to be sure that the calls don't interleave with a real time tick advance, which we do here with a simple retry loop. But, about slop... This patch also includes a related fix for the test_sleep_abs(). On an intel_adsp (which has 50 kHz ticks, a comparatively slow idle resume and interrupt entry, and even has two CPUs to mess with latency measurements) I would occasionally see the k_sleep() take more than a tick to wake up from the interrupt handler until the return to application code. Add some real time slop there (just 100us) to handle systems like this. Fixes #32572 Signed-off-by: Andy Ross <[email protected]>
@hakehuang can you verify the fix on RT1xxx and RT600? |
|
thanks @hakehuang ! |
Describe the bug
after The PR : kernel/timeout: Fix off-by-one in absolute timeouts #32505
the test fails on many stm32 boards
To Reproduce
Steps to reproduce the behavior:
Expected behavior
test passed
Environment (please complete the following information):
Additional context
reimplement tests/kernel/timer/timer_api #32339
The text was updated successfully, but these errors were encountered: