Re: [Xenomai 3.1 PATCH v2] process: update clockfreq when receive corresponding event.

On 17.06.22 08:08, Jan Kiszka via Xenomai wrote: > On 16.06.22 02:18, Hongzhan Chen via Xenomai wrote: >> 1. When there is clockfreq param passed down via command line, we >>do not update clockfreq even if we receive event of updating clockfreq. >>Or else, we

Re: [I-PIPE PATCH v2] x86/tsc: I-PIPE : notify I-PIPE about updated clockfreq

On 16.06.22 02:18, Hongzhan Chen via Xenomai wrote: > When there is refined tsc clock, notify Xenomai to apply it. > Linux may schedule a delayed work to refine tsc clock and update > tsc_khz which happen after Xenomai finsih init but tsc_scale and > tsc_shift still keep the value depending on

Re: [I-PIPE PATCH v2] x86/tsc: I-PIPE : notify I-PIPE about updated clockfreq

On 17.06.22 08:09, Jan Kiszka via Xenomai wrote: > On 16.06.22 02:18, Hongzhan Chen via Xenomai wrote: >> When there is refined tsc clock, notify Xenomai to apply it. >> Linux may schedule a delayed work to refine tsc clock and update >> tsc_khz which happen after Xenomai fins

Re: [I-PIPE PATCH v2] x86/tsc: I-PIPE : notify I-PIPE about updated clockfreq

On 16.06.22 02:18, Hongzhan Chen via Xenomai wrote: > When there is refined tsc clock, notify Xenomai to apply it. > Linux may schedule a delayed work to refine tsc clock and update > tsc_khz which happen after Xenomai finsih init but tsc_scale and > tsc_shift still keep the value depending on

Re: [Xenomai 3.1 PATCH v2] process: update clockfreq when receive corresponding event.

On 16.06.22 02:18, Hongzhan Chen via Xenomai wrote: > 1. When there is clockfreq param passed down via command line, we >do not update clockfreq even if we receive event of updating clockfreq. >Or else, we update the clockfreq with notified value. > 2. At the same time, we would like to

Re: [PATCH 3.2.x] cobalt/x86: Account for changes to switch_fpu_finish in 5.4.182

On 15.06.22 17:20, Jan Kiszka via Xenomai wrote: > From: Jan Kiszka > > The signature of switch_fpu_finish changed in stable 5.4. > > Signed-off-by: Jan Kiszka > --- > kernel/cobalt/arch/x86/ipipe/thread.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-)

Re: [xenomai-images][PATCH] Update Isar revision

On 15.06.22 18:00, Jan Kiszka via Xenomai wrote: > From: Jan Kiszka > > This brings changes to image types that are easy to account for. Also > the image file name changed, so adjust readme and start-qemu.sh. > > The update fixes logging issues, thus helps a lot with analyzin

[xenomai-images][PATCH] Update Isar revision

From: Jan Kiszka This brings changes to image types that are easy to account for. Also the image file name changed, so adjust readme and start-qemu.sh. The update fixes logging issues, thus helps a lot with analyzing failing builds, specifically in CI. Signed-off-by: Jan Kiszka --- README.md

[PATCH 3.2.x] cobalt/x86: Account for changes to switch_fpu_finish in 5.4.182

From: Jan Kiszka The signature of switch_fpu_finish changed in stable 5.4. Signed-off-by: Jan Kiszka --- kernel/cobalt/arch/x86/ipipe/thread.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/cobalt/arch/x86/ipipe/thread.c b/kernel/cobalt/arch/x86/ipipe/thread.c

Re: [PATCH] rtdm/drvlib: Prevent pagefaults on arm on io mapping

On 15.06.22 10:30, Philippe Gerum wrote: > > Jan Kiszka writes: > >> On 15.06.22 09:54, Philippe Gerum wrote: >>> >>> Jan Kiszka via Xenomai writes: >>> >>>> On 23.05.22 16:04, Gunter Grau via Xenomai wrote: >>>>> From: Gu

Re: [PATCH] rtdm/drvlib: Prevent pagefaults on arm on io mapping

On 15.06.22 09:54, Philippe Gerum wrote: > > Jan Kiszka via Xenomai writes: > >> On 23.05.22 16:04, Gunter Grau via Xenomai wrote: >>> From: Gunter Grau >>> >>> When mapping io memory into userspace an extra simulated pagefault for all >>>

Re: [PATCH 2/2] x86: ipipe: Enable FPU tests unconditionally

On 15.06.22 09:44, Bezdeka, Florian (T CED SES-DE) wrote: > On Tue, 2022-06-14 at 20:11 +0200, Jan Kiszka wrote: >> On 08.06.22 18:59, Bezdeka, Florian (T CED SES-DE) wrote: >>> On Wed, 2022-06-08 at 17:02 +0200, Jan Kiszka wrote: On 25.05.22 11:56, Florian Bezdeka wrote: > Parts of the

Re: [REMINDER] Mailing list rehosting

On 21.05.22 12:48, Philippe Gerum via Xenomai wrote: > > The Xenomai mailing list server will be migrated to [1] on June 18 > 2022. In the meantime, the current server will be operating as > usual. However, the existing subscriptions to xenomai@xenomai.org will > NOT be automatically transferred

Re: [I-PIPE Xenoami3.1 PATCH 2/2] x86/tsc: I-PIPE : notify I-PIPE about updated clockfreq

On 27.05.22 08:22, Hongzhan Chen via Xenomai wrote: > When there is refined tsc clock, notify Xenomai to apply it. Xenomai is conceptually not known to I-pipe. This patch is about calling the well-defined kevent hook when the TSC frequency changes after a recalibration. ARM does something similar

Re: [Cobalt Xenoami3.1 PATCH 1/2] process: update clockfreq when receive corresponding event.

On 27.05.22 08:22, Hongzhan Chen via Xenomai wrote: > 1. When there is clockfreq param passed down via command line, we >do not update clockfreq even if we receive event of updating clockfreq. >Or else, we update the clockfreq with notified value. > 2. At the same time, we would like to

Re: [PATCH 2/2] x86: ipipe: Enable FPU tests unconditionally

On 08.06.22 18:59, Bezdeka, Florian (T CED SES-DE) wrote: > On Wed, 2022-06-08 at 17:02 +0200, Jan Kiszka wrote: >> On 25.05.22 11:56, Florian Bezdeka wrote: >>> Parts of the FPU tests were skipped when one of the following config >>> options was enabled, shadowing a real test issue that was

Re: [PATCH] rtdm/drvlib: Prevent pagefaults on arm on io mapping

On 23.05.22 16:04, Gunter Grau via Xenomai wrote: > From: Gunter Grau > > When mapping io memory into userspace an extra simulated pagefault for all > pages is added to prevent later pagefaults because of copy on write > mechanisms. This happens only on architectures that have defined the >

Re: compile conflict with Boost

On 14.06.22 16:18, Russell Johnson via Xenomai wrote: > From 452e8b2ca8ecd53571a6b1f5d8b9ab23cd67f99d Mon Sep 17 00:00:00 2001 > From: Russell Johnson > Date: Tue, 14 Jun 2022 08:10:14 -0600 > Subject: [PATCH] fixing conflict with C++ [[fallthough]], and maybe at some > point in the future with

Re: [Cobalt Xenoami3.1 PATCH 0/2] notify Xenomai udpated clockfreq.

On 09.06.22 04:06, Chen, Hongzhan wrote: >> -Original Message- >> From: Jan Kiszka >> Sent: Wednesday, June 8, 2022 11:21 PM >> To: Chen, Hongzhan ; xenomai@xenomai.org >> Subject: Re: [Cobalt Xenoami3.1 PATCH 0/2] notify Xenomai udpated clockfreq. >> >> On 02.06.22 14:56, Chen, Hongzhan

Re: [PATCH] x86/fpu: fix compile error without kernel_fpu_disabled()

On 26.05.22 18:19, Philippe Gerum wrote: > > jamiens...@163.com writes: > >> From: Jamie Huang >> >> In v5.18-evl-rebase, function kernel_fpu_disabled() has been removed in >> commit 59f5ede3bc0f("x86/fpu: Prevent FPU state corruption"), so we will >> get compile error when CONFIG_DOVETAIL is

Re: [PATCH 2/2] net/drivers: Remove ARM64 restriction for fec driver

On 23.05.22 16:19, Gunter Grau via Xenomai wrote: > From: Johann Wiens > > As described in commit 04fab252f5d2ec3fe47be266f94714c3dda624bd, the > fec driver was added with the intention to have it working on an > i.MX8 target. > But i.MX SoC specific quirks are also handled already since the

Re: [Cobalt Xenoami3.1 PATCH 0/2] notify Xenomai udpated clockfreq.

On 02.06.22 14:56, Chen, Hongzhan wrote: > > >> -Original Message- >> From: Jan Kiszka >> Sent: Thursday, June 2, 2022 5:54 PM >> To: Chen, Hongzhan ; xenomai@xenomai.org >> Subject: Re: [Cobalt Xenoami3.1 PATCH 0/2] notify Xenomai udpated clockfreq. >> >> On 27.05.22 08:22, Hongzhan

Re: [PATCH 1/1] drivers/serial/16550A_pci.h: allow custom baud_base with pci cards

On 27.05.22 23:48, Richard Weinberger via Xenomai wrote: > On Fri, May 27, 2022 at 11:35 PM Konstantin Smola via Xenomai > wrote: >> >> pci probe was overwriting baud_base with default values, ignoring baud_base >> arguments passed in while loading driver. >> >> Signed-off-by: Konstantin Smola

Re: [PATCH 2/2] x86: ipipe: Enable FPU tests unconditionally

On 25.05.22 11:56, Florian Bezdeka wrote: > Parts of the FPU tests were skipped when one of the following config > options was enabled, shadowing a real test issue that was triggered by > high load on the system. The options: > - CONFIG_X86_USE_3DNOW > - CONFIG_MD_RAID456 > -

Re: [PATCH] switchtest: Cleanup FPU tests after ipipe -> dovetail transition

On 25.05.22 09:47, Florian Bezdeka wrote: > FPU usage in kernel space was allowed / enabled with ipipe, but is no > longer available for dovetail based kernels. That allows us to clean > up the FPU related tests of the switchtest utility. > > fp_kernel_supported() can be removed as all supported

Re: [Cobalt Xenoami3.1 PATCH 0/2] notify Xenomai udpated clockfreq.

On 27.05.22 08:22, Hongzhan Chen via Xenomai wrote: > When there is refined tsc clock, notify Xenomai to apply it. > Linux may schedule a delayed work to refine tsc clock and update > tsc_khz which happen after Xenomai finsih init but tsc_scale and > tsc_shift still keep the value depending on

Re: [RFC] Rust API for evl

On 31.05.22 15:37, Philippe Gerum via Xenomai wrote: > > I've been getting my feet wet with Rust for a few weeks now, assessing > the real-time latency figures I could get from an existing (C++) > application once fully rewritten in this language. It turned out that > performance was on par with

Re: Reminder: Xenomai community call on Wednesday, Jun 1, 2022, UTC 7:00 AM

On 01.06.22 05:22, Chen, Hongzhan via Xenomai wrote: > > We have the Xenomai community call today. > > Topics may include but are not limited to upstream/downstream project > plans, status updates, and technical discussions. It's an open online > meeting that anyone can join and ask questions.

Re: [PATCH] cobalt: ipipe: intr: Fix return value check of ipipe_set_irq_affinity

On 20.05.22 16:29, Gunter Grau via Xenomai wrote: > From: Julian Haller > > ipipe_set_irq_affinity directly returns the value of the regular > irq_set_affinity method. As described in irq.h in the linux kernel, > the following return values indicate a success: > > /* > * Return value for

Re: [PATCH] x86/fpu: fix compile error without kernel_fpu_disabled()

On 16.05.22 17:59, Bezdeka, Florian via Xenomai wrote: > On Mon, 2022-05-16 at 23:32 +0800, Jamie Huang via Xenomai wrote: >> From: Jamie > > It's up to Jan but I guess a complete name would be nice here. Same > fore the Signed-off-by below. Philippe is maintaining the dovetail tree but, yes,

Re: Machine freezes under Ubuntu 20.04

On 16.05.22 16:22, Arturo Laurenzi wrote: > Il giorno lun 16 mag 2022 alle ore 15:56 Arturo Laurenzi > ha scritto: >> >>> The call-stack is not reported as fully reliable. Are you running with >>> CONFIG_DEBUG_INFO=y? Do you have CONFIG_UNWINDER_ORC=y? >>> >>> Assuming it is reliable, we may try

Re: Wrong CPU count on Apollo Lake platform

On 20.05.22 13:41, dabbede--- via Xenomai wrote: > Dear Xenomai community, > > I'm writing here because of the following issue: I have compiled a > xenomai-patched kernel that, when used on an Intel Atom E3950 (Apollo > Lake family), return the wrong cpu count (i.e. nproc returns 1 instead > of

Re: RTNet: sendto(): EAGAIN error

On 13.05.22 14:51, Mauro S. via Xenomai wrote: > Il 05/05/22 17:04, Mauro S. via Xenomai ha scritto: >> Il 05/05/22 15:05, Jan Kiszka ha scritto: >>> On 03.05.22 17:18, Mauro S. via Xenomai wrote: Hi all, I'm trying to use RTNet with TDMA. I succesfully set up my bus:

Re: [linux-dovetail][PATCH 0/3] Add TSC function supports and MFD driver for TGPIO

On 18.05.22 19:45, Bezdeka, Florian (T CED SES-DE) wrote: > On Tue, 2022-05-17 at 09:53 +0800, Zqiang via Xenomai wrote: >> The following modifications are mainly to add TSC function for TGPIO >> and add intel-ehl-gpio driver divides and initializes the PSE TGPIO >> resources. >> >> Christopher

Re: 16550A: failed to get the IRQ line free

On 06.05.22 19:32, C Smith via Xenomai wrote: > I have three serial devices connected using 16550A.ko driver. The card > is a Moxa PCI 4-port card, where all ports share IRQ 18. > Several times per minute in dmesg I get : > [Xenomai] xnintr_edge_vec_handler: failed to get the IRQ18 line free > >

Re: [PATCH 1/2] debian: Remove --enable-smp

On 06.05.22 08:55, Richard Weinberger wrote: > - Ursprüngliche Mail - >> Von: "Jan Kiszka" >> On 05.05.22 22:06, Richard Weinberger via Xenomai wrote: >>> ping? :-) >>> >> >> Thanks for the reminder - merged. > > Did you also apply "[PATCH 2/2] doc: Remove references to --enable-smp"? >

Re: [PATCH 1/2] debian: Remove --enable-smp

On 05.05.22 22:06, Richard Weinberger via Xenomai wrote: > ping? :-) > Thanks for the reminder - merged. But "configure --help" itself still talks about "--enable-smp". Should like be changed to "--disable-smp" to reflect the default. Jan > On Wed, Apr 13, 2022 at 2:05 PM Richard Weinberger

Re: Can't compile userspace application with compiler switch -std=c++11 and Xenomai 3.2

On 05.05.22 16:56, Grau, Gunter via Xenomai wrote: > > Hi, > > We are trying to port our application to Xenomai 3.2. > The source is c++ and we use in some parts C++11 elements. Therefore the > compile switch is set to -std=c++11. > When now compiling with this option we see following output

Re: [PATCH v2] utils/net/rtnet.in: fixes after shellcheck inspection

On 05.05.22 17:12, Mauro S. wrote: > Signed-off-by: Mauro Salvini > --- >  utils/net/rtnet.in | 76 +++--- >  1 file changed, 38 insertions(+), 38 deletions(-) > > diff --git a/utils/net/rtnet.in b/utils/net/rtnet.in > index f81a7bb0a..9f136b804 100644 >

Re: RTNet: sendto(): EAGAIN error

On 03.05.22 17:18, Mauro S. via Xenomai wrote: > Hi all, > > I'm trying to use RTNet with TDMA. > > I succesfully set up my bus: > > - 1GBps speed > - 3 devices > - cycle time 1ms > - timeslots with 200us offset > > I wrote a simple application that in parallel receives and sends UDP > packets

Re: [PATCH] utils/net/rtnet.in: fixes after shellcheck inspection

On 03.05.22 10:22, Mauro S. via Xenomai wrote: > Signed-off-by: Mauro Salvini > --- >  utils/net/rtnet.in | 76 +++--- >  1 file changed, 38 insertions(+), 38 deletions(-) > > diff --git a/utils/net/rtnet.in b/utils/net/rtnet.in > index f81a7bb0a..06e796cd2

Re: [PATCH] doc: Fix coreclk typo

On 29.04.22 21:14, Richard Weinberger via Xenomai wrote: > It's coreclk not coreclck. > > Signed-off-by: Richard Weinberger > --- > doc/asciidoc/MIGRATION.adoc | 6 +++--- > doc/asciidoc/man1/autotune.adoc | 8 > 2 files changed, 7 insertions(+), 7 deletions(-) > > diff --git

Re: Interrupt handler illicit call

On 02.05.22 20:08, C Smith wrote: > On Sun, May 1, 2022 at 11:25 PM Jan Kiszka wrote: >> >> On 29.04.22 21:01, Richard Weinberger via Xenomai wrote: >>> On Fri, Apr 29, 2022 at 9:04 AM C Smith via Xenomai >>> wrote: int Lp_port_handler(rtdm_irq_t *irq_handle_p) { static int

Re: Interrupt handler illicit call

On 29.04.22 21:01, Richard Weinberger via Xenomai wrote: > On Fri, Apr 29, 2022 at 9:04 AM C Smith via Xenomai > wrote: >> int Lp_port_handler(rtdm_irq_t *irq_handle_p) >> { >>static int err; >>unsigned long next; >>rtdm_irq_t *handle_p; >> >>handle_p =

Re: [PATCH] utils/net/rtnet.in: add delay during master configuration

On 22.04.22 16:25, Mauro S. via Xenomai wrote: > Some cards are slow to get the connection link up after the > "rtifconfig rteth0 up" command, e.g. on an Atom-x5 with an Intel I210 > (rt_igb driver) I detected approximately 3 seconds to get the link up. > > On master, the "rtifconfig rteth0 up"

Re: Machine freezes under Ubuntu 20.04

On 19.04.22 12:02, Arturo Laurenzi wrote: > Sorry for the delayed answer, it took us some time to instrument our > setup for broadcasting the kernel output over serial, > and now we have some interesting results. > See below. > >> On 05.04.22 15:43, Arturo Laurenzi wrote: On 04.04.22 15:21,

[xenomai-images][PATCH 2/2] ci: Apply DNS hack also on test instances

From: Jan Kiszka We've seen DNS issues with the AWS defaults also on the test jobs. Therefore, expand the scope of the hack to all jobs by generalizing .add-proxy-config to .common-config. Signed-off-by: Jan Kiszka --- ci/gitlab-ci-base.yml | 8 1 file changed, 4 insertions(+), 4

[xenomai-images][PATCH 1/2] Update Isar revision

From: Jan Kiszka Various fixes and better control over sstate. Signed-off-by: Jan Kiszka --- kas.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kas.yml b/kas.yml index 62ddbb4..6b3b32d 100644 --- a/kas.yml +++ b/kas.yml @@ -22,7 +22,7 @@ repos: isar: url:

[xenomai-images][PATCH 0/2] Isar update and CI tuning

See patches for details. Jan Jan Kiszka (2): Update Isar revision ci: Apply DNS hack also on test instances ci/gitlab-ci-base.yml | 8 kas.yml | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) -- 2.34.1

Re: [PATCH v2 0/9] Revive alchemy, pSOS and VxWorks tests

On 14.04.22 17:41, Richard Weinberger wrote: > - Ursprüngliche Mail - >>> Did the nucleus CPU scheduler guarantee that giving another task >>> the same priority of the calling task will favour the caller? >>> Now the gifted task seems to win. >> >> Did you configure with

Re: [PATCH v2 0/9] Revive alchemy, pSOS and VxWorks tests

On 14.04.22 17:13, Richard Weinberger wrote: > - Ursprüngliche Mail - >> Von: "Jan Kiszka" >>> task5 fails: >>> [9] at task-5.c:79 >>> [1] at task-5.c:23 >>> [10] at task-5.c:87 >>> [3] at task-5.c:40 >>> [11] at task-5.c:95 >>> [4] at task-5.c:45 >>> [5] at

Re: [PATCH v2] testsuite: Add test for x86 port io

On 13.04.22 23:59, Richard Weinberger via Xenomai wrote: > Test case for the following regression: > https://www.xenomai.org/pipermail/xenomai/2022-March/047451.html > > Signed-off-by: Richard Weinberger > --- > Changes since v1: > - Make sure to restore SA upon failure. > --- >

Re: [PATCH 3/9] testsuite: Add a simple test driver for alchemytests

On 13.04.22 23:58, Richard Weinberger via Xenomai wrote: > In their current shape, every alchemy test has to be a single > program and does not use the smokey test framework. > > alchemytest_driver uses smokey and runs each test as new process. Maybe rather call this "wrapper" or "loader" -

Re: [PATCH 2/6] testsuite: Hook up alchemytests

On 14.04.22 13:17, Richard Weinberger wrote: > On Thu, Apr 14, 2022 at 1:12 PM Jan Kiszka via Xenomai > wrote: >> With only up to here applied: >> >> make[2]: Entering directory 'xenomai/build/testsuite/alchemytests' >> make[2]: *** No rule to make target

Re: [PATCH v2 0/9] Revive alchemy, pSOS and VxWorks tests

On 13.04.22 23:58, Richard Weinberger via Xenomai wrote: > This patch series is a first attempt to integrate the currently abandoned > alchemy, pSOS and VxWorks tests into Xenomai's test suite. > Since each test assumes running as own process a test driver is needed > which executes each tests

Re: [PATCH 2/6] testsuite: Hook up alchemytests

On 08.04.22 10:03, Richard Weinberger via Xenomai wrote: > Build them using Xenomai's build system. > > Signed-off-by: Richard Weinberger > --- > configure.ac | 1 + > testsuite/Makefile.am | 6 +- > testsuite/alchemytests/Makefile.am | 148

Re: [PATCH 0/6] Revive alchemy tests

On 13.04.22 16:14, Richard Weinberger wrote: > - Ursprüngliche Mail - >> Von: "Jan Kiszka" >> An: "richard" , "xenomai" >> Gesendet: Mittwoch, 13. April 2022 14:56:16 >> Betreff: Re: [PATCH 0/6] Revive alchemy tests > >> On 08.04.22 10:03, Richard Weinberger via Xenomai wrote: >>> This

Re: Does Xenomai 3.2.x work with 4.14.x kernels?

On 13.04.22 11:25, Scott Reed via Xenomai wrote: > Hello, > > I am trying to build a 4.14.110 kernel+ipipe+xenomai_3.2.7 and running into > issues when trying to compile. Namely, the 4.14.x kernel does not seem > to understand the "__kernel_timespec" struct. > > Is it known if Xenomai 3.2.x

Re: Analogy supported DAQ

On 12.04.22 18:36, Ivan F. Valerio via Xenomai wrote: > Hello, > > I am looking to use Xenomai's analogy to connect my application to a NI > PCIe DAQ card. I found your list of supported hardware for analogy, and > the only PCIe found in your list are no longer supported by National >

Re: [PATCH 0/6] Revive alchemy tests

On 08.04.22 10:03, Richard Weinberger via Xenomai wrote: > This patch series is a first attempt to integrate the currently abandoned > alchemy tests into Xenomai's test suite. > Since each test assumes running as own process a test driver is needed > which executes each tests separately. > The

Re: [PATCH] configure.ac: Enable SMP by default

On 08.04.22 10:59, Richard Weinberger via Xenomai wrote: > In 2022 it is hard to find ARM or x86 systems without SMP. > Other CPU architectures are no longer supported by Xenomai. > So, make SMP support opt-out. > > Signed-off-by: Richard Weinberger > --- > configure.ac | 7 ++- > 1 file

Re: [PATCH 5/5] drivers: ipc: enable non-blocking write from regular threads

On 06.04.22 17:56, Philippe Gerum via Xenomai wrote: > From: Philippe Gerum > > Regular threads should be allowed to write to RTIPC sockets provided > MSG_DONTWAIT is implicitly set for such a request. This would match > the existing behavior with other synchronization objects, such as >

Re: [PATCH 1/5] cobalt/events: add auto-clear feature

On 07.04.22 19:09, Philippe Gerum wrote: > > Jan Kiszka writes: > >> On 07.04.22 13:16, Philippe Gerum wrote: >>> >>> Jan Kiszka writes: >>> On 06.04.22 17:56, Philippe Gerum via Xenomai wrote: > From: Philippe Gerum > > The current implementation does not atomically

[Call for Participation] Xenomai Community Meet-Up

The Xenomai community is planning to hold a virtual meet-up with presentations and live discussions on May 25th. To accommodate for different time zones, the meet-up will be split into an Asian morning session, followed by a European one. Sessions will be recorded as well and shared afterwards.

Re: 5.10-dovetail regression?

On 07.04.22 17:24, Philippe Gerum wrote: > > Jan Kiszka writes: > >> Hi Philippe, >> >> does this already ring some bell? >> >> https://source.denx.de/Xenomai/xenomai-images/-/jobs/419210 >> >> Only triggers with qemu-amd64, not on real HW and not with 5.15. >> > > I could not reproduce

Re: [PATCH 1/5] cobalt/events: add auto-clear feature

On 07.04.22 13:16, Philippe Gerum wrote: > > Jan Kiszka writes: > >> On 06.04.22 17:56, Philippe Gerum via Xenomai wrote: >>> From: Philippe Gerum >>> >>> The current implementation does not atomically consume+clear the event >>> set to be received by the waiter(s), which makes it useless for

5.10-dovetail regression?

Hi Philippe, does this already ring some bell? https://source.denx.de/Xenomai/xenomai-images/-/jobs/419210 Only triggers with qemu-amd64, not on real HW and not with 5.15. Jan -- Siemens AG, Technology Competence Center Embedded Linux

Re: [PATCH 5/5] drivers: ipc: enable non-blocking write from regular threads

On 06.04.22 17:56, Philippe Gerum via Xenomai wrote: > From: Philippe Gerum > > Regular threads should be allowed to write to RTIPC sockets provided > MSG_DONTWAIT is implicitly set for such a request. This would match > the existing behavior with other synchronization objects, such as >

Re: [PATCH 2/5] cobalt/events: add single-waiter delivery mode

On 06.04.22 17:56, Philippe Gerum via Xenomai wrote: > From: Philippe Gerum > > Allow for sending a set of event bits to the heading waiter only, > instead of broadcasting them to all waiters. > > This change affects the ABI, since we add a set of operation flags to > the cobalt_event_sync

Re: [PATCH 1/5] cobalt/events: add auto-clear feature

On 06.04.22 17:56, Philippe Gerum via Xenomai wrote: > From: Philippe Gerum > > The current implementation does not atomically consume+clear the event > set to be received by the waiter(s), which makes it useless for > anything but a plain one-time latch due to the race window this opens > with

Re: [PATCH] Remove __work from PIPELINE_INBAND_WORK_INITIALIZER

On 06.04.22 23:06, Richard Weinberger via Xenomai wrote: > ipipe took a copy of the queued work, __work was used to determine how much > bytes had to get copied. > With dovetail no copy as taken and the __work parameter is no longer > useful, so we can get rid of it. > > Signed-off-by: Richard

Re: pthread_cancel services not documented

On 07.04.22 10:20, Yunjie Gu via Xenomai wrote: > Hi All, > > I'm trying to use xenomai with posix interface, and I found some > differences in the documentation for xenomai 2 and xenomai 3. In xenomai > 2, pthread_cancel related services (including pthread_setcancelstate, .etc) > are clearly

Re: [PATCH v2] x86: dovetail: reinstate I/O bitmap on user entry

On 06.04.22 11:13, Wolfgang Denk via Xenomai wrote: > Dear Philippe, > > In message <87ee2colqg@xenomai.org> you wrote: >> >>> BTW: Do you have a Patchwork instance for the Xenomai mailing list? >> >> Unfortunately not. >> >>> I makes dealing with patch >>> series so much easier. >>> >>> Or

Re: [PATCH] xnthread_relax: Make sure wakework irq work has a stack

On 05.04.22 19:23, Richard Weinberger wrote: > - Ursprüngliche Mail - >>> How about additionally widening the suspected race window by adding a >>> delay to lostage_task_wakeup? >> >> Excellent idea! :-) > > Yeah, with a dealy in lostage_task_wakeup() my WARN_ON_ONCE() triggers > very

Re: [PATCH] xnthread_relax: Make sure wakework irq work has a stack

On 05.04.22 17:53, Richard Weinberger wrote: > - Ursprüngliche Mail - >> Von: "Jan Kiszka" >> I would like to have an explanation or prove points (traces, assertions) >> that we actually see xnthread_relax overtaking the delivery of its own >> wakework. > > I can re-test with something

Re: [PATCH] xnthread_relax: Make sure wakework irq work has a stack

On 05.04.22 15:10, Richard Weinberger wrote: > On Tue, Apr 5, 2022 at 3:02 PM Bezdeka, Florian via Xenomai > wrote: >> I'm not sure if waiting is really what we want. I like the idea of >> moving the work into struct xnthread as Jan already suggested >> internally. > > Well, the wait is cheap,

Re: Machine freezes under Ubuntu 20.04

On 05.04.22 15:43, Arturo Laurenzi wrote: >> On 04.04.22 15:21, Arturo Laurenzi via Xenomai wrote: > >>> >>> Recently, we have started a transition towards Ubuntu 20.04, and things >>> have started to break. >>> >>> The first attempt was to install kernel 5.4.151 and stick to ipipe. Under >>>

Re: Machine freezes under Ubuntu 20.04

On 04.04.22 15:21, Arturo Laurenzi via Xenomai wrote: > Dear Xenomai community, > in our lab we use Xenomai + RTnet to control complex EtherCAT-based robotic > platforms (research prototypes). > > Our infrastructure is made of two multi-threaded processes, let's say A and > B, as follows. > >

Re: [PATCH] Alchemy: Fix rt_task_unblock() for RT_MUTEX

On 04.04.22 14:17, Richard Weinberger wrote: > - Ursprüngliche Mail - >> Von: "Jan Kiszka" >> An: "richard" , "xenomai" >> Gesendet: Montag, 4. April 2022 13:21:45 >> Betreff: Re: [PATCH] Alchemy: Fix rt_task_unblock() for RT_MUTEX > >> On 30.03.22 22:16, Richard Weinberger via Xenomai

Re: [PATCH] Alchemy: Fix rt_task_unblock() for RT_MUTEX

On 30.03.22 22:16, Richard Weinberger via Xenomai wrote: > Starting with Xenomai 3, RT_MUTEX is based on libcobalt's pthread mutex > implementation. > POSIX requires that pthread_mutex_lock() shall not return EINTR, > this requirement breaks rt_task_unblock() if a RT_TASK blocks on > a RT_MUTEX. >

Re: [PATCH] Alchemy: Fix rt_task_unblock() for RT_MUTEX

On 04.04.22 11:39, Richard Weinberger via Xenomai wrote: > On Fri, Apr 1, 2022 at 9:16 AM Bezdeka, Florian via Xenomai > wrote: >>> With my changes at least the application works again and the tests >>> on the customer side pass. >> >> We would need such / similar tests as well inside the Xenomai

dovetail-5.10: build-breakage on ARM

Hi Philippe, likely by accident: 5.10-dovetail-rebase lost disable_irq_if_pipelined / enable_irq_if_pipelined macros. 5.16 was affected as well, 5.15 and 5.17 are not. Jan -- Siemens AG, Technology Competence Center Embedded Linux

Re: xeno-test fails when kernel 64bit userland 32bit

On 25.03.22 14:01, Paal Tamas wrote: >   > > Jan Kiszka írta: > > On 25.03.22 13:26, Paal Tamas via Xenomai wrote: > > Dear All, > > I am using xenomai_3.2.1 with kernel 5.10-dovetail on x86_64 platform.  > I compile the kernel to 64bit, but I need to have the userspace as 32bit. So 

Re: xeno-test fails when kernel 64bit userland 32bit

On 25.03.22 13:26, Paal Tamas via Xenomai wrote: > Dear All, > I am using xenomai_3.2.1 with kernel 5.10-dovetail on x86_64 platform. I > compile the kernel to 64bit, but I need to have the userspace as 32bit. So I > configured the userspace compilation the following way: > ./configure

Re: Bug in xenomai 3.2.x on ARM

On 22.03.22 18:31, Greg Gallagher via Xenomai wrote: > On Tue, Mar 22, 2022 at 12:49 PM François Legal via Xenomai < > xenomai@xenomai.org> wrote: > >> Hello, >> >> trying to port a running Xenomai 3.1.x/Linux 4.4.x system to Xenomai >> 3.2.x/Linux 4.4.x running on Zynq7000, I found a (maybe) bug

Re: [rtnet] kernel bug during slave configuration

On 21.03.22 17:25, Jan Kiszka via Xenomai wrote: > On 21.03.22 15:40, Mauro via Xenomai wrote: >> Hi all, >> >> I'm using Xenomai 3.1.2 on a Intel Atom x5-E8000 64bit with an Intel >> I210 gigabit ethernet controller. Linux kernel is 5.4.181. >> >> I hav

Re: [rtnet] kernel bug during slave configuration

On 21.03.22 15:40, Mauro via Xenomai wrote: > Hi all, > > I'm using Xenomai 3.1.2 on a Intel Atom x5-E8000 64bit with an Intel > I210 gigabit ethernet controller. Linux kernel is 5.4.181. > > I have two identical devices, one configured as master: > > - > $ cat /etc/rtnet.conf >

Re: [PATCH] ipipe: noarch: Fix handling of PCIe MSI interrupts for dwc PCIe controller

On 18.03.22 17:53, Scott Reed wrote: > Handling of PCIe MSI interrupts resulted in system > hanging or high latencies. > > Fix is to replaced missed call to generic_handle_irq with > ipipe_handle_irq(). > > Signed-off-by: Scott Reed > --- > drivers/pci/controller/dwc/pcie-designware-host.c | 2

Re: System hang on first PCIe MSI interrupt with I-pipe kernels newer than 4.14.62

On 17.03.22 16:24, Scott Reed wrote: > > > On 3/16/22 11:35 AM, Jan Kiszka wrote: >> On 16.03.22 10:58, Scott Reed wrote: >>> >>> >>> On 3/15/22 9:42 AM, Scott Reed via Xenomai wrote: On 3/15/22 7:32 AM, Jan Kiszka wrote: > On 14.03.22 18:45, Scott Reed wrote: >> >>

Re: System hang on first PCIe MSI interrupt with I-pipe kernels newer than 4.14.62

On 16.03.22 10:58, Scott Reed wrote: > > > On 3/15/22 9:42 AM, Scott Reed via Xenomai wrote: >> >> >> On 3/15/22 7:32 AM, Jan Kiszka wrote: >>> On 14.03.22 18:45, Scott Reed wrote: On 3/11/22 2:13 PM, Scott Reed via Xenomai wrote: > > On 3/11/22 12:38 PM, Jan Kiszka wrote:

Re: CONFIG_NO_HZ_FULL = y but still have arch-timer on isolation CPUs

On 15.03.22 05:01, Ivan Jiang via Xenomai wrote: > Dear Guys: > > > >    I’ve set the configs like this > >    CONFIG_NO_HZ_FULL = y > > CONFIG_RCU_NOCB_CPU=y > > CONFIG_PREEMPT=y > > CONFIG_CPU_IDLE=n > > CONFIG_ARM_CPUIDLE=n > > CONFIG_CPU_FREQ=n > > And setenv isolcpus=1

Re: waitqueue vs. mutex behavior

On 15.03.22 19:27, Matt Klass via Xenomai wrote: > Using Xenomai 3.0.10, with kernel 4.9.128-05789, on armv7, we're having > problems with the functionality of rtdm_waitqueues. The code was written by > a Xenomai-adept developer who has since left for greener pastures. > > We have two functions

[PATCH] arm64: ipipe: Fix section mismatch of __ipipe_tsc_register

From: Jan Kiszka The kernel warns: The function dw_apb_clocksource_register() references the function __init __ipipe_tsc_register(). This is often because dw_apb_clocksource_register lacks a __init annotation or the annotation of __ipipe_tsc_register is wrong. Signed-off-by: Jan Kiszka ---

[PATCH] arm64: ipipe: Make erratum_1418040_thread_switch compatible with I-pipe

From: Jan Kiszka First of all, this erratum hook is called from __switch_to, thus potentially also from the primary domain. Some of the functions it calls check if preemption was disabled under Linux - which may not be the case when invoked from primary domain. Rather than adding a costly check

Re: ipipe-5.4: arm64 regression

On 14.03.22 14:02, Greg Gallagher wrote: > > > On Mon, Mar 14, 2022 at 8:33 AM Jan Kiszka > wrote: > > On 04.03.22 00:45, Greg Gallagher wrote: > > > > > > On Thu, Mar 3, 2022 at 1:20 PM Jan Kiszka > >

Re: ipipe-5.4: arm64 regression

On 14.03.22 14:02, Greg Gallagher wrote: > > > On Mon, Mar 14, 2022 at 8:33 AM Jan Kiszka > wrote: > > On 04.03.22 00:45, Greg Gallagher wrote: > > > > > > On Thu, Mar 3, 2022 at 1:20 PM Jan Kiszka > >

Re: [PATCH v8 0/4] Kernel-Shark and libtraceevent plugins

On 15.03.22 02:32, Chen, Hongzhan wrote: > Looks good to me. Thanks for your help. > Thanks for your effort! The last "few percentages" to get autoconf/automake integration were indeed tougher than I thought. Jan > Regards > > Hongzhan Chen > > -Original Message- > From: Jan Kiszka

Re: [PATCH] cobalt/sched: Use nr_cpumask_bits instead of BITS_PER_LONG

On 14.03.22 22:13, Bezdeka, Florian via Xenomai wrote: > On Mon, 2022-03-14 at 21:05 +, Bezdeka, Florian via Xenomai wrote: >> Hi Richard, >> >> On Mon, 2022-03-14 at 21:38 +0100, Richard Weinberger via Xenomai >> wrote: >>> BITS_PER_LONG is too broad, the max number of usable bits is limited

Re: System hang on first PCIe MSI interrupt with I-pipe kernels newer than 4.14.62

On 14.03.22 18:45, Scott Reed wrote: > > > On 3/11/22 2:13 PM, Scott Reed via Xenomai wrote: >> >> On 3/11/22 12:38 PM, Jan Kiszka wrote: >>> On 11.03.22 11:12, Scott Reed via Xenomai wrote: Hello, I am seeing an apparent issue with PCIe MSI interrupts and I-pipe when trying

Re: ipipe-5.4: arm64 regression

On 04.03.22 00:45, Greg Gallagher wrote: > > > On Thu, Mar 3, 2022 at 1:20 PM Jan Kiszka > wrote: > > On 02.03.22 16:44, Greg Gallagher wrote: > > > > > > On Wed, Mar 2, 2022 at 1:48 AM Jan Kiszka > >

  1   2   3   4   5   6   7   8   9   10   >