-
Notifications
You must be signed in to change notification settings - Fork 2k
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/periph_timer_timeout0: Regression test for timer callbacks setting new timers #10019
base: master
Are you sure you want to change the base?
Conversation
a974b23
to
0dc18fd
Compare
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions. |
This is useful just needs some review time. |
I rebased and reran but it seems like some things are not so happy |
0dc18fd
to
6cdf4c9
Compare
Rebased and moved in the new test folder. Test passed on my nrf52dk. |
Murdock results❌ FAILED 8f00189 tests: Integrate zero timeout test into timer test
Test failures (1)
Artifacts |
The newly introduced tests fails on the samr21-xpro. I think the timer on that board might have a bug. |
I have that board at hands. I do like the test, but I dislike that it creates a new app rather than extending the existing Consolidating the number of apps a bit reduces CI time and increase the life of boards used for testing by reducing the number of flash cycles per full test run. |
@maribu like this? (And still fails on the samr21xpro) |
There have been some recent CI failures for the tests/sys/shell. I think that is related as the failure occurs on the samr21-xpro when compiled using LLVM inside a periodic timer test. E.g. see this.
|
…ing new timers This test is designed to catch an implementation bug where a timer callback is called directly from inside timer_set if the given timeout=0, leading to a stack overflow if timer_set is called from within the callback of the same timer. The bug is present on the current revision of the Kinetis LPTMR periph driver. A bug fix is provided in a separate commit.
23de238
to
8f00189
Compare
@@ -207,6 +239,53 @@ static int test_timer(unsigned num, uint32_t timer_freq) | |||
return 1; | |||
} | |||
|
|||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
timer_set(ctx->dev, chan, 20000u); | ||
timer_set(ctx->dev, chan, 0); | ||
} | ||
mutex_unlock(&ctx->mtx); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can someone explain to me the purpose of the mutex? It is locked in test_timer_timeout
and unlocked in the timer callback?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a common pattern in RIOT for a thread to wait for an IRQ. Unlike a POSIX mutex, a RIOT mutex can be unlocked from a different context (and even from IRQ context).
The idea is that locking an already locked mutex will block. Unlocking that mutex from the ISR will unblock the thread.
/* Wait until we have executed the zero timeout callback enough times */ | ||
while (ctx.counter < TEST_ITERATIONS) { | ||
mutex_lock(&ctx.mtx); | ||
++switches; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
switches
is unused from here on?
Contribution description
This test is designed to catch an implementation bug where a timer
callback is called directly from inside timer_set if the given
timeout=0, leading to a stack overflow if timer_set is called from
within the callback of the same timer.
The bug is present on the current revision of the Kinetis LPTMR periph
driver. A bug fix is provided in #10020.
Testing procedure
build and flash tests/periph_timer_timeout0, run
make test
Issues/PRs references
#10020 for the bug fix