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

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 FPU tests were skipped when one of the following config > >

Re: compile conflict with Boost

On Tue, 2022-06-14 at 11:01 +0200, Philippe Gerum via Xenomai wrote: > Julien Blanc writes: > > > Le mardi 14 juin 2022 à 10:04 +0200, Philippe Gerum a écrit : > > > Julien Blanc < > > > julien.bl...@sprinte.eu > > > > writes: > > > > > > > Le mardi 14 juin 2022 à 08:54 +0200, Philippe Gerum a

Re: compile conflict with Boost

On Tue, 2022-06-14 at 08:29 +, Julien Blanc via Xenomai wrote: > Le mardi 14 juin 2022 à 10:04 +0200, Philippe Gerum a écrit : > > Julien Blanc < > > julien.bl...@sprinte.eu > > > writes: > > > > > Le mardi 14 juin 2022 à 08:54 +0200, Philippe Gerum a écrit : > > > > Julien Blanc via Xenomai

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

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 triggered by > > high load on the system. The options: > > -

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

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 Hall (1): > x86/tsc: Add TSC support functions to support ART

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

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. > > In v5.18-evl-rebase, function kernel_fpu_disabled() has been removed in > commit 59f5ede3bc0f("x86/fpu: Prevent

Re: Register (or stack) corruption: Xenomai 3.2.1 on 4.19-ipipe

On Tue, 2022-05-03 at 10:41 +, Bezdeka, Florian via Xenomai wrote: > Hi all, > > it seems that I'm able to reproduce a register (or stack) corruption on > x86. > > The problem does not appear when running the Xenomai testsuite > (especially switchtest) without any addit

Re: Register (or stack) corruption: Xenomai 3.2.1 on 4.19-ipipe

On Tue, 2022-05-03 at 10:41 +, Bezdeka, Florian via Xenomai wrote: > Hi all, > > it seems that I'm able to reproduce a register (or stack) corruption on > x86. > > The problem does not appear when running the Xenomai testsuite > (especially switchtest) without any addit

Register (or stack) corruption: Xenomai 3.2.1 on 4.19-ipipe

Hi all, it seems that I'm able to reproduce a register (or stack) corruption on x86. The problem does not appear when running the Xenomai testsuite (especially switchtest) without any additional load. Stressing Linux with stress-ng makes the test fail. Kernel: 4.19.231-cip68 Xenomai: 3.2.1

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

On Tue, 2022-04-26 at 16:24 +0200, Mauro S. wrote: > Hi Florian, > > thanks for your comments. See below mine. > > Il 23/04/22 19:26, Florian Bezdeka ha scritto: > > Hi all, > > > > some minor comments, see below: [snip] > > > > > > +    The parameter -d allows to introduce a delay in

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

On Thu, 2022-04-14 at 14:58 +0200, Richard Weinberger via Xenomai wrote: > - Ursprüngliche Mail - > > Von: "Jan Kiszka" > > An: "richard" , "xenomai" > > Gesendet: Donnerstag, 14. April 2022 13:18:59 > > Betreff: Re: [PATCH v2 0/9] Revive alchemy, pSOS and VxWorks tests > > > On

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

Hi Richard, On Fri, 2022-04-08 at 10:03 +0200, Richard Weinberger via Xenomai wrote: > +static int __run_extprog(struct smokey_test *t, int argc, char *const argv[]) > +{ > + int ret; > + char *tst_path; > + > + ret = asprintf(_path, "%s/%s --cpu-affinity=0", mydir, t->name); > +

Re: [PATCH] Remove __work from PIPELINE_INBAND_WORK_INITIALIZER

Hi Richard, On Wed, 2022-04-06 at 23:06 +0200, 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 ^^ is >

Re: Reminder: Xenomai community call on Wednesday, Apr 06, 2022, UTC 7:00 AM

On Wed, 2022-04-06 at 04:54 +, 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

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

On Tue, 2022-04-05 at 13:40 +0200, Richard Weinberger wrote: > While testing some workload the following KASAN splat arose. > irq_work_single+0x70/0x80 is the last line of irq_work_single(): > (void)atomic_cmpxchg(>node.a_flags, flags, flags & ~IRQ_WORK_BUSY); > > So, writing to >node.a_flags

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

On Thu, 2022-03-31 at 10:36 +0200, Richard Weinberger wrote: > - Ursprüngliche Mail - > > Von: "Florian Bezdeka" > > I can't say much about the alchemy skin. Never used that myself. Have > > you checked the history if such a change was / could be intentional? > > CCing Jan... > > Well,

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

Hi Richard, On Wed, 2022-03-30 at 22:16 +0200, 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

Re: RTNET setup issue

On Thu, 2022-03-24 at 16:27 +0100, Paal Tamas wrote: > > I started the debug session using the rtifconfig.c file, since the > > rtifconfig command "fails fine". I added some trace to the > > rtifconfig.c (into the do_display() function) and rtnet_chrdev.c > > (into the rtnet_core_ioctl() function)

Re: RTNET setup issue

On Wed, 2022-03-23 at 16:02 +0100, Paal Tamas via Xenomai wrote: > > Paal Tamas via Xenomai írta: > > > > "François Legal" írta: > > > Le Mercredi, Mars 23, 2022 14:07 CET, Paal Tamas a > > > écrit: > > > > > > > > > > > "François Legal" írta: > > > > > Le Mercredi, Mars 23, 2022 10:48

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

On Mon, 2022-03-14 at 22:10 +0100, Richard Weinberger wrote: > - Ursprüngliche Mail - > > Von: "Florian Bezdeka" > > I agree, BITS_PER_LONG seems wrong. But couldn't it be too small as > > well? It depends on NR_CPUS which might be > BITS_PER_LONG. > > Hmm, nr_cpumask_bits is defined as:

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

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 > > by nr_cpumask_bits. > >

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

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 > by nr_cpumask_bits. I agree, BITS_PER_LONG seems wrong. But couldn't it be too small as well? It depends on NR_CPUS which might be >

Re: Questiion on commit: demo/cyclictest: fix time delta calculation

Hi Richard, On Fri, 2022-03-04 at 12:35 +0100, Richard Weinberger via Xenomai wrote: > Hello, > > I'm investigating into a cyclictest issue where it reports negative values > just like this commit states: > https://source.denx.de/Xenomai/xenomai/-/commit/3069a7bbc48559f4d2a6184d6159b771f193a4e9

Re: [PATCH v2 3/3] libtraceevent: Add xenomai_schedparams plugin for libtraceevent

On Tue, 2022-03-01 at 21:57 -0500, Hongzhan Chen via Xenomai wrote: > For cobalt thread, there is special struct param_ex data stored in > data record, we need to parse and print its content out correctly > to hint user. > > Signed-off-by: Hongzhan Chen > --- > configure.ac

Re: [PATCH 1/1] Added verbosity to 16550A serial driver. dmesg shows the ports, irqs, baudbases.

On Sun, 2022-01-23 at 00:18 -0800, Konstantin Smola via Xenomai wrote: > kernel/drivers/serial: Added verbosity to 16550A serial driver. dmesg shows > the ports, irqs, baudbases. > Signed-off-by: Konstantin Smola > --- > kernel/drivers/serial/16550A.c | 3 +++ > 1 file changed, 3 insertions(+)

Re: [PATCH] cobalt: Fix resource leak of cobalt_monitor

On Thu, 2022-01-20 at 09:12 +0100, Philippe Gerum wrote: > Florian Bezdeka writes: > > > We have a test within the smokey testsuite which actually does > > something like > > > >cobalt_monitor_init() > >cobalt_monitor_wait() > >cobalt_monitor_enter() > > -> timeout > >

Re: Dovetail 5.10 - Xenomai huge page support

On Thu, 2022-01-20 at 09:32 +0100, Philippe Gerum wrote: > "Bezdeka, Florian" writes: > > > On Wed, 2022-01-19 at 13:35 +0000, Bezdeka, Florian via Xenomai wrote: > > > Hi all, > > > > > > after migrating from 4.19-ipipe to 5.10-dovetail int

Re: Dovetail 5.10 - Xenomai huge page support

On Wed, 2022-01-19 at 13:35 +, Bezdeka, Florian via Xenomai wrote: > Hi all, > > after migrating from 4.19-ipipe to 5.10-dovetail internal users are > reporting that they receive sporadic SIGXCPUs. The reported reason is > "page_fault_user".  > > After disablin

Dovetail 5.10 - Xenomai huge page support

Hi all, after migrating from 4.19-ipipe to 5.10-dovetail internal users are reporting that they receive sporadic SIGXCPUs. The reported reason is "page_fault_user".  After disabling the huge page support in 5.10 the issue vanished. Tests are still running, but we are optimistic that we found the

Re: [PATCH] libtraceevent: Add new xenomai plugin to print param_ex correctly

On Mon, 2022-01-17 at 21:47 -0500, Hongzhan Chen via Xenomai wrote: > For cobalt thread, there is special struct param_ex data stored in > data record, we need to parse and print its content out correctly > to hint user. > > Signed-off-by: Hongzhan Chen > > diff --git a/plugins/Makefile

Re: [xenomai-images][PATCH v4 0/8] Update CI and kconfig for next and stable/3.2.x

On Fri, 2022-01-07 at 16:02 +0100, Jan Kiszka via Xenomai wrote: > Changes in v4: > - clean up CI variable interface and documentation > > This accounts for change in Xenomai next as well as the fork-off of > stable/3.2.x. And it simplifies our gitlab-ci configuration as bit. Can we simplify

Re: [PATCH 0/7] y2038: cond_wait_prologue64 and related fixes

On Wed, 2022-01-05 at 15:58 +0100, Jan Kiszka wrote: > On 05.01.22 15:56, Bezdeka, Florian (T CED SES-DE) wrote: > > On Wed, 2022-01-05 at 15:43 +0100, Jan Kiszka wrote: > > > On 05.01.22 15:06, Florian Bezdeka wrote: > > > > Hi all, > > > > > > > > this is the last missing POSIX related y2038

Re: [PATCH 0/7] y2038: cond_wait_prologue64 and related fixes

On Wed, 2022-01-05 at 15:43 +0100, Jan Kiszka wrote: > On 05.01.22 15:06, Florian Bezdeka wrote: > > Hi all, > > > > this is the last missing POSIX related y2038 affected syscall in > > Xenomai. With this applied we have two Xenomai specific syscalls > > missing: > > > > -

Re: [PATCH 0/4] Drop PowerPC architecture

On Wed, 2021-12-15 at 19:04 +0100, Jan Kiszka via Xenomai wrote: > Citing patch 1: > > While this architecture served well in many use cases over a long time, > it's time is over, new chip chips are no longer being released. > > As Xenomai is moving its core completely over Dovetail, there is no

Re: [PATCH 0/5] Remove support for I-pipe / kernels < 5.10

On Mon, 2021-12-20 at 11:37 +, Bezdeka, Florian via Xenomai wrote: > On Thu, 2021-12-16 at 16:48 +0100, Jan Kiszka via Xenomai wrote: > > Move forward and cut off the ropes that binds us to I-pipe kernels, thus > > anything older than 5.10. > > > > This series prima

Re: [PATCH 0/5] Remove support for I-pipe / kernels < 5.10

On Thu, 2021-12-16 at 16:48 +0100, Jan Kiszka via Xenomai wrote: > Move forward and cut off the ropes that binds us to I-pipe kernels, thus > anything older than 5.10. > > This series primarily removes no longer used files and kernel version > wrappings. It does not yet fold dovetail code into

Re: [PATCH 1/1] Examples demonstrating .mmap() in RTDM driver

Hi Konstantin, On Sun, 2021-12-19 at 23:13 -0800, Konstantin Smola via Xenomai wrote: > +#ifndef PAGE_SIZE > +#define PAGE_SIZE 4096 > +#endif > + > +typedef struct { /* memory to share */ > + int data[PAGE_SIZE * 100]; > + double dval; > +} shm_test_layout_t; Hm... First of

Re: [xenomai-images] [PATCH 1/1] Changes to support sbuild-based Isar

On Thu, 2021-12-09 at 09:43 +, Bezdeka, Florian via Xenomai wrote: > On Thu, 2021-12-09 at 09:42 +0000, Bezdeka, Florian via Xenomai wrote: > > On Thu, 2021-12-09 at 08:36 +0100, Uladzimir Bely via Xenomai wrote: > > > These patch is required to build Isar from 'ubely/sbuild'

Re: [xenomai-images] [PATCH 1/1] Changes to support sbuild-based Isar

On Thu, 2021-12-09 at 09:42 +, Bezdeka, Florian via Xenomai wrote: > On Thu, 2021-12-09 at 08:36 +0100, Uladzimir Bely via Xenomai wrote: > > These patch is required to build Isar from 'ubely/sbuild' branch, > > e.g. refspec: 37a71e72c7b8e9ae7e9f6a402ecdc6ff66eab8c4 > >

Re: [xenomai-images] [PATCH 1/1] Changes to support sbuild-based Isar

On Thu, 2021-12-09 at 08:36 +0100, Uladzimir Bely via Xenomai wrote: > These patch is required to build Isar from 'ubely/sbuild' branch, > e.g. refspec: 37a71e72c7b8e9ae7e9f6a402ecdc6ff66eab8c4 We're using that, so why do we need to patch? Is that related to the new SBUILD feature in ISAR? No way

y2038: select() seems not affected

Hi, when we initially collected all y2038 affected syscalls we putted the select() call on the list [1], which is one of the 4 calls that are still missing. Before starting implementing the missing y2038 safe syscall today, I noticed that this call is not affected at all. There is a struct

Re: error: Building the x86 libraries (32/64bit)

On Sun, 2021-11-21 at 11:58 +, zared kamal via Xenomai wrote: > Dear sir,I try to build libraries for Xenomai kernel 3.1 installtion. > configuartion:linux kernel 4.9.90xenomai 3.1 > > with command: > sicom3@sicom3-VirtualBox:/usr/src/xenomai-3.1$ ./configure --with-core=cobalt >

Re: [PATCH] dovetail: Adjust EXIT_SYSCALL_* values to avoid clash with seccomp

On Thu, 2021-11-11 at 19:57 +0100, Jan Kiszka via Xenomai wrote: > From: Jan Kiszka > > __secure_computing, called by syscall_trace_enter, returns -1 when a > call should be skipped. We must avoid that this is interpreted as > EXIT_SYSCALL_OOB in the dovetail case. > > Fixes, e.g., crashes of

Re: Trying Xenomai3.2 and has some web browser problem

On Thu, 2021-11-11 at 04:46 +, Ando Yuta via Xenomai wrote: > Hello Jan > > Thanks for the reply. > > > x86? > > Sorry I forgot to write the CPU info. > My CPU is x86_64(11th Gen Intel i5) > > > Can you generate a trace (strace or maybe even kernel event trace) of both > > good an bad

Re: [xenomai-images][PATCH v2 3/8] kas: Introduce kas option file for CI builds

On Wed, 2021-11-10 at 14:42 +0100, Jan Kiszka wrote: > On 10.11.21 14:23, Bezdeka, Florian (T RDA IOT SES-DE) wrote: > > On Wed, 2021-10-13 at 14:22 +0200, Jan Kiszka wrote: > > > On 13.10.21 14:17, Florian Bezdeka wrote: > > > > For now the difference between the demo and the "ci image" is the >

Re: [xenomai-images][PATCH v2 3/8] kas: Introduce kas option file for CI builds

On Wed, 2021-10-13 at 14:22 +0200, Jan Kiszka wrote: > On 13.10.21 14:17, Florian Bezdeka wrote: > > For now the difference between the demo and the "ci image" is the > > removed sshd-regen-keys. That reduces the (first) boot time especially > > on low end CI hardware. Helps to stay within LAVA

Re: rtcansend 32-bit

On Fri, 2021-11-05 at 09:14 +0100, Jan Kiszka wrote: > On 05.11.21 08:09, C Smith wrote: > > Please review and accept this patch, which allows 32 bit apps to send > > and receive CAN. It is tested successfully with 32bit and 64bit compiles > > of utils/can/rtcansend.c / and rtcanrecv.c. The compat

Re: rtcansend 32-bit

On Wed, 2021-11-03 at 23:49 -0700, C Smith wrote: > I was able to make the CAN transmit work successfully from my 32 bit > compile of rtcansend.c, by adding rtdm_get_iovec() to the code. I'll > submit a patch once both transmit  and receive are working, but I'm > still having trouble receiving

Re: rtcansend 32-bit

On Wed, 2021-11-03 at 11:46 +0100, Jan Kiszka via Xenomai wrote: > On 03.11.21 07:59, Jan Kiszka wrote: > > On 02.11.21 23:57, C Smith via Xenomai wrote: > > > I added some printf/printk to rtcansend.c as well as rtcan_raw.c: > > > > > > rtcan_raw.c: > > > /* Check size of buffer */ > > >

[dovetail][RFC PATCH 0/5] Investigation summary TSC unsable, netdev watchdog

Hi, with this series I'm trying to summarize some analysis done on the machine that is still affected by some timing issues. See [1] for the old postings (including hardware description). I tried to split the important things from the necessary infrastructure preparation. This should allow us

Re: [PATCH] testsuite/xeno-test: Restore timesyncd running state on smokey failure

On Thu, 2021-10-21 at 14:15 +0200, Jan Kiszka wrote: > On 21.10.21 13:55, Florian Bezdeka wrote: > > We stop systemd-timesyncd before running the smokey testsuite and start > > it again once the smokey tests are complete. As xeno-test has a "set -e" > > we will stop the execution on the first

Re: [PATCH] cobalt/arch/arm: fptest: Add missing SIMD register clobbering

On Thu, 2021-10-07 at 09:58 +0200, Jan Kiszka wrote: > On 06.10.21 23:01, Bezdeka, Florian (T RDA IOT SES-DE) wrote: > > On Wed, 2021-10-06 at 17:19 +0200, Jan Kiszka wrote: > > > From: Jan Kiszka > > > > > > This caused troubles with modern gcc that starts to use those regs for > > > other

Re: irq pipeline: Netdev watchdog triggered

On Mon, 2021-09-06 at 18:16 +0200, Philippe Gerum wrote: > Bezdeka, Florian writes: > > > On Mon, 2021-09-06 at 16:56 +0200, Philippe Gerum wrote: > > > Bezdeka, Florian writes: > > > > > > > Hi, > > > > > > > > here is another IRQ_PIPELINE problem we're facing on on of our quite > > > > big

Re: [PATCH] drivers/testing/switchtest: Properly clean up xnthread on error

On Thu, 2021-10-07 at 16:12 +0200, Jan Kiszka via Xenomai wrote: > From: Jan Kiszka > > Analogously to dfb55d64fc0d. Seems both qualify for stable. > > Signed-off-by: Jan Kiszka > --- > kernel/drivers/testing/switchtest.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git

Re: "switchtest" problem with recent 5.10 dovetail and distro-like kernel config

On Thu, 2021-10-07 at 08:55 +, Bezdeka, Florian via Xenomai wrote: > On Thu, 2021-10-07 at 08:53 +0000, Bezdeka, Florian via Xenomai wrote: > > On Thu, 2021-10-07 at 10:37 +0200, Jan Kiszka wrote: > > > On 05.10.21 17:18, Henning Schild wrote: > > > > Am

Re: "switchtest" problem with recent 5.10 dovetail and distro-like kernel config

On Thu, 2021-10-07 at 08:53 +, Bezdeka, Florian via Xenomai wrote: > On Thu, 2021-10-07 at 10:37 +0200, Jan Kiszka wrote: > > On 05.10.21 17:18, Henning Schild wrote: > > > Am Tue, 5 Oct 2021 16:38:12 +0200 > > > schrieb "Bezdeka, Florian (T RDA IOT SES-DE)"

Re: "switchtest" problem with recent 5.10 dovetail and distro-like kernel config

On Thu, 2021-10-07 at 10:37 +0200, Jan Kiszka wrote: > On 05.10.21 17:18, Henning Schild wrote: > > Am Tue, 5 Oct 2021 16:38:12 +0200 > > schrieb "Bezdeka, Florian (T RDA IOT SES-DE)" > > : > > > > > On Tue, 2021-10-05 at 16:29 +0200, Jan Kiszka via Xenomai wrote: > > > > On 24.09.21 15:31,

Re: [PATCH] cobalt/arch/arm: fptest: Add missing SIMD register clobbering

On Wed, 2021-10-06 at 17:19 +0200, Jan Kiszka wrote: > From: Jan Kiszka > > This caused troubles with modern gcc that starts to use those regs for > other purposes. Seen with gcc-10 on Debian 11 e.g. > > Signed-off-by: Jan Kiszka > --- >

Re: "switchtest" problem with recent 5.10 dovetail and distro-like kernel config

On Tue, 2021-10-05 at 16:29 +0200, Jan Kiszka via Xenomai wrote: > On 24.09.21 15:31, Henning Schild via Xenomai wrote: > > Am Wed, 22 Sep 2021 16:21:54 +0200 > > schrieb Henning Schild via Xenomai : > > > > > Am Wed, 22 Sep 2021 14:36:49 +0200 > > > schrieb Philippe Gerum : > > > > > > >

Re: [PATCH v4 1/3] y2038: cobalt/posix/io: Adding recvmmsg64

On Thu, 2021-09-30 at 10:22 +0800, Song Chen wrote: > Add a syscall specific for recvmmsg64 with 64bit time_t. > > --- > v2: > 1, adjust indentation, different files have different indentation, see >./kernel/cobalt/posix/io.h >./kernel/cobalt/posix/syscall32.h >I followed the function

Re: [PATCH v4 3/3] y2038: testsuite/smokey/y2038: testcase for recvmmsg64

On Thu, 2021-09-30 at 10:22 +0800, Song Chen wrote: > Extending the test suite for recvmmsg64 test. > > Signed-off-by: Song Chen > > --- > v2: > 1, rename variables > 2, remove unnecessary branches > 3, call smokey_check_errno > > v4: > 1, call smokey_check_errno in more scenarios > --- >

Re: [PATCH v4 3/3] y2038: testsuite/smokey/y2038: testcase for recvmmsg64

Hi Song! On Thu, 2021-09-30 at 10:22 +0800, Song Chen wrote: > Extending the test suite for recvmmsg64 test. > > Signed-off-by: Song Chen > > --- > v2: > 1, rename variables > 2, remove unnecessary branches > 3, call smokey_check_errno > > v4: > 1, call smokey_check_errno in more scenarios >

Re: [PATCH v4 1/3] y2038: cobalt/posix/io: Adding recvmmsg64

Hi Song! On Thu, 2021-09-30 at 10:22 +0800, Song Chen wrote: > Add a syscall specific for recvmmsg64 with 64bit time_t. > > --- > v2: > 1, adjust indentation, different files have different indentation, see >./kernel/cobalt/posix/io.h >./kernel/cobalt/posix/syscall32.h >I followed

Re: [PATCH v3 3/3] y2038: testsuite/smokey/y2038: testcase for recvmmsg64

Hi Song, it took some time... I'm just back from vacation. On Mon, 2021-09-13 at 09:46 +0800, Song Chen wrote: > Extending the test suite for recvmmsg64 test. > > Signed-off-by: Song Chen > > --- > v2: > 1, rename variables > 2, remove unnecessary branches > 3, call smokey_check_errno > --- >

Re: 回复： An error occures when installing Xenomai libraries and tools

On Fri, 2021-09-10 at 07:58 +0200, Jan Kiszka wrote: > On 10.09.21 03:08, rany97 wrote: > > Sorry for not replying properly. > > I got Xenomai > > from https://xenomai.org/downloads/xenomai/stable/xenomai-3.1.tar.bz2. > > > > The

Re: An error occures when installing Xenomai libraries and tools

On Thu, 2021-09-09 at 09:00 +0200, Jan Kiszka wrote: > On 09.09.21 08:55, Bezdeka, Florian via Xenomai wrote: > > On Thu, 2021-09-09 at 11:43 +0800, rany97 via Xenomai wrote: > > > Hi, > > > > > > > > > When I run "sudo make install" to

Re: An error occures when installing Xenomai libraries and tools

On Thu, 2021-09-09 at 11:43 +0800, rany97 via Xenomai wrote: > Hi, > > > When I run "sudo make install" to install Xenomai libraries and tools, gcc > reports an error posted below: > >

Re: [PATCH v2 1/3] y2038: cobalt/posix/io: Adding recvmmsg64

On Thu, 2021-09-09 at 10:24 +0800, chensong_2...@189.cn wrote: > > 在 2021/9/8 下午5:03, Bezdeka, Florian 写道: > > On Wed, 2021-09-08 at 11:30 +0800, Song Chen wrote: > > > Add a syscall specific for recvmmsg64 with 64bit time_t. > > > > > > --- > > > v2: > > > 1, adjust indentation, different files

Re: [PATCH v2 1/3] y2038: cobalt/posix/io: Adding recvmmsg64

On Wed, 2021-09-08 at 11:30 +0800, Song Chen wrote: > Add a syscall specific for recvmmsg64 with 64bit time_t. > > --- > v2: > 1, adjust indentation, different files have different indentation, see >./kernel/cobalt/posix/io.h >./kernel/cobalt/posix/syscall32.h >I followed the function

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

Hi Song! On Tue, 2021-09-07 at 15:07 +0800, Song Chen wrote: > Extending the test suite for recvmmsg64 test. > > Signed-off-by: Song Chen > --- > testsuite/smokey/y2038/syscall-tests.c | 135 > + > 1 file changed, 135 insertions(+) > > diff --git

Re: [PATCH 1/3] y2038: cobalt/posix/io: Adding recvmmsg64

On Tue, 2021-09-07 at 15:11 +0800, Song Chen wrote: > Add a syscall specific for recvmmsg64 with 64bit time_t. > > Signed-off-by: Song Chen > --- > include/cobalt/uapi/syscall.h | 1 + > kernel/cobalt/posix/io.c| 15 +++ > kernel/cobalt/posix/io.h| 5 + >

Re: irq pipeline: Netdev watchdog triggered

On Mon, 2021-09-06 at 16:56 +0200, Philippe Gerum wrote: > Bezdeka, Florian writes: > > > Hi, > > > > here is another IRQ_PIPELINE problem we're facing on on of our quite > > big Xenomai machines: > > > > Platform: > > Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz > > 2 Sockets, 6 cores per

Re: irq pipeline: Netdev watchdog triggered

On Mon, 2021-09-06 at 16:56 +0200, Philippe Gerum wrote: > Bezdeka, Florian writes: > > > Hi, > > > > here is another IRQ_PIPELINE problem we're facing on on of our quite > > big Xenomai machines: > > > > Platform: > > Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz > > 2 Sockets, 6 cores per

irq pipeline: Netdev watchdog triggered

Hi, here is another IRQ_PIPELINE problem we're facing on on of our quite big Xenomai machines: Platform: Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz 2 Sockets, 6 cores per socket, 2 threads per core (2 NUMA nodes) As soon as we enable CONFIG_IRQ_PIPELINE the netdev watchdog triggers. There is no

Re: IRQ_PIPELINE: TSC marked as unstable

On Fri, 2021-09-03 at 10:41 +0200, Philippe Gerum wrote: > Philippe Gerum writes: > > > Bezdeka, Florian writes: > > > > > Hi all, > > > > > > I'm able to reproduce the following on two different platforms now, so > > > I assume it's a IRQ_PIPELINE generic issue: > > > > > > Platform A): > >

Re: IRQ_PIPELINE: TSC marked as unstable

On Fri, 2021-09-03 at 10:33 +0200, Philippe Gerum wrote: > Bezdeka, Florian writes: > > > Hi all, > > > > I'm able to reproduce the following on two different platforms now, so > > I assume it's a IRQ_PIPELINE generic issue: > > > > Platform A): > > Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz > > 1

IRQ_PIPELINE: TSC marked as unstable

Hi all, I'm able to reproduce the following on two different platforms now, so I assume it's a IRQ_PIPELINE generic issue: Platform A): Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz 1 Socket, 4 Cores, 1 thread per core Platform B): Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz 2 Sockets, 6 cores per socket,

Re: autotune inside qemu: early shot and segfault

On Fri, 2021-08-27 at 10:31 -0400, Lennart Sorensen wrote: > On Fri, Aug 27, 2021 at 02:15:29PM +0200, Jan Kiszka via Xenomai wrote: > > On 27.08.21 13:39, Bezdeka, Florian (T RDA IOT SES-DE) wrote: > > > Wow, once coredumpctl was installed I got: > > > > > > Stack trace of thread 312: > > >

Re: [PATCH] y2038: testsuite/smokey/y2038: Run tests on y2038 safe kernels only

On Fri, 2021-08-27 at 14:57 +0200, Jan Kiszka wrote: > On 27.08.21 12:02, Florian Bezdeka wrote: > > Especially 4.19 is not 2038 safe and 32 bit kernels do not have > > CONFIG_64BIT_TIME set, which ends up in __kernel_timespec being defined > > in a non y2038 safe way. > > > >

Re: autotune inside qemu: early shot and segfault

On Fri, 2021-08-27 at 14:15 +0200, Jan Kiszka wrote: > On 27.08.21 13:39, Bezdeka, Florian (T RDA IOT SES-DE) wrote: > > On Fri, 2021-08-27 at 12:23 +0200, Jan Kiszka wrote: > > > On 27.08.21 12:22, Bezdeka, Florian (T RDA IOT SES-DE) wrote: > > > > On Fri, 2021-08-27 at 12:03 +0200, Jan Kiszka

Re: autotune inside qemu: early shot and segfault

On Fri, 2021-08-27 at 12:23 +0200, Jan Kiszka wrote: > On 27.08.21 12:22, Bezdeka, Florian (T RDA IOT SES-DE) wrote: > > On Fri, 2021-08-27 at 12:03 +0200, Jan Kiszka wrote: > > > On 27.08.21 11:57, Florian Bezdeka wrote: > > > > Hi all, > > > > > > > > first issue: > > > > > > > > maybe someone

Re: autotune inside qemu: early shot and segfault

On Fri, 2021-08-27 at 12:03 +0200, Jan Kiszka wrote: > On 27.08.21 11:57, Florian Bezdeka wrote: > > Hi all, > > > > first issue: > > > > maybe someone can explain what's going on here. I'm running autotune > > inside qemu (ARM) on an x86_64 host and get the error below. The > > kernel in use

Re: [PATCH v2 7/7] testsuite/smokey/leaks: Adding checks for procfs exports

On Wed, 2021-08-25 at 17:09 +0200, Jan Kiszka wrote: > On 25.08.21 12:32, Florian Bezdeka wrote: > > Make sure that named semaphores as well as mqueues are exported to the > > procfs. > > > > Signed-off-by: Florian Bezdeka > > --- > > testsuite/smokey/leaks/leaks.c | 27

Re: [PATCH v2 0/3] y2038: Adding event_wait64()

On Thu, 2021-08-12 at 15:02 +0800, chensong_2...@189.cn wrote: > > 在 2021/8/11 下午9:36, Florian Bezdeka 写道: > > Hi! > > > > Just another y2038 related syscall, once again based on v1 sent out by > > Song and rebased to current next with some code- and test-cleanups applied. > > > > @Song: > >

Re: [RFC PATCH 1/4] cobalt/registry: Make the root directory for proc exports optional

On Wed, 2021-08-18 at 16:02 +0200, Philippe Gerum wrote: > Bezdeka, Florian writes: > > > On Wed, 2021-08-18 at 15:26 +0200, Philippe Gerum wrote: > > > Florian Bezdeka via Xenomai writes: > > > > > > > Previously the root directory was mandatory, which means that exports > > > > to the proc

Re: [RFC PATCH 1/4] cobalt/registry: Make the root directory for proc exports optional

On Wed, 2021-08-18 at 15:26 +0200, Philippe Gerum wrote: > Florian Bezdeka via Xenomai writes: > > > Previously the root directory was mandatory, which means that exports > > to the proc file system were forced to be located in > > /proc/xenomai/registry///. > > > > The virtual directory is

Re: [RFC PATCH 0/4] Export mqueues to procfs

On Wed, 2021-08-18 at 13:41 +0200, Jan Kiszka wrote: > On 18.08.21 13:24, Florian Bezdeka wrote: > > Hi, > > > > this is another try to make registered mqueues visible. This time by > > exporting them to the procfs, namely to > > /proc/xenomai/registry/mqueue/ > > > > Let me know what you

Re: [PATCH] testsuite/smokey: Fixing a registry leak of the posix_select test

On Fri, 2021-08-13 at 08:59 +0200, Jan Kiszka wrote: > On 12.08.21 18:38, Florian Bezdeka wrote: > > According to POSIX message queues have kernel persistence, which means > > they are not cleaned up until the next reboot. > > > > The test has a mq_unlink() as "precondition", so it will clean up

Re: posix_select seems to leak a registry element

On Thu, 2021-08-12 at 14:45 +0200, Jan Kiszka wrote: > On 12.08.21 14:39, Bezdeka, Florian (T RDA IOT SES-DE) wrote: > > Hi all, > > > > I just noticed that the posix_select test of smokey is leaking one > > registry element: > > > > $ cat /proc/xenomai/registry/usage > > 8/512 > > > > $

posix_select seems to leak a registry element

Hi all, I just noticed that the posix_select test of smokey is leaking one registry element: $ cat /proc/xenomai/registry/usage 8/512 $ /smokey --run=posix_select posix_select OK $ cat /proc/xenomai/registry/usage 9/512 The following diff would fix that, but I assume the resource cleanup

Re: [PATCH v2 3/3] y2038: testsuite/smokey/y2038: Adding testcases for monitor_wait64()

On Wed, 2021-08-11 at 15:36 +0200, Florian Bezdeka wrote: > The time measurement is a bit different to the other y2038 related > measurements we do. Using a monitor with CLOCK_REALTIME requires an > absolute timeout. > > Signed-off-by: Florian Bezdeka > --- Already applied. Can be ignored.

Re: [PATCH v2 2/3] y2038: lib/cobalt/internal: dispatch monitor_wait

On Wed, 2021-08-11 at 15:36 +0200, Florian Bezdeka wrote: > From: Song Chen > > If sizeof time_t bigger than 4, which means glibc supports > 64bit timespec, go to monitor_wait64. > > otherwise, go to original monitor_wait. > > Signed-off-by: Song Chen > [Florian: Fix warnings reported by

Re: [PATCH v2 1/3] y2038: cobalt/posix/monitor: Adding monitor_wait64

On Wed, 2021-08-11 at 15:36 +0200, Florian Bezdeka wrote: > Adding monitor_wait64. Patch is based on v1 sent out by Song and was > re-worked to apply on top of current next/master. > > __cobalt_monitor_wait() is now validating the struct timespec64 it > received from userland. That was not the

Re: [PATCH v2 1/3] y2038: cobalt/posix/monitor: Adding monitor_wait64

On Wed, 2021-08-11 at 10:11 +0200, Florian Bezdeka wrote: >   > - if (ts) > + if (ts) { > + if (!timespec64_valid(ts)) > + return -EINVAL; > + >   timeout = ts2ns(ts) + 1; > + } That is mentioned already in the commit message but worth

Re: [PATCH] testsuite/smokey: y2038: Fix evaluation of pthread_join result

On Mon, 2021-08-09 at 09:15 +0200, Jan Kiszka wrote: > From: Jan Kiszka > > The status value is the pointer, not where the pointer points to. > > Signed-off-by: Jan Kiszka > --- > > Not yet resolving the unexpected assertion, though. > > testsuite/smokey/y2038/syscall-tests.c | 2 +- > 1

Re: [PATCH] cobalt/posix/mutex: Harmonize pthread_mutex_timedlock() and sem_timedwait()

On Thu, 2021-07-29 at 19:29 +0200, Jan Kiszka wrote: > On 29.07.21 18:22, Bezdeka, Florian (T RDA IOT SES-DE) wrote: > > On Thu, 2021-07-29 at 17:45 +0200, Jan Kiszka wrote: > > > On 29.07.21 17:06, Philippe Gerum wrote: > > > > > > > > Florian Bezdeka writes: > > > > > > > > > According to the

Re: [PATCH] cobalt/posix/mutex: Harmonize pthread_mutex_timedlock() and sem_timedwait()

On Thu, 2021-07-29 at 17:45 +0200, Jan Kiszka wrote: > On 29.07.21 17:06, Philippe Gerum wrote: > > > > Florian Bezdeka writes: > > > > > According to the POSIX spec the value of the timeout parameter needs > > > not to be validated if the mutex/semaphore could be taken immediately. > > > > >

Re: [PATCH 2/2] cobalt/posix/mutex: Harmonize pthread_mutex_timedlock() and sem_timedwait()

Please ignore this one... Local tooling bug. On Thu, 2021-07-29 at 16:40 +0200, Florian Bezdeka wrote: > According to the POSIX spec the value of the timeout parameter needs > not to be validated if the mutex/semaphore could be taken immediately. > > While the implementation of the semaphore

Re: [xenomai-image PATCH v2 5/5] Add kas option for swithing off debug

On Tue, 2021-07-27 at 12:51 +0200, Jan Kiszka via Xenomai wrote: > On 27.07.21 02:42, Hongzhan Chen via Xenomai wrote: > > For performance or latency testing and demonstration, debug switches > > should be off but it is on by default. > > > > Signed-off-by: Hongzhan Chen > > --- > >  

Re: [xenomai-images][PATCH v2 0/4] Incorporate Comments and fix AWS upload

On Wed, 2021-07-14 at 09:41 +0200, Q. Gylstorff via Xenomai wrote: > From: Quirin Gylstorff > >  Incorporate the comments from patchset[1] set by uploading a test-report.xml >  to gitlab artifacts[2] and replace sed commands with envsubst[3]. > > > Changes V2: >  - use gitlab reports to

  1   2   >