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

xtimer: set now pointer correctly in _update_short_timers() loop [backport 2020.04] #13854

Conversation

miri64
Copy link
Member

@miri64 miri64 commented Apr 11, 2020

Backport of #13850

Contribution description

This fixes xtimer to use xtimer_now64() instead of xtimer_now() for updating the *now variable during the iteration in _update_short_timers() function. The same function is used to initialize *now in _timer_callback() below.

While using xtimer_now() in this iteration step does not hinder the proper execution of all timers in the short term timers (for those the xtimer module only looks at the start_time member, not the long_start_time member) at least for the current long term time window (I did not test higher cases), it sets the long_start_time member to 0 for all timers following in the list of timers after this iteration step. However, external modules that rely on this to be correct, e.g. evtimer, fail their calculations when trying to compare to the current value to xtimer_now64().

If the changed header becomes the new head this behavior won't show up, as it is overwritten once the update of all headers is done. However, all timers later in the list will now have the wrong values.

Testing procedure

A regression test testing this behavior is provided. Confirm the bug, by reverting the fix and running it, run it with the patch to confirm that it fixes the bug:

export BOARD="<knock yourself out>"
make -C tests/xtimer_now32_overflow flash test

Issues/PRs references

None, but should fix a known, but not reported issue, where RPL starts "spamming" DIS every minute instead of every 5 minutes after >71min.

This fixes `xtimer` to use `xtimer_now64()` instead of `xtimer_now()`
for updating the `*now` variable during the iteration in
`_update_short_timers()` function. The same function is used to
initialize `*now` in `_timer_callback()` below.

While using `xtimer_now()` in this iteration step does not hinder the
proper execution of all timers in the short term timers (for those the
`xtimer` module only looks at the `start_time` member, not the
`long_start_time` member) at least for the current long term time window
(I did not test higher cases), it sets the `long_start_time` member to 0
for all timers following in the list of timers after this iteration
step. However, external modules that rely on this to be correct,
e.g. evtimer [1], fail their calculations when trying to compare to
the current value to `xtimer_now64()`.

[1] https:/RIOT-OS/RIOT/blob/11f3d68/sys/evtimer/evtimer.c#L118-L121

Co-Authored-By: Cenk Gündoğan <[email protected]>
(cherry picked from commit 212fe15)
Co-Authored-By: Julian Holzwarth <[email protected]>
(cherry picked from commit 4aa4a17)
(cherry picked from commit 085c62e)
@miri64 miri64 added Area: timers Area: timer subsystems CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Process: release backport Integration Process: The PR is a release backport of a change previously provided to master Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors) labels Apr 11, 2020
Copy link
Contributor

@kaspar030 kaspar030 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK.

@kaspar030 kaspar030 merged commit ed180f2 into RIOT-OS:2020.04-branch Apr 14, 2020
@leandrolanzieri leandrolanzieri added this to the Release 2020.04 milestone Apr 14, 2020
@miri64 miri64 deleted the backport/2020.04/xtimer/fix/now32-overflow branch April 14, 2020 07:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: timers Area: timer subsystems CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Process: release backport Integration Process: The PR is a release backport of a change previously provided to master Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants