[xenomai-images PATCH] tests: restrict realtime cpu

If there is no CPU restriction on the bootargs, smokey cpu_affinity test would be skipped reporting with "no kernel support". Signed-off-by: Hongzhan Chen diff --git a/tests/jobs/xenomai-beagle-bone-black.yml b/tests/jobs/xenomai-beagle-bone-black.yml index 034ac99..8117f29 100644 ---

Re: Docker - Xenomai hangs on rt_task_wait_period()

On 22.06.21 18:38, MONTET Julien via Xenomai wrote: > Hello the developers, > > I have been using Xenomai for the past two months on different targets / > skins / architectures, and it is a great real time solution ! > For the past few days, I have been trying to use my code on a docker : > >

Re: about issue #14 on xenomai-hacker-space

On 23.06.21 04:54, Chen, Hongzhan wrote: > Hi Jan > > I do not know if the issue #14 you reported is about "cpu_affinity skipped > (no kernel support)" in log [1]. > The issue "cpu_affinity skipped (no kernel support)" is because there is no > non-RT cpu found in system > and we may pass

about issue #14 on xenomai-hacker-space

Hi Jan I do not know if the issue #14 you reported is about "cpu_affinity skipped (no kernel support)" in log [1]. The issue "cpu_affinity skipped (no kernel support)" is because there is no non-RT cpu found in system and we may pass xenomai.supported_cpus in commandline to restrict RT cpu to

Docker - Xenomai hangs on rt_task_wait_period()

Hello the developers, I have been using Xenomai for the past two months on different targets / skins / architectures, and it is a great real time solution ! For the past few days, I have been trying to use my code on a docker : * Compiled on a debian 10.9 with Xenomai libraries (3.1) for an

Re: x86: ipipe: Tracing of preemptirq events triggers a kernel PANIC

On Tue, 2021-06-22 at 09:41 +, Bezdeka, Florian via Xenomai wrote: > Hi, > > I'm able to easily reproduce a kernel PANIC when trying to enable the > following trace events: > > - preemptirq:irq_enable > - preemptirq:irq_disable > > or as cmdline: > > trace-cmd start -e

Re: Large gpio interrupt latency

Jan Kiszka writes: > On 22.06.21 11:31, Philippe Gerum wrote: >> >> Jan Kiszka writes: >> >>> On 22.06.21 10:37, Philippe Gerum wrote: Jan Kiszka writes: > On 22.06.21 09:49, Julien Blanc via Xenomai wrote: >> Le mardi 22 juin 2021 à 09:38 +0200, Philippe Gerum via

x86: ipipe: Tracing of preemptirq events triggers a kernel PANIC

Hi, I'm able to easily reproduce a kernel PANIC when trying to enable the following trace events: - preemptirq:irq_enable - preemptirq:irq_disable or as cmdline: trace-cmd start -e "preemptirq:irq_enable" trace-cmd start -e "preemptirq:irq_disable" The PANIC can be reproduced with 4.19 and

Re: Large gpio interrupt latency

On 22.06.21 11:31, Philippe Gerum wrote: > > Jan Kiszka writes: > >> On 22.06.21 10:37, Philippe Gerum wrote: >>> >>> Jan Kiszka writes: >>> On 22.06.21 09:49, Julien Blanc via Xenomai wrote: > Le mardi 22 juin 2021 à 09:38 +0200, Philippe Gerum via Xenomai a > écrit : >>

Re: Large gpio interrupt latency

Jan Kiszka writes: > On 22.06.21 10:37, Philippe Gerum wrote: >> >> Jan Kiszka writes: >> >>> On 22.06.21 09:49, Julien Blanc via Xenomai wrote: Le mardi 22 juin 2021 à 09:38 +0200, Philippe Gerum via Xenomai a écrit : > > With this in mind, assuming that we have

Re: Large gpio interrupt latency

On 22.06.21 10:37, Philippe Gerum wrote: > > Jan Kiszka writes: > >> On 22.06.21 09:49, Julien Blanc via Xenomai wrote: >>> Le mardi 22 juin 2021 à 09:38 +0200, Philippe Gerum via Xenomai a >>> écrit : With this in mind, assuming that we have previously sanitized the clock

Re: Large gpio interrupt latency

Jan Kiszka writes: > On 22.06.21 09:49, Julien Blanc via Xenomai wrote: >> Le mardi 22 juin 2021 à 09:38 +0200, Philippe Gerum via Xenomai a >> écrit : >>> >>> With this in mind, assuming that we have previously sanitized the >>> clock >>> identifier, doing this: >>> >>> #define

Re: Large gpio interrupt latency

On 22.06.21 09:49, Julien Blanc via Xenomai wrote: > Le mardi 22 juin 2021 à 09:38 +0200, Philippe Gerum via Xenomai a > écrit : >> >> With this in mind, assuming that we have previously sanitized the >> clock >> identifier, doing this: >> >> #define get_timestamp(__clock) \ >> ({ (__clock) ==

Re: dovetail: posix-clock: Sporadic test failures

On Tue, 2021-06-22 at 10:18 +0200, Jan Kiszka wrote: > On 22.06.21 10:09, Bezdeka, Florian (T RDA IOT SES-DE) wrote: > > Hi, > > > > would be interesting to know if someone else is seeing sporadic test > > failures of the posix-clock tests. There are two failures that I can > > regularly

Re: dovetail: posix-clock: Sporadic test failures

On 22.06.21 10:09, Bezdeka, Florian (T RDA IOT SES-DE) wrote: > Hi, > > would be interesting to know if someone else is seeing sporadic test > failures of the posix-clock tests. There are two failures that I can > regularly reproduce on one of our (quite big) test machines: > > Hardware info: >

dovetail: posix-clock: Sporadic test failures

Hi, would be interesting to know if someone else is seeing sporadic test failures of the posix-clock tests. There are two failures that I can regularly reproduce on one of our (quite big) test machines: Hardware info: 32 cores, Intel Xeon E5-2640, Sandy Bridge EP a) posix-clock.c:285, assertion

Re: Large gpio interrupt latency

Le mardi 22 juin 2021 à 09:38 +0200, Philippe Gerum via Xenomai a écrit : > > With this in mind, assuming that we have previously sanitized the > clock > identifier, doing this: > > #define get_timestamp(__clock) \ > ({ (__clock) == CLOCK_MONOTONIC ? rtdm_clock_read_monotonic() : >

Re: Large gpio interrupt latency

François Legal writes: > Le Lundi, Juin 21, 2021 18:45 CEST, Philippe Gerum a > écrit: > >> >> Philippe Gerum via Xenomai writes: >> >> > François Legal writes: >> > >> >> Le Lundi, Juin 21, 2021 16:57 CEST, Philippe Gerum a >> >> écrit: >> >> >> >>> >> >>> Jan Kiszka writes: