Skip to content

GitLab

Switch branch/tag
  1. 17 Sep, 2018 3 commits
  3. 06 Sep, 2018 4 commits
    • Jan Kiszka's avatar
      Add CONTRIBUTING guide and workflow explanation · 1b5b1156
      Jan Kiszka authored 
      

Shall both help new comers to understand in which form patches are
requested and what will happen to them normally after submitting them.
Signed-off-by: Jan Kiszka's avatarJan Kiszka <jan.kiszka@siemens.com>
      1b5b1156
    • Jan Kiszka's avatar
      cobalt/posix/signal: Fix return code on siginfo copy errors · 09b207f9
      Jan Kiszka authored 
      

The put_siginfo functions return a non-zero value on error. We have to
convert that into proper -EFAULT before returning.
Signed-off-by: Jan Kiszka's avatarJan Kiszka <jan.kiszka@siemens.com>
      09b207f9
    • Philippe Gerum's avatar
      cobalt/sched: improve watchdog accuracy · f5a67a24
      Philippe Gerum authored and Jan Kiszka's avatar Jan Kiszka committed 
      

The original watchdog mechanism was based on a sampling method: every
second (built-in value), it used to check the runtime mode of the
current task preempted on the ticking CPU. A per-cpu counter was
increased by one every time rt/primary mode was detected, then checked
against the trigger limit (CONFIG_XENO_OPT_WATCHDOG_TIMEOUT).
Otherwise, the counter was reset to zero.

With this fairly naive approach, it only takes a single hit with
CONFIG_XENO_OPT_WATCHDOG_TIMEOUT=1 to trigger the watchdog, i.e. if
the system-fixed 1s watchdog tick preempts any Xenomai task when it is
running in primary mode on the current CPU, the watchdog fires.

The default value of 4s papered over the inherent imprecision of such
a coarse-grained method, lengthening the odds of observing false
positive triggers.

To improve the accuracy of the watchdog, arm the watchdog timer to
fire at the final trigger date directly, right before switching the
CPU to primary mode (leave_root()), disarming it when the CPU is about
to switch back to secondary mode (enter_root()).

Better accuracy comes at the expense of slightly more overhead when
transitioning between primary and secondary modes, which should be
acceptable for a debug feature which is not affecting the hot path
anyway (i.e. there is no added cost for strictly rt context switches).
Signed-off-by: Philippe Gerum's avatarPhilippe Gerum <rpm@xenomai.org>
Signed-off-by: Jan Kiszka's avatarJan Kiszka <jan.kiszka@siemens.com>
      f5a67a24
    • Philippe Gerum's avatar
      cobalt/intr: drop last #if XENO_DEBUG() conditional · b4cd0f72
      Philippe Gerum authored and Jan Kiszka's avatar Jan Kiszka committed 
      
Signed-off-by: Philippe Gerum's avatarPhilippe Gerum <rpm@xenomai.org>
Signed-off-by: Jan Kiszka's avatarJan Kiszka <jan.kiszka@siemens.com>
      b4cd0f72
  5. 04 Sep, 2018 1 commit
  7. 03 Sep, 2018 6 commits
  9. 31 Aug, 2018 2 commits
    • Philippe Gerum's avatar
      drivers/autotune: fix computation of gravity limit · 553881db
      Philippe Gerum authored 
      A wrongly computed gravity limit value caused the calibration to end
too early on some platforms (e.g. arm64).

This value should be the max. among the set of min. latencies observed
while running the warmup steps. In the same move, run more warmup
steps to increase the likeliness of reaching such max.
      553881db
    • Philippe Gerum's avatar
      drivers/autotune: fix calibration with low frequency timers · 262cdf25
      Philippe Gerum authored 
      When a single timer tick last less than the adjustment step time
(i.e. < 500 ns), we end up with a zero adjustment value which either
leads to a spurious early shot detection due to a rounding error, or a
null gravity value at the end of a lengthy but useless calibration
process.

Make sure to adjust by at least one timer tick, and mitigate rounding
errors when checking for early shots when the timer frequency is lower
than 1e9 / ADJUSTMENT_STEP.
      262cdf25
  11. 28 Aug, 2018 1 commit
    • Philippe Gerum's avatar
      cobalt/arm64: calibrate: prevent excessive delay of next host tick · abd64d98
      Philippe Gerum authored 
      The calibration procedure overwrites the current value of the timer
counter for a pending oneshot tick event, which is admittedly ok in
the context of initializing Cobalt. However, the previous
implementation maxed the counter value, potentially causing excessive
delay to the host waiting for the overwritten timer event.

Use a shorter delay value when calibrating so that the next shot does
not occur later than one jiffy after we left the calibration
routine. One jiffy is also long enough for preventing the timer to
ever fire while running the calibration loop.
      abd64d98
  13. 25 Aug, 2018 1 commit
  15. 22 Aug, 2018 1 commit
    • Philippe Gerum's avatar
      cobalt/arm: calibrate: prevent excessive delay of next host tick · 630f0a33
      Philippe Gerum authored 
      The calibration procedure overwrites the current value of the timer
counter for a pending oneshot tick event, which is admittedly ok in
the context of initializing Cobalt. However, the previous
implementation maxed the counter value, potentially causing excessive
delay to the host waiting for the overwritten timer event.

Use a shorter delay value when calibrating so that the next shot does
not occur later than one jiffy after we left the calibration
routine. One jiffy is also long enough for preventing the timer to
ever fire while running the calibration loop.
      630f0a33
  17. 20 Aug, 2018 1 commit
  19. 01 Aug, 2018 6 commits
  21. 14 Jul, 2018 1 commit
  23. 03 Jul, 2018 13 commits

Imprint & Privacy Policy