mps2_an385:tests/kernel/tickless/tickless_concept/kernel.tickless.concept fail

[wentongwu]

*** Booting Zephyr OS build zephyr-v2.1.0-580-gb0a8461a873a  ***
Running test suite tickless_concept
===================================================================
starting test - test_tickless_sysclock
time 10, 220
time 230, 430
PASS - test_tickless_sysclock
===================================================================
starting test - test_tickless_slice
elapsed slice 110, expected: <100, 110>
elapsed slice 120, expected: <100, 110>

    Assertion failed at ZEPHYR_BASE/tests/kernel/tickless/tickless_concept/src/main.c:59: thread_tslice: t <= SLICE_SIZE_LIMIT is false

elapsed slice 0, expected: <100, 110>

    Assertion failed at ZEPHYR_BASE/tests/kernel/tickless/tickless_concept/src/main.c:57: thread_tslice: t >= SLICE_SIZE is false

elapsed slice 0, expected: <100, 110>

    Assertion failed at ZEPHYR_BASE/tests/kernel/tickless/tickless_concept/src/main.c:57: thread_tslice: t >= SLICE_SIZE is false

FAIL - test_tickless_slice
===================================================================
Test suite tickless_concept failed.
===================================================================
PROJECT EXECUTION FAILED

[galak]

Is this failure on hardware or QEMU?

[jhedberg]

Where did you see the issue? In CI?

[wentongwu]

Is this failure on hardware or QEMU?

QEMU

[wentongwu]

Where did you see the issue? In CI?

yes, in CI

[stephanosio]

This happens when the host CPU usage is very high (e.g. when running sanitycheck).

Re-running the test should make it pass (it is an intermittent failure caused by processing delay).

[stephanosio]

cc @nashif

[stephanosio]

Where did you see the issue? In CI?

I have seen this failure a number of times in the CI. Simply re-running the failing block in the Shippable will resolve this.

Maybe we should consider increasing the retry count for this test.

[erwango]

@jhedberg Can we increase the priority ? Frequency of the failure is non negligible

[jhedberg]

@jhedberg Can we increase the priority ? Frequency of the failure is non negligible

@erwango do you know who might be able to take ownership of this issue (i.e. have it assigned to them)? We can change the priority, but without an assignee I'm afraid it will not make much difference.

[erwango]

@erwango do you know who might be able to take ownership of this issue

@jhedberg, if there is not board owner then maybe the subsystem owner ?

[erwango]

@karl-zh since you're familiar with mps2 boards, can you have a look to this issue (it is annoying since poping up often in shippable reports)?

[andrewboie]

@wentongwu you have already been looking into the timing related issues with QEMU targets

why did you open this bug? why do you think this is unrelated to the QEMU timing issues we have been aware of for a long time now?

@jhedberg Can we increase the priority ? Frequency of the failure is non negligible

@erwango this is not being seen on real hardware

This almost certainly an instance of #14173 unless someone has evidence to the contrary

[wentongwu]

@andrewboie Yes I'm looking at it, just surprised we have already enabled icount on mps2_an385 with "-icount auto" which I don't think is correct. I will close this issue and continue #14173 if got big slot. Thanks

[erwango]

@wentongwu why closing the issue if still present ?
I meet this failure about twice a day in failling shippable reports.
That's might not be an implementation issue, maybe this test should not be run, but I don't think thre is really nothing to do here.