[PATCH 00/25] Dovetail integration, next round

This is just half-way through to one working arch. A split at this at the point libcobalt is refactored for dovetail ticks. Test target for this part remains I-pipe, i.e. the check for no regressions on it. Jan CC: Hongzhan Chen CC: Philippe Gerum Hongzhan Chen (12): cobalt/irq: dovetail:

[PATCH 24/25] lib/cobalt: add default wrapper to clock_settime()

From: Philippe Gerum Signed-off-by: Philippe Gerum Signed-off-by: Jan Kiszka --- lib/cobalt/wrappers.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/lib/cobalt/wrappers.c b/lib/cobalt/wrappers.c index 860b260201..18c237734f 100644 --- a/lib/cobalt/wrappers.c +++

[PATCH 09/25] cobalt/x86: dovetail: add architecture bits

From: Philippe Gerum Signed-off-by: Philippe Gerum [Jan: style fixes, dropped/linked shared files] Signed-off-by: Jan Kiszka --- kernel/cobalt/arch/x86/dovetail/Makefile | 5 ++ kernel/cobalt/arch/x86/dovetail/c1e.c | 1 + .../include/asm/xenomai/calibration.h | 37

[PATCH 13/25] cobalt/init: dovetail: add oob stage enabling, disabling services

From: Hongzhan Chen Signed-off-by: Hongzhan Chen Signed-off-by: Jan Kiszka --- kernel/cobalt/dovetail/init.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/cobalt/dovetail/init.c b/kernel/cobalt/dovetail/init.c index 983186abe1..bc891b4c13 100644 ---

[PATCH 15/25] cobalt/tick: dovetail: install/uninstall proxy tick device

From: Hongzhan Chen Signed-off-by: Hongzhan Chen [Philippe: protect xntimer_start with nklock] Signed-off-by: Philippe Gerum Signed-off-by: Jan Kiszka --- kernel/cobalt/dovetail/tick.c | 83 ++- 1 file changed, 81 insertions(+), 2 deletions(-) diff --git

[PATCH 08/25] cobalt/x86: Move shared headers out of pipeline specific folder

From: Jan Kiszka Those are not affected by pipeline differences. Signed-off-by: Jan Kiszka --- kernel/cobalt/arch/x86/{ipipe => }/include/asm/xenomai/c1e.h | 0 kernel/cobalt/arch/x86/{ipipe => }/include/asm/xenomai/features.h | 0 kernel/cobalt/arch/x86/{ipipe =>

[PATCH 17/25] cobalt/tick: dovetail: implement pipeline_timer_name()

From: Hongzhan Chen Get the name of real device controlled by the proxy tick device. Signed-off-by: Hongzhan Chen Signed-off-by: Jan Kiszka --- include/cobalt/kernel/dovetail/pipeline/clock.h | 11 +-- kernel/cobalt/dovetail/tick.c | 12 2 files

[PATCH 03/25] cobalt/intr: dovetail: implement interrupt management, handling

From: Philippe Gerum We are using regular request/free_irq under dovetail. This also means there is no extra task to be done in the interrupt enable/disable services. The affinity hint set during request needs to be cleared before freeing the IRQ, or Linux will complain. Signed-off-by:

[PATCH 04/25] cobalt/irq: dovetail: implement out-of-band irq management and handling

From: Hongzhan Chen implement oob irq request and free and post for both TIMER_OOB_IPI and RESCHEDULE_OOB_IPI Signed-off-by: Hongzhan Chen Signed-off-by: Jan Kiszka --- .../kernel/dovetail/pipeline/pipeline.h | 41 ++- 1 file changed, 31 insertions(+), 10 deletions(-)

[PATCH 18/25] cobalt/timer: pipeline: abstract handling of ONESHOT_STOPPED mode

From: Hongzhan Chen It adds a way to force the timer management code to reprogram the hardware on option, to make the real device controlled by the proxy tick again as it leaves the ONESHOT_STOPPED mode. The I-pipe does not require any further action in this case, leading to a nop.

[PATCH 25/25] lib/cobalt: dovetail: use clock_gettime() vcall for reading timestamps

From: Philippe Gerum Dovetail enables out-of-band access to the vDSO-based clock_gettime() vcall from applications. If present, select this method instead of relying on the hardware tick counter for CLOCK_MONOTONIC, CLOCK_MONOTONIC_RAW, CLOCK_REALTIME and CLOCK_HOST_REALTIME. At binding time,

[PATCH 02/25] cobalt/kevents: dovetail: drop call to obsolete force_commit_memory()

From: Philippe Gerum A process is now marked for COW-breaking on fork() upon the first call to dovetail_init_altsched(), and must ensure its memory is locked via a call to mlockall(MCL_CURRENT|MCL_FUTURE) as usual. As a result, force_commit_memory() became pointless and was removed from the

[PATCH 01/25] cobalt/kernel: ipipe: rename xnsched_realtime_domain to xnsched_primary_domain

From: Philippe Gerum This symbol is now I-pipe specific, stick to the I-pipe nomenclature when referring to the high priority execution domain. Signed-off-by: Philippe Gerum Signed-off-by: Jan Kiszka --- .../cobalt/kernel/ipipe/pipeline/pipeline.h | 2 +- kernel/cobalt/ipipe/init.c

[PATCH 11/25] cobalt/sched: dovetail: add task control block initializers

From: Hongzhan Chen Signed-off-by: Hongzhan Chen Signed-off-by: Jan Kiszka --- kernel/cobalt/dovetail/sched.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/cobalt/dovetail/sched.c b/kernel/cobalt/dovetail/sched.c index 71f763d399..82e29136ca 100644 ---

[PATCH 23/25] lib/cobalt: dovetail: allow representing time as count of nanoseconds

From: Philippe Gerum When the core runs on top of Dovetail, all time values are represented as counts of nanoseconds, in which case a Cobalt tick equals a nanosecond. Introduce inline wrappers for tick-to/from-ns conversion which are nops in the latter case. Cobalt passes us a null clock

[PATCH 10/25] cobalt/kernel: dovetail: implement sirq services

From: Hongzhan Chen inband sirq request through synthetic_irq_domain and free and post srq. Signed-off-by: Hongzhan Chen Signed-off-by: Jan Kiszka --- .../cobalt/kernel/dovetail/pipeline/sirq.h| 28 +++ 1 file changed, 23 insertions(+), 5 deletions(-) diff --git

[PATCH 14/25] cobalt/timer: Check if nklock is held in timer services

From: Philippe Gerum Signed-off-by: Philippe Gerum Signed-off-by: Jan Kiszka --- kernel/cobalt/timer.c | 12 1 file changed, 12 insertions(+) diff --git a/kernel/cobalt/timer.c b/kernel/cobalt/timer.c index f9aa457ce9..9297cca186 100644 --- a/kernel/cobalt/timer.c +++

[PATCH 12/25] cobalt/clock: dovetail: provide backend code to CLOCK_HOST_REALTIME

From: Hongzhan Chen Signed-off-by: Hongzhan Chen Signed-off-by: Jan Kiszka --- include/cobalt/kernel/dovetail/pipeline/clock.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/cobalt/kernel/dovetail/pipeline/clock.h

linux-v5.10.y-dovetail

Hi Philippe, first, is source.denx.de/Xenomai/xenomai4/linux-evl.git already replacing git.evlproject.org/linux-evl.git? At least CI is currently stuck over the latter [update: was stuck, it's moving again]. Regarding 5.10, I think we are getting closer to the point where our users also need a

"cobalt/vfile: seq_file seek index must progress"

Hi Philippe, https://source.denx.de/Xenomai/xenomai/-/commit/dd9a5ee0ed6f734f40d3733f9fff23394c8647bd Bug fix unrelated to dovetail? There is no description, so I cannot easily asses this. Jan

Re: [PATCH V3 1/3] rtdm/testing: latmus: introduce latmus driver

On 21.04.21 07:05, hongzha1 via Xenomai wrote: > To support the latmus application for determining the best > gravity values for the cobalt core clock, and measuring > the response time to timer events. > > Signed-off-by: hongzha1 > --- > include/rtdm/uapi/testing.h | 63 ++ >

Re: [lttng-dev] LTTng - Xenomai : different results between timestamp-lttng and rt_time_read()

On 20.05.21 17:09, Mathieu Desnoyers wrote: > - On May 20, 2021, at 9:56 AM, Mathieu Desnoyers > mathieu.desnoy...@efficios.com wrote: > >> - On May 20, 2021, at 9:54 AM, lttng-dev lttng-...@lists.lttng.org wrote: >> >>> - On May 20, 2021, at 5:11 AM, lttng-dev

Re: y2038 dependency to wip/dovetail

On 19.05.21 19:41, Florian Bezdeka wrote: > On 19.05.21 19:23, Jan Kiszka wrote: >> On 19.05.21 17:34, Florian Bezdeka wrote: >>> Hi Jan, >>> >>> as already mentioned this morning during Xenomai community call, the >>> y2038 stuff has one more dependency that is not in next yet: >>> >>> We need

Re: y2038 dependency to wip/dovetail

On 19.05.21 17:34, Florian Bezdeka wrote: > Hi Jan, > > as already mentioned this morning during Xenomai community call, the > y2038 stuff has one more dependency that is not in next yet: > > We need this commit from wip/dovetail: > > 336f9d67e5a4 ("lib/cobalt: dovetail: use clock_gettime()

Re: reminder: Xenomai community call on today, May 19th, UTC 7:00

On 19.05.21 08:57, Chen, Hongzhan wrote: > Sorry ,please use zoom > https://us05web.zoom.us/j/81175706978?pwd=S1FmTWtKTGY3REJqNzJRbmt0ZzN4QT09 > Unfortunately, something is broken with Zoom here: This does not allow joining via the browser. Any other link, or any tweak to the meeting settings

Re: reminder: Xenomai community call on today, May 19th, UTC 7:00

On 19.05.21 08:03, Chen, Hongzhan via Xenomai wrote: > Just for soft reminder, As planned, we have the Xenomai community call > Topics may include but not limited to upstream/downstream project plan, > status update, and technical discussion. > It's an open online meeting that anyone can join and

Re: [for-upstream/dovetail 1/2] drivers/gpio: core: introduce helper to find array of gpiochips

On 18.05.21 23:25, Jan Kiszka wrote: > On 13.05.21 03:02, hongzha1 via Xenomai wrote: >> To find array of gpiochips for non-OF platform >> >> Signed-off-by: hongzha1 > > Just noticed that all your patches carry your user name in the > signed-off. You should fix that. Is this correct? > >

Re: [for-upstream/dovetail 1/2] drivers/gpio: core: introduce helper to find array of gpiochips

On 13.05.21 03:02, hongzha1 via Xenomai wrote: > To find array of gpiochips for non-OF platform > > Signed-off-by: hongzha1 Just noticed that all your patches carry your user name in the signed-off. You should fix that. Is this correct? Signed-off-by: Hongzhan Chen Also, please make sure

Re: arm/arm64 ipipe performance

On 18.05.21 20:28, Greg Gallagher via Xenomai wrote: > Hi Everyone, >There's been a noticeable slow down in the arm and arm64 latency of > late. I tracked the issue > down to the tracing infrastructure. For now if you hit this issue, > disable ftrace. Once this is done the latency numbers

Re: [PATCH 00/31] Update fec driver for xenomai 3 and linux kernel 5.4 and add I.MX8 support

On 12.05.21 11:52, Jean-Baptiste Tredez wrote: > > Le 12/05/2021 à 08:57, Jan Kiszka a écrit : >> On 11.05.21 18:05, Jean-Baptiste Trédez via Xenomai wrote: >>> Update fec driver for xenomai 3 and linux kernel 5.4 and add I.MX8 >>> support >>> >>> Patch  1 to 27 : rtnet-mcast+vlan branch from

Re: gdb and loading a realtime library with dlopen()

On 17.05.21 11:38, Grau, Gunter wrote: > > >> -Original Message- >> From: Grau, Gunter >> Sent: Mittwoch, 12. Mai 2021 08:32 >> To: xenomai@xenomai.org >> Subject: gdb and loading a realtime library with dlopen() >> >> Hi, >> >> We currently porting a Xenomai application from 2.6 to 3.1.

[xenomai-images][PATCH v2 1/9] ci: Create resource groups for all LAVA boards

From: Jan Kiszka We currently have only one instance per board in our lab, and there is only one QEMU instance max, independently of the architecture. So far, test jobs requesting the same one can start in parallel and will then wait on the LAVA cli, consuming job time. Avoid this at CI level

Re: [PATCH] Enable retrieving of RTNET network packet timestamp OOB using recvmsg()

On 12.05.21 14:57, François Legal via Xenomai wrote: > This patch enables retrieving, in realtime application, of RTNET enabled > adapters packet timestamps. > It uses the linux semantic SO_TIMESTAMPNS, and the linux code to put the > timestamp in the control_msg structure. > Thanks for the

[PATCH 3/7] drivers/net: cfg: fix config file load up

From: Philippe Gerum set_fs() is on its way out, so we cannot open code a file read operation by calling the VFS handler directly anymore, faking a user address space. We do have kernel interfaces for loading files though, particularly kernel_read_file(). So let's use that one for loading the

[PATCH 1/7] cobalt/memory: fix __vmalloc() calls

From: Philippe Gerum Since kernel v5.8, __vmalloc() does not take protection bits as PROT_KERNEL is now wired in. Therefore we cannot disable the cache for the UMM segment via the allocation call directly anymore. This said, we don't support any CPU architecture exhibiting cache aliasing

[PATCH 7/7] cobalt/x86: remove kernel support for x86_32

From: Philippe Gerum The legacy x86_32 architecture is on its way out, with no support from Dovetail. Besides, it went untested with I-pipe configurations for many moons. We still keep 32bit compat mode available for building the user-space libraries and executables though, along with

[PATCH 0/7] Assorted improvements and 5.10-preparations from dovetail queue

This prepares drivers for kernel 5.10 and removes the obsolete x32 ABI as well as support for 32-bit x86 kernels. After this, the dovetail queue should only contain directly dovetail-related changes, nothing that could affect older kernels with I-pipe. Jan CC: Philippe Gerum Philippe Gerum

[PATCH 4/7] drivers/testing: headcheck: remove variable-length array

From: Philippe Gerum Signed-off-by: Philippe Gerum --- kernel/drivers/testing/heapcheck.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/kernel/drivers/testing/heapcheck.c b/kernel/drivers/testing/heapcheck.c index 023a06ca64..207f20921f 100644 ---

[PATCH 5/7] testsuite/smokey: trace test startup with verbose=2

From: Philippe Gerum Signed-off-by: Philippe Gerum --- testsuite/smokey/main.c | 1 + 1 file changed, 1 insertion(+) diff --git a/testsuite/smokey/main.c b/testsuite/smokey/main.c index 5702e825a0..f24c1e990b 100644 --- a/testsuite/smokey/main.c +++ b/testsuite/smokey/main.c @@ -31,6 +31,7 @@

[PATCH 6/7] cobalt/x86: remove support for the x32 ABI

From: Philippe Gerum After raising the topic of (dis)continuing support for the x32 ABI multiple times on the mailing list, it turned out that Xenomai has no known users of this dying ABI. So let's remove it. Signed-off-by: Philippe Gerum --- .../x86/include/asm/xenomai/uapi/syscall.h| 8

[PATCH 2/7] drivers/net: checksum: convert to memcpy+csum

From: Philippe Gerum Since v5.9-rc1, csum_partial_copy_nocheck() forces a zero seed as its last argument to csum_partial(). According to #cc44c17baf7f3, passing a non-zero value would not even yield the proper result on some architectures. However, other locations still expect a non-zero csum

[xenomai-images][PATCH 7/9] ci: Rename and reorder child pipeline

From: Jan Kiszka Ordering for pure aesthetic reasons, naming to align with the branch names from the main Xenomai repo. The latter will help with setting triggers. Signed-off-by: Jan Kiszka --- ci/child_pipelines_artifacts.yml| 12 ++-- ci/child_pipelines_no_artifacts.yml | 12

[PATCH] ci: Trigger xenomai-images child pipeline corresponding to main branches

From: Jan Kiszka This couples pushing to next and stable branches with running xenomai-images, and then only the affected child pipeline. Precondition is setting XENOMAI_IMAGES_TOKEN as protected CI/CD variable. Signed-off-by: Jan Kiszka --- .gitlab-ci.yml | 13 + 1 file changed,

[xenomai-images][PATCH 2/9] ci: Remove "board-" from job names

From: Jan Kiszka Only adds verbosity but no information. Keep it for the resource groups, though, as they are board-related. Signed-off-by: Jan Kiszka --- ci/gitlab-ci-base.yml | 20 +++--- ci/kernel_4_19_xenomai_next.yml | 48 -

[xenomai-images][PATCH 4/9] ci: Remove redundant job filtering on USE_GITLAB_ARTIFACTS

From: Jan Kiszka Already done by including only one of the two files. Signed-off-by: Jan Kiszka --- ci/artifacts.yml| 4 ci/no-artifacts.yml | 3 --- 2 files changed, 7 deletions(-) diff --git a/ci/artifacts.yml b/ci/artifacts.yml index fb1549f..9d6b0e1 100644 --- a/ci/artifacts.yml

[xenomai-images][PATCH 8/9] ci: Factor out common bridge jobs

From: Jan Kiszka Further reduces the duplicate parts in child_pipelines_[no_]artifacts.yml. Signed-off-by: Jan Kiszka --- ci/child_pipelines_artifacts.yml| 14 ++ ci/child_pipelines_common.yml | 19 +++ ci/child_pipelines_no_artifacts.yml | 14

[xenomai-images][PATCH 9/9] ci: Add job filter variable

From: Jan Kiszka This allows to set a filter variable when triggering the pipeline, effectively running only one of the currently three child pipelines. Will permit automatic triggering from the Xenomai repo on pushes to the corresponding branches. Signed-off-by: Jan Kiszka ---

[xenomai-images][PATCH 5/9] ci: Pull common .add-lava-ssh-config into gitlab-ci-base.yml

From: Jan Kiszka Also refactor a bit for better readability. Signed-off-by: Jan Kiszka --- ci/artifacts.yml | 8 ci/gitlab-ci-base.yml | 12 ci/no-artifacts.yml | 9 + 3 files changed, 13 insertions(+), 16 deletions(-) diff --git a/ci/artifacts.yml

[xenomai-images][PATCH 3/9] ci: Fix USE_GITLAB_ARTIFACTS definition

From: Jan Kiszka Variables do not propagate automatically to child pipelines. So define this one in the artifact version of the child pipeline file. Signed-off-by: Jan Kiszka --- .gitlab-ci-artifacts.yml | 3 --- ci/artifacts.yml | 4 2 files changed, 4 insertions(+), 3

[xenomai-images][PATCH 0/9] ci improvements

This brings a number of improvements for our CI/CT: - resource groups for board to avoid spinning actively on busy ones - filter variable to run only for a specific Xenomai branch - consolidation of the artifact/no-artifact cases - fix for artifact child pipeline With this and an upcoming CI

[xenomai-images][PATCH 6/9] ci: Consolidate artifacts/no-artifacts case

From: Jan Kiszka By checking for USE_GITLAB_ARTIFACTS, we can share the scripts section. This leaves the variation to the addition of artifacts. Signed-off-by: Jan Kiszka --- ci/artifacts.yml | 6 +- ci/gitlab-ci-base.yml | 8 ci/no-artifacts.yml | 7 +-- 3 files

[xenomai-images][PATCH 1/9] ci: Create resource groups for all LAVA boards

From: Jan Kiszka We currently have only one instance per board in our lab. So far, test jobs requesting the same one can start in parallel and will then wait on the LAVA cli, consuming job time. Avoid this at CI level already. Signed-off-by: Jan Kiszka --- ci/gitlab-ci-base.yml | 6 ++ 1

Re: latency test crashing

On 12.05.21 00:04, Peter Laurich via Xenomai wrote: > Hi, > > I am hoping that someone can help me to solve a problem that I am having > with the Xenomai latency test. > > Here is my set up: > > * 4.9.146 kernel with ipipe patch (this is the last kernel version >   that supports 32-bit x86 and

Re: [PATCH 00/31] Update fec driver for xenomai 3 and linux kernel 5.4 and add I.MX8 support

On 11.05.21 18:05, Jean-Baptiste Trédez via Xenomai wrote: > Update fec driver for xenomai 3 and linux kernel 5.4 and add I.MX8 support > > Patch 1 to 27 : rtnet-mcast+vlan branch from Philippe Gerum with updated > driver for 4.18.85 kernel > Patch 28 to 29 : update driver for 5.4 kernel and

Re: xeno-test failed due to cond_destroy error

On 12.05.21 04:08, Fangsuo Wu wrote: > yes, to be more accurate, the issue is found in the libc file under > gcc-linaro-arm-linux-gnueabihf-4.9-2014.08_linux/arm-linux-gnueabihf/libc/usr/include/pthread.h. > > The glibc is accompanied with the gcc I downloaded from >

Re: xeno-test failed due to cond_destroy error

On 11.05.21 12:37, Fangsuo Wu wrote: > Hi, the issue seems related to the gcc compiler I > used（gcc-linaro-arm-linux-gnueabihf-4.9-2014.08_linux）. Huh, that is... well "matured". > > I added some log and found the failure was from below code, line 155: > pthread_cond_destroy > ->

Re: [PATCH] ipipe_tsc: Use WRTIE_ONCE for updating last_tsc

On 11.05.21 16:57, Grau, Gunter via Xenomai wrote: >> -Original Message- >> From: Gunter Grau >> Sent: Freitag, 5. März 2021 09:22 >> To: xenomai@xenomai.org >> Cc: r...@xenomai.org; Grau, Gunter >> Subject: [PATCH] ipipe_tsc: Use WRTIE_ONCE for updating last_tsc >> >> The gcc 8.3

Re: xeno-test failed due to cond_destroy error

On 10.05.21 09:20, Fangsuo Wu wrote: > Jan, > Thanks for your reply. The environment I used is listed below. BTW, I > can run latency test successfully. > > 1. The revision of Xenomai: xenomai-3.1.tar.bz2 > 2. Soc: dual ARM cortex A7 > 3. How I built application libraries: > ./configure

Re: [PATCH wip/dovetail 1/1] cobalt: Remove duplicate timespec/itimerspec copy helpers

On 07.05.21 17:18, Florian Bezdeka wrote: > The variant of such helpers which are using a temporary element on the > stack work in both worlds, so on systems with 4 and 8 byte time_t. > To keep the code as simple as possible we can remove the > __BITS_PER_LONG == 64 implementation. > >

Re: xeno-test failed due to cond_destroy error

On 10.05.21 03:56, Fangsuo Wu via Xenomai wrote: > Hi, I met below errors when running xeno-test in my board: > > > > > > > > > > > > > > > > > > > > > *sh-4.4# ./xeno-testStarted child 209: /bin/sh > /usr/xenomai/bin/xeno-test-run-wrapper ./xeno-test++ echo 0++ >

Re: [PATCH v6 0/4] Adressing y2038 test failures on ARM and BBB

On 07.05.21 23:51, Florian Bezdeka wrote: > The CI pipeline discovered an invalid instruction on some ARM boards, > especially the BBB (beaglebone black). Applying this patch series should > fix the current test failure on "next" branch. > > As already discussed: There might be another problem in

Re: Timer_Create for periodic tasks

[re-adding the list] On 09.05.21 13:06, Marco Barletta wrote: > Yes, of course. > I attached "test3.c" that is a basic posix period task ripoff i found on > the web by Marc Le Douarain. I couldn't test with smokey since at the > best of my knowledge I realized it doesn't handles periodic tasks

Re: Timer_Create for periodic tasks

On 08.05.21 17:13, Marco Barletta via Xenomai wrote: > Hi everyone; > I'm currently running Xenomai 3.1 and I'm facing with an issue. When I want > to create a periodic task using timer_create and consequently sigwait or > sigwaitinfo it works when running in root pid namespace, but when i run the

Re: [PATCH v4 3/4] y2038: Add tests for the sc_cobalt_sem_timedwait64 syscall

On 07.05.21 17:58, Jan Kiszka via Xenomai wrote: > On 07.05.21 14:49, Florian Bezdeka wrote: >> Introducing a new smokey plugin that can be extended for all kind of >> y2038 tests. For now we are testing the new sc_cobalt_sem_timedwait64 >> syscall without using any l

Re: [PATCH v4 3/4] y2038: Add tests for the sc_cobalt_sem_timedwait64 syscall

On 07.05.21 14:49, Florian Bezdeka wrote: > Introducing a new smokey plugin that can be extended for all kind of > y2038 tests. For now we are testing the new sc_cobalt_sem_timedwait64 > syscall without using any libc wrappers provided by libcobalt. > > Signed-off-by: Florian Bezdeka > --- >

Re: [PATCH v4 3/4] y2038: Add tests for the sc_cobalt_sem_timedwait64 syscall

On 07.05.21 14:49, Florian Bezdeka wrote: > Introducing a new smokey plugin that can be extended for all kind of > y2038 tests. For now we are testing the new sc_cobalt_sem_timedwait64 > syscall without using any libc wrappers provided by libcobalt. > > Signed-off-by: Florian Bezdeka > --- >

Re: [PATCH v2 0/9] y2038 groundwork and first steps

On 05.05.21 18:52, Jan Kiszka via Xenomai wrote: > Picking up from Philippe's queue: > > This patch series prepares the tree for the upcoming y2038 work, > converting obsolete/ambiguous time specification types to the proper > ones introduced upstream by the v5.x kernel ser

[PATCH v2 6/9] cobalt/sem: y2038: Fixing the sem_timedwait syscall for 32 bit systems

From: Florian Bezdeka On systems using 32 bit for time_t the sem_timedwait syscall was broken because the function used for copying the timeout value from userspace to kernel (=sem_fetch_timeout()) was always copying sizeof(struct timespec64). A 32 bit application (or more specific an

[PATCH v2 3/9] cobalt/kernel: y2038: convert struct itimerspec to itimerspec64

From: Philippe Gerum As internal interfaces are gradually being made y2038-safe, the itimerspec64 type should be used internally by the kernel to represent interval timer specs. Apply the same reasoning to Cobalt. We still use a legacy y2038-unsafe itimerspec type at the kernel<->user interface

[PATCH v2 8/9] y2038: Add tests for the sc_cobalt_sem_timedwait64 syscall

From: Florian Bezdeka Introducing a new smokey plugin that can be extended for all kind of y2038 tests. For now we are testing the new sc_cobalt_sem_timedwait64 syscall without using any libc wrappers provided by libcobalt. Signed-off-by: Florian Bezdeka [Jan: add missing stdbool include]

[PATCH v2 7/9] y2038: Adding sem_timedwait64

From: Florian Bezdeka Implementation is heavily inspired by the sem_timedwait syscall, but expecting time64 based timespec / timeout. We need two new syscall handlers: - The native one (COBALT_SYSCALL()) to get 32 bit kernels time64 aware. This handler is added for 64 bit kernels as well,

[PATCH v2 0/9] y2038 groundwork and first steps

Picking up from Philippe's queue: This patch series prepares the tree for the upcoming y2038 work, converting obsolete/ambiguous time specification types to the proper ones introduced upstream by the v5.x kernel series. In v2, feedback on the first round has been addressed, primarily regarding

[PATCH v2 2/9] lib: y2038: convert to internal timespec type

From: Philippe Gerum Signed-off-by: Philippe Gerum Signed-off-by: Jan Kiszka --- lib/alchemy/task.c | 9 ++--- lib/copperplate/threadobj.c | 9 ++--- lib/psos/task.c | 9 ++--- lib/vxworks/kernLib.c | 6 -- lib/vxworks/taskLib.c | 6 -- 5

[PATCH v2 4/9] cobalt/kernel: y2038: convert struct timex to __kernel_timex

From: Philippe Gerum As internal interfaces are gradually being made y2038-safe, the __kernel_timex type should be used internally by the kernel to represent time adjustment parameters. Apply the same reasoning to Cobalt. We still use a legacy y2038-unsafe timex type at the kernel<->user

[PATCH v2 1/9] cobalt/kernel: y2038: convert struct timespec to timespec64

From: Philippe Gerum As internal interfaces are gradually being made y2038-safe, the timespec64 type should be used internally by the kernel to represent time values. Apply the same reasoning to Cobalt. We still use a legacy y2038-unsafe timespec type at the kernel<->user interface boundary

[PATCH v2 9/9] y2038: lib/cobalt: Add support of sc_cobalt_sem_timedwait64

From: Florian Bezdeka In case libcobalt is build with -D_TIME_BITS=64 sc_cobalt_sem_timedwait64 will be used instead of sc_cobalt_sem_timedwait. Signed-off-by: Florian Bezdeka Signed-off-by: Jan Kiszka --- lib/cobalt/semaphore.c | 5 + 1 file changed, 5 insertions(+) diff --git

[PATCH v2 5/9] cobalt/kernel: y2038: switch to new legacy type names

From: Philippe Gerum Since 5.6-rc3, former 32bit compatibility types for time-related structs have been renamed as follows: compat_timeval -> old_timeval32 compat_timespec -> old_timespec32 compat_itimerspec -> old_itimerspec32 Apply the same changes to the tree, providing backward

Community call now - but we have some issues

Hi all, a reminder for our biweekly community call. It should take place right now - except that we still need our host to open it up. As there is not reaction so far, let's move (I'm online already): https://meet.jit.si/xenomai-call (This would be the regular link:

Re: Community call now - but we have some issues

On 05.05.21 09:09, Jan Kiszka wrote: > Hi all, > > a reminder for our biweekly community call. It should take place right > now - except that we still need our host to open it up. > > As there is not reaction so far, let's move (I'm online already): > > https://meet.jit.si/xenomai-call > Ok,

Re: [PATCH v2 5/7] drivers/net: wrap csum_partial_copy_nocheck()

On 04.05.21 16:48, Philippe Gerum wrote: > > Philippe Gerum writes: > >> Philippe Gerum writes: >> >>> Jan Kiszka writes: >>> On 16.04.21 18:48, Philippe Gerum wrote: > > Jan Kiszka writes: > >> On 15.04.21 09:54, Philippe Gerum wrote: >>> >>> Jan Kiszka writes:

Re: RTSerial Difference in Behavior Between 2.6.4 & 3.1

On 04.05.21 22:40, Alan Gaglio wrote: >> -Original Message- >> From: Jan Kiszka >> Sent: Friday, April 23, 2021 1:52 AM >> To: Alan Gaglio ; xenomai@xenomai.org >> Subject: Re: RTSerial Difference in Behavior Between 2.6.4 & 3.1 >> >> On 22.04.21 20:52, Alan Gaglio wrote: From: Jan

Re: [RFC] status of [meta-]xenomai for Yocto

On 03.05.21 19:16, Henning Schild via Xenomai wrote: > We have xenomai-images kind of maintained under the umbrella of the > project. But that is Isar and Yocto sure has its place as well. I have > also seen buildroot layers which include xenomai. > > Such integration systems tend to cause a lot

[RFC][PATCH] dovetail: intr: Clear affinity_hint before freeing the IRQ

From: Jan Kiszka We are setting it on xnintr_attach(), and Linux seems to dislike when it is non-NULL on free_irq(). __free_irq(): ... /* make sure affinity_hint is cleaned up */ if (WARN_ON_ONCE(desc->affinity_hint)) desc->affinity_hint = NULL; Signed-off-by:

Re: Can printk in the root domain cause the system to hung ?

On 25.04.21 12:33, Jamie Huang via Xenomai wrote: > Hi, all: > We are now porting ipipe on mips architecture. There is a > problem, after local_irq_enable() is called in start_kernel(), system > looks hung. We found that this may be related to printk in root domain, > if we use early_printk

Re: Updating fec driver for kernel 5.4 and I.MX8Q

On 26.04.21 14:21, Jean-Baptiste Tredez via Xenomai wrote: > Hello, > > Do you have plans for updating fec drivers on xenomai 3.1 ? > > We tried to merge uptream linux driver and Philippe Gerum work (commit > 1b7a4bd9598aa0d777016fda7e51d2e22aa51e77). Here is the result, it seems > to work on

Re: RTSerial Difference in Behavior Between 2.6.4 & 3.1

On 22.04.21 20:52, Alan Gaglio wrote: >> From: Jan Kiszka >> Sent: Wednesday, April 21, 2021 3:00 AM >> To: Alan Gaglio ; xenomai@xenomai.org >> Subject: Re: RTSerial Difference in Behavior Between 2.6.4 & 3.1 >> >> On 20.04.21 16:45, Alan Gaglio via Xenomai wrote: >>> I am in the process of

Re: RTSerial Difference in Behavior Between 2.6.4 & 3.1

On 20.04.21 16:45, Alan Gaglio via Xenomai wrote: > I am in the process of upgrading from 32-bit/Xenomai 2.6.4/Ubuntu 14.04.4/ > Linux 3.16.7 to 64-bit/Xenomai 3.1/Ubuntu 20.04.1/Linux 5.4.77 and I'm > experiencing an rtserial event difference in behavior. Our application > depends on single-byte

Re: [PATCH v2 3/3] y2038: testsuite/smokey/y2038: testcase for nanosleep64

On 20.04.21 08:25, Song Chen via Xenomai wrote: > From: chensong > > add test case for clock_nanosleep64 in testsuite > > Signed-off-by: chensong > > --- > v2: > 1, REALTIME --> MONOTONIC > 2, more combinations > 3, smokey warning in clock_gettime > 4, remove magic number > --- >

Re: [PATCH V2 3/3] testsuite/latmus: introduce latmus benchmark

On 20.04.21 03:02, Chen, Hongzhan wrote: > > >> -Original Message- >> From: Jan Kiszka >> Sent: Friday, April 16, 2021 8:05 PM >> To: Chen, Hongzhan ; xenomai@xenomai.org >> Subject: Re: [PATCH V2 3/3] testsuite/latmus: introduce latmus benchmark >> >> On 16.04.21 07:31, hongzha1 via

Re: [PATCH v2 5/7] drivers/net: wrap csum_partial_copy_nocheck()

On 16.04.21 18:48, Philippe Gerum wrote: > > Jan Kiszka writes: > >> On 15.04.21 09:54, Philippe Gerum wrote: >>> >>> Jan Kiszka writes: >>> On 15.04.21 09:21, Philippe Gerum wrote: > > Jan Kiszka writes: > >> On 27.03.21 11:19, Philippe Gerum wrote: >>> From:

Re: [PATCH V2 0/3] introduce latmus

On 16.04.21 07:31, hongzha1 via Xenomai wrote: > Latmus is a backport from EVL to Cobalt, the procedure is fully > described here: https://evlproject.org/core/benchmarks/ ...but in a EVL-specific way. At least terminology is different, but I suspect more. > > I verified all functions of latmus

Re: [PATCH V2 3/3] testsuite/latmus: introduce latmus benchmark

On 16.04.21 07:31, hongzha1 via Xenomai wrote: > Measure response time to GPIO events sent by a remote Zephyr-based > latency monitor (latmon). This monitor collects then sends the latency > data over a network connection to the latmus front-end which displays > the results received: > > [Linux

Re: Stuck qemuarm target in xenomai-images

On 15.04.21 14:54, Greg Gallagher wrote: > > > On Thu, Apr 15, 2021 at 8:49 AM Jan Kiszka > wrote: > > Hi Greg, > > I debugged a bit between meetings: > > (gdb) > 335             rc = dev->set_next_event((unsigned long) clc, dev); > > Here

Re: ipipe 5.4.107 / 5.4.93 build issues on arm32

On 15.04.21 14:09, Greg Gallagher wrote: > > > On Thu, Apr 15, 2021 at 2:59 AM Jan Kiszka > wrote: > > On 15.04.21 07:35, Greg Gallagher via Xenomai wrote: > > On Wed, Apr 14, 2021 at 7:43 PM steve freyder > wrote: > > >

Stuck qemuarm target in xenomai-images

Hi Greg, I debugged a bit between meetings: (gdb) 335 rc = dev->set_next_event((unsigned long) clc, dev); Here we crash in early boot because set_next_event is NULL: (gdb) p *dev $4 = {event_handler = 0xc03cc2e8 , set_next_event = 0x0, set_next_ktime = 0x0, next_event = 1000,

Re: [PATCH v2 5/7] drivers/net: wrap csum_partial_copy_nocheck()

On 15.04.21 09:54, Philippe Gerum wrote: > > Jan Kiszka writes: > >> On 15.04.21 09:21, Philippe Gerum wrote: >>> >>> Jan Kiszka writes: >>> On 27.03.21 11:19, Philippe Gerum wrote: > From: Philippe Gerum > > Since v5.9-rc1, csum_partial_copy_nocheck() forces a zero seed as

Re: [PATCH v2 5/7] drivers/net: wrap csum_partial_copy_nocheck()

On 15.04.21 09:21, Philippe Gerum wrote: > > Jan Kiszka writes: > >> On 27.03.21 11:19, Philippe Gerum wrote: >>> From: Philippe Gerum >>> >>> Since v5.9-rc1, csum_partial_copy_nocheck() forces a zero seed as its >>> last argument to csum_partial(). According to #cc44c17baf7f3, passing >>> a

Re: ipipe 5.4.107 / 5.4.93 build issues on arm32

On 15.04.21 07:35, Greg Gallagher via Xenomai wrote: > On Wed, Apr 14, 2021 at 7:43 PM steve freyder wrote: > >> On 4/14/2021 4:50 PM, Greg Gallagher via Xenomai wrote: >> >> On Wed, Apr 14, 2021 at 4:52 PM Thomas Petazzoni >> wrote: >> >> >> On Wed, 14 Apr 2021 14:41:29 -0400 >> Greg

Re: ipipe 5.4.107 / 5.4.93 build issues on arm32

On 14.04.21 14:42, Thomas Petazzoni via Xenomai wrote: > Hello, > > I just tested the following ipipe patches on arm32: > > https://xenomai.org/downloads/ipipe/v5.x/arm/ipipe-core-5.4.107-arm-1.patch > https://xenomai.org/downloads/ipipe/v5.x/arm/ipipe-core-5.4.93-arm-0.patch > > applied of

Re: Path to xeno-config - packages vs. scripts

On 14.04.21 12:39, Bezdeka, Florian (T RDA IOT SES-DE) wrote: > On Wed, 2021-04-14 at 10:08 +, Bezdeka, Florian via Xenomai wrote: >> Hi! >> >> While porting a simple application to Xenomai I had some problems >> related to the xeno-config tool: >> >> xeno-config is part of the xenomai-runtime

<    5   6   7   8   9   10   11   12   13   14   >