ehl_crb: tests/kernel/timer/timer_api/timer_api/test_sleep_abs (kernel.timer.tickless) failed.

[chen-png]

To Reproduce
Steps to reproduce the behavior:

1. west build -b ehl_crb -p auto tests/kernel/timer/timer_api -DCONF_FILE="prj_tickless.conf"
2. copy binary to USB/PXE boot media
3. boot
4. See error

Logs and console output

*** Booting Zephyr OS build zephyr-v2.5.0-652-g767ba47423fd  ***
Running test suite timer_api
===================================================================
START - test_time_conversions
PASS - test_time_conversions
===================================================================
START - test_timer_duration_period
PASS - test_timer_duration_period
===================================================================
START - test_timer_restart
PASS - test_timer_restart
===================================================================
START - test_timer_period_0
PASS - test_timer_period_0
===================================================================
START - test_timer_expirefn_null
PASS - test_timer_expirefn_null
===================================================================
START - test_timer_periodicity
PASS - test_timer_periodicity
===================================================================
START - test_timer_status_get
PASS - test_timer_status_get
===================================================================
START - test_timer_status_get_anytime
PASS - test_timer_status_get_anytime
===================================================================
START - test_timer_status_sync
PASS - test_timer_status_sync
===================================================================
START - test_timer_k_define
PASS - test_timer_k_define
===================================================================
START - test_timer_user_data
PASS - test_timer_user_data
===================================================================
START - test_timer_remaining
PASS - test_timer_remaining
===================================================================
START - test_timeout_abs
PASS - test_timeout_abs
===================================================================
START - test_sleep_abs
Assertion failed at WEST_TOPDIR/zephyr/tests/kernel/timer/timer_api/src/main.c:750: test_sleep_abs: (late >= 0 && late < k_us_to_ticks_ceil32(100) is false)
expected wakeup at 33208, got 33209 (late 1)
FAIL - test_sleep_abs
===================================================================
Test suite timer_api failed.
===================================================================
PROJECT EXECUTION FAILED

Environment (please complete the following information):

• OS: Linux
• Toolchain: zephyr-sdk-0.12.2
• Commit ID: 767ba47

[PerMac]

@pabigot Does this relate to #32339 ?
Edit: I see another issue for this test suite:
timer.tickless.timeout_abs fails on nrf9160 (worked well for v2.5.0). Should I raise a separate bug for this test case or is it the same issue?

START - test_timeout_abs
Assertion failed at WEST_TOPDIR/zephyr/tests/kernel/timer/timer_api/src/main.c:723: test_timeout_abs: (t0 + rem_ticks == exp_ticks is false)
Wrong remaining: now 122955 rem 327557046 expires 327680000 (1)
FAIL - test_timeout_abs

[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.

[PerMac]

play whack-a-mole

I never liked that game... 😦

[nashif]

I created that as a bug in hopes that we could avoid wasting so much time on this test.

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

[andyross]

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

[enjiamai]

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:
zephyr: gitlab mainline commit: 23f699b (*** Booting Zephyr OS build zephyr-v2.5.0-484-g23f699bd907f ***)
zephyr-intel: gitlab mainline commit: 22c6331

[enjiamai]

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:
zephyr: gitlab mainline commit: 23f699b (*** Booting Zephyr OS build zephyr-v2.5.0-484-g23f699bd907f ***)
zephyr-intel: gitlab mainline commit: 22c6331

Excuse me, their failure test case was different, so I file another issue for this:
#32877

[nashif]

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.

[enjiamai]

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?

[galak]

@andyross any updates?

[yerabolu]

Can not reproduce this failure anymore on EHL_CRB or ACRN. Confirmed it with @enjiamai as well on ACRN. So closing this out.