-
Notifications
You must be signed in to change notification settings - Fork 6.7k
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
Comments
Always NRFx... It's true that I underconstrained the scheduler setup -- maybe the main thread is already at the lowest priority on those boards? |
CONFIG_BT=n and it works... |
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. |
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]>
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. |
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]>
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]>
@carlescufi, @cvinayak: The #9745 might be source of this problem. |
@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. |
Should be fixed now. Can't reproduce on nrf52840_pca10056 post-timer-rewrite. |
Hasn't reappeared. Must be fixed. Closing. |
Commit: 02aa980
Execution log:
Platforms tested: nrf52840_pca10056:arm, nrf52_pca10040:arm, nrf51_pca10028:arm
The text was updated successfully, but these errors were encountered: