Uploaded image for project: 'rcX - Operating System'
  1. rcX - Operating System
  2. RCX-718

Kernel Timer Tick wrap-around (after ~49days) causes timers to get corrupted and not execute at all (single shot) or execute faster than expected (reload timers)

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: V2.1.1.0, V2.1.2.0, V2.1.3.0, V2.1.4.0, V2.1.5.0, V2.1.6.0, V2.1.7.0, V2.1.8.0, V2.1.9.0
    • Component/s: Kernel
    • Labels:
      None
    • Account:
      SDO rcX (SDORCX)

      Description

      During kernel tick wrap-around the timer task processes the upcoming ~500 kernel ticks ahead of time. The number of kernel ticks which are processed illlegally, depends on the overall system load, number of registered timers and on the runtime source media (netX51@INTRAM ~ 500 ticks). The effect on the registered timers highly depends on its type (auto-reload or single-shot timer).

      Auto-Reload-Timer:
      In case of kernel tick wrap-around the callback of an auto-reload-timer is called repeatedly (500 times on netX51@INTRAM) without any reference to the kernel tick for a maximum of one kernel tick period. I.e. the timer task processes expired timers ahead of time (at kernel tick time 0) and much faster than expected, followed by a short period without any timer activity. After that period an auto-reload-timer returns to normal operation. Application timers created with TlrTimerApplicationCreate are also affected - during wrap-around condition the destination queue of the TlrTimer may gets temporarily flooded!

      Single-Shot-Timers:
      The callback of an one-shot-timer is not be called at all if the timer is created or restarted within the first ~500 ticks after the kernel tick wrap-around and the expected expiration time is also within that first ~500 ticks. As the first ~500 ticks are processed ahead of time, timers which should expire within the first 500 ticks are already processed at kernel tick time zero. In general timers with a short period (<500 Ticks) have the higher potential to get lost (i.e. never gets called). In worst case scenario a single shot timer is only restarted on expiration of the same timer (i.e. the timer restarts itself). In this case the wrap-around issue will lead to the critical situation that the timer won't be restarted anymore. Application timers created with TlrTimerApplicationCreate are also affected and might not be invoked, as well.

        Attachments

          Issue Links

            Expenses

              Activity

                Status Description

                  People

                  • Reporter:
                    stephans stephans
                  • Votes:
                    0 Vote for this issue
                    Watchers:
                    0 Start watching this issue

                    Dates

                    • Created:
                      Updated:
                      Resolved: