- 17 Oct, 2018 1 commit
-
-
Jan Kiszka authored
Drop the obsoleted mknod calls - all modern systems use devtmpfs, and that creates the rtp nodes for us. Furthermore, switch the remaining installation of udev rules to proper automake, using sysconfdir, INSTALL_DATA etc., dropping sudo from those steps (installation into privileged folders implies "sudo make install" or running as root in the first place). Finally, only differentiate between pre-existing udev.rules and default installation into rules.d. This removes the need for the install-user target - drop it. Signed-off-by:Jan Kiszka <jan.kiszka@siemens.com>
-
- 10 Oct, 2018 2 commits
-
-
Jan Kiszka authored
If xnregistry_enter in mq_open fails, the new entry will not be added to cobalt_mqq. But the cleanup path taken afterwards will nevertheless try to remove it from there. That will cause a crash because the mq->link is uninitialized. Fix that by initializing it as list head so that list removal becomes harmless, even when the entry is not on any list.. Signed-off-by: -
Otherwise, weird results could be seen when the second wraps, leading to t1.nsec < t2.nsec, e.g.: T: 0 ( 1107) P:98 I:1000 C:1886710 Min: 0 Act: 4 Avg:2147483647 Max: -1 Signed-off-by:
Philippe Gerum <rpm@xenomai.org> Signed-off-by:
-
- 02 Oct, 2018 4 commits
-
-
xnsched_realtime_cpus is a misnomer defining the set of CPUs which may handle timer events. cobalt_cpu_affinity is a subset of xnsched_realtime_cpus which defines which CPU(s) may run Cobalt threads. Signed-off-by:
-
cobalt_cpu_affinity defines the CPU set which may run Cobalt threads, which is a subset of xnsched_realtime_cpus. I.e. we may handle IRQs over CPUs which do not run threads. Signed-off-by:
-
Attempting to migrate to the head domain while running on a CPU which is not in part of the real-time set is a bug, and must be detected by the core. Furthermore, for this detection to work, the I-pipe must not BUG() unconditionally when failing to schedule out such thread in __ipipe_migrate_head(), but rather let the real-time core handle the situation (i.e. Xenomai in xnthread_harden()). Until both changes are in place, running a thread issuing a real-time call over a non-RT CPU would trigger a BUG() assertion, e.g.: With kernel parameter "xenomai.supported_cpus=2", running: $ switchtest --cpu-affinity=0 would lead to: [ 11.681486] kernel BUG at kernel/sched/core.c:5816! [ 11.686343] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM Signed-off-by:
-
Make sure people do run the cyclictest the way it is intended to with Xenomai (i.e. using Xenomai's rt scheduler...). Also, detect and bail out upon spurious relaxes in dual kernel mode, so that latency results are dismissed as they should until the bug is fixed. Signed-off-by:
-
- 27 Sep, 2018 1 commit
-
-
Jan Kiszka authored
This overwrote the pointer itself - and more. Long pending bugs. Signed-off-by:
-
- 24 Sep, 2018 3 commits
-
-
asm/uaccess.h is an arch-local, partial header which may cause build issues if included directly. Signed-off-by:
-
Various build systems and also the kernel uses aarch64 to refer to arm64, map aarch64 and arm64 to the same thing. Signed-off-by:
Marek Vasut <marex@denx.de> Signed-off-by:
-
Usable with latest Flexcan controller revisions available from recent i.MX series. The older driver would break when initializing the chip (FIFO activation), e.g.: [ 957.052272] rtcan0: real bitrate 1000000, sampling point 75.0% [ 957.058325] rtcan0: writing ctrl=0x011a2003 [ 957.062670] rtcan0: flexcan_set_bit_time: mcr=0x5980000f ctrl=0x011a2003 [ 957.069403] rtcan0: flexcan_chip_start: writing mcr=0x79a2020f [ 957.069421] rtcan0: flexcan_chip_start: writing ctrl=0x011aac53 [ 957.075359] Unhandled fault: imprecise external abort (0x1c06) at 0xaec71a2c [ 957.088371] pgd = cae8c000 [ 957.091106] [aec71a2c] *pgd=9d843835, *pte=ba49d75f, *ppte=ba49dc7f [ 957.097447] Internal error: : 1c06 [#1] SMP ARM [ 957.108324] CPU: 1 PID: 843 Comm: rtcanconfig Not tainted 4.14.34 #1 [ 957.115391] Hardware name: Freescale i.MX7 Dual (Device Tree) [ 957.121155] I-pipe domain: Linux [ 957.124404] task: caee1900 task.stack: ca5d0000 [ 957.128968] PC is at flexcan_chip_start+0x180/0x34c [ 957.133869] LR is at flexcan_chip_start+0x178/0x34c As a bonus, the latest work arounds addressing silicon bugs are now included (e.g. use of timestamp-based offloading when the FIFO ordering does not match the time of arrival). Signed-off-by:
-
- 17 Sep, 2018 4 commits
-
-
4.14 is always eager, unfortunately we will need a few ifdefs inside the eager fpu support as well. Signed-off-by:
Henning Schild <henning.schild@siemens.com> [Jan: converted C++-style comment] Signed-off-by:
-
Signed-off-by:
-
Linux 4.4.138 switched to eager fpu, set IPIPE_X86_FPU_EAGER accordingly. Signed-off-by:
-
Upstream 4.14 switched to purely eager fpu switching. That was backported to 4.4 and 4.9. This commit makes cobalt able to deal whith the changed kernel behaviour. This commit takes care of 4.9 to begin with. Introduce IPIPE_X86_FPU_EAGER to switch between the new and the old implementations. The new implementation is much simpler than the old one. We basically only deal with the odd case where Xenomai preempts Linux in a kernel-fpu context. In a regular Linux that can never happen and if it happens we need to make sure to get things into a consistent state. We have to make "current" as not owning the fpu anymore and allow others to use in-kernel fpu (kernel_fpu_enable). __switch_to from Linux will do the rest. Signed-off-by:
-
- 06 Sep, 2018 4 commits
-
-
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 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: -
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:
-
Signed-off-by:
-
- 04 Sep, 2018 1 commit
-
-
Move scheduler init/cleanup bits to dedicated routines. This concentrates scheduler related code in the sched module. Signed-off-by:
-
- 03 Sep, 2018 6 commits
-
-
Jan Kiszka authored
This should have been used only by rtdm_printk_ratelimited which was switched to xnclock_ratelimit. Signed-off-by: -
Jan Kiszka authored
Will allow to remove the RTDM-specific core. Signed-off-by: -
Jan Kiszka authored
Signed-off-by: -
Jan Kiszka authored
This will service as an internal building block for RT-safe rate-limited printk (printk_ratelimit() is not suited). It's derived from the RTDM variant, but simplied (central lock, static parameters). We will switch rtdm_printk_ratelimited to this implementation later on. Signed-off-by: -
Jan Kiszka authored
This reverts commit e2520f81 . The change was simply wrong, the return code was already passed, but that is hidden in the parameter list of cobalt_call_extension. The latter return 1 if a callback was invoked. Signed-off-by:
-
Signed-off-by:
-
- 31 Aug, 2018 2 commits
-
-
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.
-
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.
-
- 28 Aug, 2018 1 commit
-
-
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.
-
- 25 Aug, 2018 1 commit
-
-
For external projects wanting to use RTnet with its special features like RTnet IOCTLs it is necessary to provide the API headers in the Xenomai installation directory.
-
- 22 Aug, 2018 1 commit
-
-
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.
-
- 20 Aug, 2018 1 commit
-
-
Philippe Gerum authored
-
- 01 Aug, 2018 6 commits
-
-
This aligns the return code with cobalt_sched_setschedparam_ex: If there is no u_winoff and no thread, we should return ESRCH so that userspace can easily detect that it should call the standard libc service instead. Fix the core and remove the related workaround from the userspace lib. Signed-off-by: -
This aligns the implementation with the documentation: If we get an error from the kernel that suggests the thread is unknown to it, let glibc deal with it. Note that pthread_setschedparam_ex currently returns an invalid error code, EINVAL rather than ESRCH, so that we try to detect the remote thread case with some heuristic. Signed-off-by: -
Fix pthread_setschedparam_ex that it does not suggests the core to map the current thread if the target thread of the request is actually not pthread_self(). The core will reject such requests now, but we should avoid them in the first place so that we get a clear error code. Signed-off-by: -
It's always current, and it can only be current. Signed-off-by: -
Detect if the caller passed the PID of a remote thread that we do not know yet. In that case, do not try to shadow anything, that will only end up in a mess. Signed-off-by: -
If the caller has already a Xenomai shadow, we will crash rather than failing gracefully. The reason is that pthread_discard expects secondary mode - which may not be the case if the caller is already able to migrate. So check early and avoid that we can run into this trap. Signed-off-by:
-
- 14 Jul, 2018 1 commit
-
-
Philippe Gerum authored
No I-pipe architecture supports PIC muting anymore.
-
- 03 Jul, 2018 1 commit
-
-
Philippe Gerum authored
-
