Skip to content
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

tests/kernel/sched/deadline fails on NRF5x boards #9843

Closed
spoorthik opened this issue Sep 7, 2018 · 8 comments
Closed

tests/kernel/sched/deadline fails on NRF5x boards #9843

spoorthik opened this issue Sep 7, 2018 · 8 comments
Assignees
Labels
area: ARM ARM (32-bit) Architecture bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug

Comments

@spoorthik
Copy link
Contributor

Commit: 02aa980

Execution log:

 ***** delaying boot 1000ms (per build configuration) *****
***** Booting Zephyr OS 1.13.0-rc2 (delayed boot 1000ms) *****
Running test suite suite_deadline
===================================================================
starting test - test_deadline

    Assertion failed at /zephyr.git/tests/kernel/sched/deadline/src/main.c:70: test_deadline: (n_exec == 0 is false)
threads ran too soon
FAIL - test_deadline
===================================================================
===================================================================

PROJECT EXECUTION FAILED

Platforms tested: nrf52840_pca10056:arm, nrf52_pca10040:arm, nrf51_pca10028:arm

@spoorthik spoorthik added bug The issue is a bug, or the PR is fixing a bug area: ARM ARM (32-bit) Architecture labels Sep 7, 2018
@nashif nashif added the priority: low Low impact/importance bug label Sep 7, 2018
@andyross
Copy link
Contributor

andyross commented Sep 7, 2018

Always NRFx... It's true that I underconstrained the scheduler setup -- maybe the main thread is already at the lowest priority on those boards?

@nashif
Copy link
Member

nashif commented Sep 7, 2018

CONFIG_BT=n and it works...
Something in the BT stack interferes with the test, suggest to add CONFIG_BT=n to the prj.conf

@andyross
Copy link
Contributor

andyross commented Sep 7, 2018

That's a good catch. Yeah, there are threads and priority selection done in the context of the BT and network layers, if it pushes the main thread to the bottom that could do it. If it doesn't, though, nothing should really "interfere" with the scheduling here. Agree with that for an immediate fix, but I should dig a little before closing this.

andyross pushed a commit to andyross/zephyr that referenced this issue Sep 7, 2018
The BT threads are interfering with the main thread priority selection
and the test fails semi-spuriously on NRF5x boards with "threads ran
too soon" (i.e. not an EDF failure per se, but the fact that the new
threads at K_LOWEST_APPLICATION_PRIO are running instead of the test
thread).  This is a reasonable workaround for testing the
SCHED_DEADLINE ordering behavior, though.

Fixes zephyrproject-rtos#9843

Signed-off-by: Andy Ross <[email protected]>
@andyross
Copy link
Contributor

andyross commented Sep 7, 2018

Suggested fix submitted, but please don't close until I can figure out why this is happening (strictly: it's not a problem with the EDF feature, the detected case is that the threads are running before the test's main entry point has blocked, which shouldn't happen). A quick look at the generated .config doesn't show anything obviously wrong.

nashif pushed a commit that referenced this issue Sep 8, 2018
The BT threads are interfering with the main thread priority selection
and the test fails semi-spuriously on NRF5x boards with "threads ran
too soon" (i.e. not an EDF failure per se, but the fact that the new
threads at K_LOWEST_APPLICATION_PRIO are running instead of the test
thread).  This is a reasonable workaround for testing the
SCHED_DEADLINE ordering behavior, though.

Fixes #9843

Signed-off-by: Andy Ross <[email protected]>
@nashif nashif reopened this Sep 9, 2018
Josh0027 pushed a commit to Josh0027/zephyr that referenced this issue Sep 10, 2018
The BT threads are interfering with the main thread priority selection
and the test fails semi-spuriously on NRF5x boards with "threads ran
too soon" (i.e. not an EDF failure per se, but the fact that the new
threads at K_LOWEST_APPLICATION_PRIO are running instead of the test
thread).  This is a reasonable workaround for testing the
SCHED_DEADLINE ordering behavior, though.

Fixes zephyrproject-rtos#9843

Signed-off-by: Andy Ross <[email protected]>
@pizi-nordic
Copy link
Collaborator

@carlescufi, @cvinayak: The #9745 might be source of this problem.

@carlescufi
Copy link
Member

@nashif @andyross as per @pizi-nordic suggestion, this might be caused by the fix we posted for the 1.13 release which fixes some tests, but makes others fail. The only clean solution is to follow-up on #9904.

@andyross
Copy link
Contributor

Should be fixed now. Can't reproduce on nrf52840_pca10056 post-timer-rewrite.

@andyross
Copy link
Contributor

andyross commented Mar 1, 2019

Hasn't reappeared. Must be fixed. Closing.

@andyross andyross closed this as completed Mar 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: ARM ARM (32-bit) Architecture bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug
Projects
None yet
Development

No branches or pull requests

5 participants