Re: [Xenomai] Weird behavior during debug

264rt cobalt 20 - XT packetfilter 1 279rt cobalt 20 - W packetfilter >-Original Message- >From: Lange Norbert >Sent: Montag, 18. Dezember 2017 14:43 >To: Xenomai (xenomai@xenomai.org) >Subject: Weird

[Xenomai] Weird behavior during debug

Hello, I tried debugging a cobalt application, and when I hit a breakpoint most of the system freezes. If I run for example top over Serial or SSH, then the display won`t be refreshed anymore, A separate program running as RT Task, waiting for an timer-event (occurring 10 times a second) will

Re: [Xenomai] Weird behavior during debug

will stop (supposedly at read), as soon as the debugged program is halted. Norbert >-Original Message- >From: Jan Kiszka [mailto:jan.kis...@siemens.com] >Sent: Dienstag, 19. Dezember 2017 10:35 >To: Lange Norbert; Xenomai (xenomai@xenomai.org) >Subject: Re: Weird behavi

Re: [Xenomai] RTDM/RTNet - proposal to support sending/receiving multiple packets with one systemcall

>-Original Message- >From: Jan Kiszka [mailto:jan.kis...@siemens.com] >Sent: Mittwoch, 06. Dezember 2017 09:27 >To: Stéphane Ancelot; Lange Norbert; Xenomai (xenomai@xenomai.org) >Subject: Re: [Xenomai] RTDM/RTNet - proposal to support sending/receiving >multipl

Re: [Xenomai] RTDM/RTNet - proposal to support sending/receiving multiple packets with one systemcall

>-Original Message- >From: Stéphane Ancelot [mailto:sance...@numalliance.com] >Sent: Mittwoch, 06. Dezember 2017 09:15 >To: Lange Norbert; Xenomai (xenomai@xenomai.org) >Cc: jan.kis...@siemens.com >Subject: Re: [Xenomai] RTDM/RTNet - proposal to support sending/re

[Xenomai] RTDM/RTNet - proposal to support sending/receiving multiple packets with one systemcall

Hello, I would like to involve the RTDM Maintainers for discussing an addition to the RTDM drivermodel. This work would be done by Phillipe Gerum as part of a contract, he is also better suited to outline the necessary changes, should nothing stand against the proposal itself. - Problem

Re: [Xenomai] Weird behavior during debug

>-Original Message- >From: Jan Kiszka [mailto:jan.kis...@siemens.com] >Sent: Dienstag, 19. Dezember 2017 19:57 >To: Lange Norbert; Xenomai (xenomai@xenomai.org); Philippe Gerum >Subject: Re: Weird behavior during debug > >EMAIL from a NON-ANDRITZ SOURCE:

Re: [Xenomai] Why get low latency while running stress command?

Hi, I guess what happens is, that the CPU will be put to sleep and/or lower frequency and voltage between calls, These transitions are rather slow and will then have to happen on wake-up Disable any kind of powersaving features in Linux and possibly BIOS (C-States). Kind regards, Norbert

Re: [Xenomai] rtdm_timer_start latency?

Hello, this seems identical to an issue I have. I wanted to start a millisecond tick, aligned to seconds, but used the POSIX timerfd_settime. Under Linux this works as intendent, under cobalt it doesn't. I expect that the first timeout would be somewhat close to the call, on a "whole"

[Xenomai] Patched kernel headers - are they needed afterwards for gibc and more?

Hello, A script with patches together a kernel, ipipe and xenomai kernel drivers. Result is the packages to install the kernel image. A buildroot configuration will build the rootfs, without * using the identical kernel version (different patch level) * using headers that were used for

Re: [Xenomai] building Xenomai Apps with CMake (RFC)

>-Original Message- >From: Henning Schild [mailto:henning.sch...@siemens.com] >Sent: Freitag, 06. April 2018 10:47 >To: Lange Norbert >Cc: Jan Kiszka; Xenomai (xenomai@xenomai.org) >Subject: Re: building Xenomai Apps with CMake (RFC) > >E-MAIL F

Re: [Xenomai] building Xenomai Apps with CMake (RFC)

Hello, >-Original Message- >From: Jan Kiszka [mailto:jan.kis...@siemens.com] >Sent: Donnerstag, 05. April 2018 16:55 >To: Lange Norbert; Xenomai (xenomai@xenomai.org); Henning Schild >Subject: Re: building Xenomai Apps with CMake (RFC) > >E-MAIL FROM

Re: [Xenomai] building Xenomai Apps with CMake (RFC)

>- none (--no-auto-init) >- bootstrap-pic.o (--auto-init-solib) >- bootstrap.o (--auto-init or default) > >To me the questions then are: >- The code there could be encapsulated in a header? I dont see how it could not, it just uses public API >- or could be put in a lib? As static lib: Not a

[Xenomai] [PATCH] add missing headers and casts, prefer POSIX definitions

Fix a few missing headers and casts see http://man7.org/linux/man-pages/man2/bind.2.html and http://man7.org/linux/man-pages/man2/open.2.html and http://man7.org/linux/man-pages/man7/sigevent.7.html Signed-off-by: Norbert Lange --- demo/posix/cobalt/gpiopwm.c

[Xenomai] [PATCH] fix out-of-bounds access

Fix an invalid memory access in the testsuite. Signed-off-by: Norbert Lange --- testsuite/smokey/net_common/smokey_net_server.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/testsuite/smokey/net_common/smokey_net_server.c

Re: [Xenomai] [PATCH 3/3] provide an extended xenomai_init function

--Original Message- From: Norbert Lange <nolang...@gmail.com> Sent: Montag, 23. April 2018 16:24 To: xenomai@xenomai.org Cc: Lange Norbert <norbert.la...@andritz.com> Subject: [PATCH 3/3] provide an extended xenomai_init function E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PL

Re: [Xenomai] xeno-config --no-mode-check still has -lmodechk

Ok, I believe that's my entirely the fault of my changes, ignore the previous mail Norbert This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information

Re: [Xenomai] xeno-config --no-mode-check still has -lmodechk

Hello, Since I just ran into this…. libcobalt seems to really need libmodechk to define __real_malloc and __real_free. I believe this to be a bug? $ nm /home/lano/buildroot/host/x86_64-buildroot-linux-gnu/sysroot/usr/xenomai/lib/libcobalt.so | grep malloc 000199f0 T malloc_ex

[Xenomai] Fun with cobalt interposing fcntl

Hello, I ran into an annoying problem with cobalt, namely that it interposes functions with varargs like fcntl, The issue is that it won't ever be able to correctly forward the varags. In the example, fcntl will be interpreted as having an additional int parameter, while some functionality has

Re: [Xenomai] [PATCH] cobalt: fcntl uses void* instead of int

> > @@ -139,11 +139,11 @@ static int do_ioctl(int fd, unsigned int > > request, void *arg) COBALT_IMPL(int, fcntl, (int fd, int cmd, ...)) > > { > > va_list ap; > > - int arg; > > + void *arg; > > int ret; > > > > va_start(ap, cmd); > > - arg = va_arg(ap, int); > > +

Re: [Xenomai] Order options to build a Xenomai program

Hello, link order is important and goes left-to-right, this seems to include "wrappers", which only wrap symbols that where already encountered (to the left of the wrapper argument) Compare an application using malloc: Variant A: -Wl,@modechk.wrappers -l modechk The app is linked, extern

Re: [Xenomai] Order options to build a Xenomai program

>>> Norbert, I have followed your emails and your project. You did a good job, >>> but I don't agree with your approach. My points are: >>> >>> - You are trying to convert Xenomai a CMake project and this probably will >>> not happen because Upstream is very happy with the autotools. I don't

Re: [Xenomai] Order options to build a Xenomai program

> So, from my point of view it confirm my suspicious that the wrapper > mechanism is fragile. I really didn't understand why Xenomai core team > changed the native API for the POSIX. Although I saw the Jan Kiska > conference video explaining it, tell me primitive or dump, but I prefer to > have >

RE: Cobalt Preemption of kernel update_fast_timekeeper can cause deadlocks

> -Original Message- > From: Jan Kiszka > Sent: Donnerstag, 20. Dezember 2018 14:33 > To: Lange Norbert ; Xenomai > (xenomai@xenomai.org) > Subject: Re: Cobalt Preemption of kernel update_fast_timekeeper can cause > deadlocks > > E-MAIL FROM A NON-ANDRITZ SO

RE: Cobalt Preemption of kernel update_fast_timekeeper can cause deadlocks

> On 19.12.18 19:26, Auel, Kendall via Xenomai wrote: > > Jan, > > > > I'm very much in favor of providing a way to prevent Xenomai modules > from using features which can result in deadlock, if there is a clean way to > detect such a situation. > > > > We used gettimeofday in one of our modules

RE: Cobalt Preemption of kernel update_fast_timekeeper can cause deadlocks

> >> > >> If you are calling into an "unknown" non-RT blob, dropping from RT > >> may actually be required. We do not promote explicit mode switches > >> because they are not needed if you control (wrap) all your code. This > >> might be an exception. > > > > The non-RT "blob" is the regular

RE: improve and provide a header for bootstrapping

> -Original Message- > From: Jan Kiszka > Sent: Dienstag, 4. Dezember 2018 18:59 > To: Lange Norbert > Cc: Xenomai ; Philippe Gerum > > Subject: Re: improve and provide a header for bootstrapping > > E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE

RE: HelloWorld with CMake

> -Original Message- > From: Xenomai On Behalf Of Evandro > Sestrem via Xenomai > Sent: Dienstag, 4. Dezember 2018 12:40 > To: xenomai@xenomai.org > Subject: HelloWorld with CMake > > ** cmake_xenomai attempt ** > - > I also tried to use the cmake_xenomai github

RE: improve and provide a header for bootstrapping

> -Original Message- > From: Jan Kiszka > Sent: Dienstag, 4. Dezember 2018 17:30 > To: Lange Norbert > Cc: Xenomai ; Philippe Gerum > > Subject: Re: improve and provide a header for bootstrapping > > E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE

RE: improve and provide a header for bootstrapping

So any update on this. Do you have something similar to patchwork to keep up on those loose email-threads? Norbert > -Original Message- > From: Xenomai On Behalf Of Norbert > Lange > Sent: Freitag, 26. Oktober 2018 18:36 > To: jan.kis...@siemens.com > Cc: Xenomai > Subject: Re:

RE: [Xenomai] [PATCH] cobalt: fcntl uses void* instead of int

Mittwoch, 17. Oktober 2018 17:27 > To: Lange Norbert ; xenomai@xenomai.org > Subject: Re: [Xenomai] [PATCH] cobalt: fcntl uses void* instead of int > > E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE > EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR > ATTACHME

LD_PRELOAD checker for clock_gettime and consorts

Hello, as you might know, I run into alot of troubles with realtime code calling clock_gettime. This function is now a syscall on many architectures and depends on a linux kernel spinlock, so a RT thread might deadlock itself when both trying to claim that lock and preventing the linux kernel

FW: LD_PRELOAD checker for clock_gettime and consorts

And heres a checker for malloc/free and consorts. This one is a bit trickier and I have barely tested it. > -Original Message- > From: Xenomai On Behalf Of Lange > Norbert via Xenomai > Sent: Donnerstag, 10. Jänner 2019 14:47 > To: Xenomai (xenomai@xenomai.org) > S

Cobalt Preemption of kernel update_fast_timekeeper can cause deadlocks

There is a deadlock issue that haunted me for several weeks, it is caused by the kernels update of the user-visible timekeeping structures used by the VDSO clock_gettime functions. The kernel regularly updates a Timestamp structure, which is accessible in user-mode, it does so by something akin

RE: Cobalt Preemption of kernel update_fast_timekeeper can cause deadlocks

> -Original Message- > From: Jan Kiszka > Sent: Mittwoch, 19. Dezember 2018 13:45 > To: Philippe Gerum ; Lange Norbert > ; Xenomai (xenomai@xenomai.org) > > Subject: Re: Cobalt Preemption of kernel update_fast_timekeeper can cause > deadlocks > > E-

Kernel module symbol conflicts

Hello, We use a setup with multiple network controllers, and so far only one of them is realtime capable. The issue is, that there are nonRt and Rt drivers active at the same time (igb statically builtin and rt_igb as module). And while it works, I got some irregular weird crashes. Is there an

RE: x86_64 kernel does not start under qemu

Hello, I have a similar issue on real hardware (cc Philippe). Can you try booting with notscdeadline? Norbert > -Original Message- > From: Xenomai On Behalf Of Richard > Weinberger via Xenomai > Sent: Mittwoch, 6. März 2019 11:17 > To: xenomai@xenomai.org; henning.sch...@siemens.com

Posix skin and Mutex initialisation/destruction inconsistencies

Hello, 1) There is an inconsistency with the documentation [1], which claims that mutex and condition variables need to be explicitly initialized with the *_init functions. The implementation however checks the state via a flag and calls *_init if necessary, and the program below works

RE: smokey's fork tests hangs?

> -Original Message- > From: Jan Kiszka > Sent: Freitag, 8. März 2019 16:23 > To: Lange Norbert ; Xenomai > (xenomai@xenomai.org) > Subject: Re: smokey's fork tests hangs? > > E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE > EXERCISE CAUTION

RE: smokey's fork tests hangs with glibc 2.28+ ?

is not available with the Mercury core, might be easier to isolate that way. In the future, maybe some battletested glibc versions could be recommended for xenomai? > -Original Message- > From: Jan Kiszka > Sent: Freitag, 8. März 2019 16:23 > To: Lange Norbert ; Xenoma

RE: smokey's fork tests hangs with glibc 2.28+ ?

Thats a rootfs which reproduces the issue. Identical setup, but glibc 2.27 will not reproduce. > -Original Message- > From: Jan Kiszka > Sent: Montag, 11. März 2019 14:50 > To: Lange Norbert ; Xenomai > (xenomai@xenomai.org) > Subject: Re: smokey's fork tests han

smokey's fork tests hangs?

Hello, I have problems with the fork tests, they both hang for me. # xeno smokey --run=11 --verbose=2 # xeno smokey --run=20 --verbose=2 no leak withthread no leak withmutex no leak withcond no leak withsem no leak withnamed sem no leak withtimer no leak withmq When started under gdb, the

RE: smokey's fork tests hangs?

> -Original Message- > From: Jan Kiszka > Sent: Freitag, 8. März 2019 14:59 > To: Lange Norbert ; Xenomai > (xenomai@xenomai.org) > Subject: Re: smokey's fork tests hangs? > > E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE > EXERCISE CAUTION

RE: smokey's fork tests hangs?

> > Not reproducible here with stable/3.0.x or next, and with ipipe-x86-4.14.y. > What are your parameters? Not entirely upstream, but based on ipipe-core-4.14.89-x86-2 and xenomai master, the difference is contained in the rt_igb driver, which is not even loaded. Defconfig is attached. I

libcopperplate.so depends on modecheck?

Hello, Seems like libcopperplate.so always depends on libmodechk.so, as the following symbols would imply: nm -D /home/lano/buildroot/host/x86_64-buildroot-linux-gnu/sysroot/usr/xenomai/lib/libcopperplate.so | grep __real U __real_free U __real_malloc

RE: smokey's fork tests hangs with glibc 2.28+ ?

t: Montag, 11. März 2019 15:19 > To: Lange Norbert ; Jan Kiszka > ; Xenomai (xenomai@xenomai.org) > > Subject: Re: smokey's fork tests hangs with glibc 2.28+ ? > > E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE > EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINK

RE: smokey's fork tests hangs with glibc 2.28+ ?

t: Montag, 11. März 2019 15:19 > To: Lange Norbert ; Jan Kiszka > ; Xenomai (xenomai@xenomai.org) > > Subject: Re: smokey's fork tests hangs with glibc 2.28+ ? > > E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE > EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINK

RE: libcopperplate.so depends on modecheck?

I still believe this to be a bug, adding a patch to correct this. Regards, Norbert > -Original Message- > From: Lange Norbert > Sent: Mittwoch, 20. März 2019 11:49 > To: Xenomai (xenomai@xenomai.org) > Subject: libcopperplate.so depends on modecheck? > >

RE: libcopperplate.so depends on modecheck?

> -Original Message- > From: Jan Kiszka > Sent: Freitag, 31. Mai 2019 16:26 > To: Lange Norbert ; Xenomai > (xenomai@xenomai.org) ; Philippe Gerum > ; Henning Schild > Subject: Re: libcopperplate.so depends on modecheck? > > E-MAIL FROM A NON-ANDRITZ SO

RE: serial driver for imx28

> -Original Message- > From: Julien Blanc > Sent: Freitag, 14. Juni 2019 14:46 > To: Lange Norbert ; Xenomai > (xenomai@xenomai.org) > Subject: Re: serial driver for imx28 > > E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE > EXERCISE CAUTION

RE: serial driver for imx28

> -Original Message- > From: Xenomai On Behalf Of Julien Blanc > via Xenomai > Sent: Freitag, 14. Juni 2019 13:54 > To: Xenomai@xenomai.org > Subject: serial driver for imx28 > > E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE > EXERCISE CAUTION WITH E-MAIL CONTENT AND

RE: Commands for reading, loading and unloading drivers on BeagleBone Black?

have to do a thing, and the modules get loaded automatically. Norbert From: danwe Sent: Freitag, 21. Juni 2019 13:23 To: Lange Norbert ; xenomai@xenomai.org Subject: Re: Commands for reading, loading and unloading drivers on BeagleBone Black? E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY

cobalts printf thread affects signalfd operation

Hello, I ran into a problem with the automatically spawned printf thread. Short summary: The kernel delivers signals by picking a thread that can accept a signal and does not mask the specific signal, only if none is available then the signal will be queued for asynchronous delivery. signalfd

RE: Commands for reading, loading and unloading drivers on BeagleBone Black?

Use sysfs- # unbind the current driver for those devices for sio in 1-2:1.0 1-2:1.1 1-2:1.2 1-2:1.3; do echo "$sio" > /sys/bus/usb/devices/"$sio"/driver/unbind done # use a specific driver 'ftdi_sio' for a device echo "1-2:1.0" > /sys/bus/usb/drivers/ftdi_sio/bind # let linux pick a

RE: [PATCH] lib/cobalt: init: do not call pthread_atfork() from atfork() handlers

(readding ML) > -Original Message- > From: Philippe Gerum > Sent: Dienstag, 14. Mai 2019 10:38 > To: Lange Norbert > Subject: Re: [PATCH] lib/cobalt: init: do not call pthread_atfork() from > atfork() handlers > > E-MAIL FROM A NON-ANDRITZ SOURCE: AS A

RE: [PATCH] lib/cobalt: init: do not call pthread_atfork() from atfork() handlers

> -Original Message- > From: Philippe Gerum > Sent: Dienstag, 14. Mai 2019 12:05 > To: Lange Norbert ; Xenomai > (xenomai@xenomai.org) > Subject: Re: [PATCH] lib/cobalt: init: do not call pthread_atfork() from > atfork() handlers > > E-MAIL FROM A NON-AN

FW: [PATCH] lib/cobalt: init: do not call pthread_atfork() from atfork() handlers

What do you think about this hackaround? Still not "clean" to call in a signal handler but it does work. Norbert > -Original Message- > From: Lange Norbert > Sent: Dienstag, 14. Mai 2019 12:24 > To: Philippe Gerum ; Xenomai (xenomai@xenomai.org) > > Subject:

RE: having problems with daemonizing

> -Original Message- > From: Xenomai On Behalf Of Lowell > Gilbert via Xenomai > Sent: Freitag, 26. April 2019 23:19 > To: xenomai@xenomai.org > Subject: having problems with daemonizing > > E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE > EXERCISE CAUTION WITH E-MAIL

RE: ipipe 4.19: spurious APIC interrupt when setting rt_igp to up

> -Original Message- > From: Jan Kiszka > Sent: Freitag, 5. Juli 2019 09:39 > To: Lange Norbert ; Xenomai > (xenomai@xenomai.org) ; Philippe Gerum > > Subject: Re: ipipe 4.19: spurious APIC interrupt when setting rt_igp to up > > E-MAIL FROM A NON-ANDRITZ SO

Waking up threads from the other xenomai/linux domain

Hello, I have multiple threads, one of them is realtime, one other is responsible for controlling the service. The controlling thread blocks on some linux sockets, the realtime one has a select on a RT socket and a timeout. I now have the problem that I need to wake up the other thread under

RE: Waking up threads from the other xenomai/linux domain

> -Original Message- > From: Philippe Gerum > Sent: Donnerstag, 27. Juni 2019 14:43 > To: Lange Norbert ; Xenomai > (xenomai@xenomai.org) > Subject: Re: Waking up threads from the other xenomai/linux domain > > E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY ME

RE: ipipe 4.19: spurious APIC interrupt when setting rt_igp to up

> -Original Message- > From: Jan Kiszka > Sent: Mittwoch, 10. Juli 2019 23:31 > To: Lange Norbert ; Xenomai > (xenomai@xenomai.org) ; Philippe Gerum > > Subject: Re: ipipe 4.19: spurious APIC interrupt when setting rt_igp to up > > E-MAIL FROM A NON-ANDRITZ SO

RE: [PATCH] cobalt: remove call to sigprocmask

> -Original Message- > From: Xenomai On Behalf Of Jan Kiszka > via Xenomai > Sent: Freitag, 12. Juli 2019 15:07 > To: Norbert Lange ; xenomai@xenomai.org > Subject: Re: [PATCH] cobalt: remove call to sigprocmask > > E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE >

Best way to detect if a filedescriptor is a cobalt filedescriptor (/socket)

Hi, I am opening a packetsocket, which is supposed to be realtime. Unfortunatly if the rtpacket (rtnet?) module is not loaded, then this will just silently fall back to a linux packet socket. Then later demote thread during accesses. How would I be able to detect this early during startup? I

ipipe 4.19: spurious APIC interrupt when setting rt_igp to up

Hello, using the rt_igb driver with the recent ipipe/kernel will result in a broken state (I assume one cpu core is “stuck”). This is a quote from Phillipe (note that I tested the plain upstream revivision below) > This happens specifically when the igb driver enables the device at >

RE: (unknown)

> -Original Message- > From: Jan Kiszka > Sent: Mittwoch, 10. April 2019 16:48 > To: Lange Norbert ; Xenomai > > Subject: Re: (unknown) > > E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE > EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINK

RE: affinity of main thread is bound to current core

> -Original Message- > From: Philippe Gerum > Sent: Donnerstag, 22. August 2019 17:29 > To: Lange Norbert ; Jan Kiszka > ; Xenomai (xenomai@xenomai.org) > > Subject: Re: affinity of main thread is bound to current core > > E-MAIL FROM A NON-ANDRITZ SOURCE: AS

RE: affinity of main thread is bound to current core

> -Original Message- > From: Jan Kiszka > Sent: Donnerstag, 22. August 2019 16:52 > To: Lange Norbert ; Xenomai > (xenomai@xenomai.org) > Subject: Re: affinity of main thread is bound to current core > > E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, P

RE: [PATCH 2/2] cobalt: switch hand over status to -ENODEV for non-RTDM fd

> -Original Message- > From: Jan Kiszka > Sent: Donnerstag, 29. August 2019 16:52 > To: Lange Norbert ; Philippe Gerum > ; Xenomai (xenomai@xenomai.org) > > Subject: Re: [PATCH 2/2] cobalt: switch hand over status to -ENODEV for non- > RTDM fd > > E-

RE: [PATCH 2/2] cobalt: switch hand over status to -ENODEV for non-RTDM fd

I ran into a rather big issue with linux filehandles I use Xenomai master on ipipe-core-4.19.60-x86-5 with those patches, (can't be 100% sure its not some kernel/userspace conflict, but I doubt it) What happens is that upon a __cobalt_close with a linux filehande, the syscall sc_cobalt_close

affinity of main thread is bound to current core

Hello, I use Xenomai master on ipipe-core-4.19.60-x86-5. I start out with an affinity mask of 0xF, in the function cobalt_init_2, pthread_setschedparam will get called, after the syscall sc_cobalt_thread_setschedparam_ex the affinity mask will contain a single CPU (supposedly the current

RE: Static build of rtnet

> -Original Message- > From: Jan Kiszka > Sent: Dienstag, 17. September 2019 09:42 > To: Lange Norbert ; Xenomai > (xenomai@xenomai.org) > Subject: Re: Static build of rtnet > > NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR > ATTACHMENTS. > > &

Static build of rtnet

Hello, I havent tested this in a while, but building rtnet static will crash the kernel when this module initializes. With the various fixes and cleanups in master/next (like rtdm_available) that might be worth a look? I would hope to build a static kernel one day, and so far there are 2

RE: ipipe 4.19: spurious APIC interrupt when setting rt_igp to up

driver in use, and am unbinding the network card prior to binding the rt_igp driver Regards, Norbert > -Original Message- > From: Jan Kiszka > Sent: Freitag, 5. Juli 2019 15:57 > To: Lange Norbert ; Xenomai > (xenomai@xenomai.org) ; Philippe Gerum > > Subject: Re: ipip

RE: Best way to detect if a filedescriptor is a cobalt filedescriptor (/socket)

> -Original Message- > From: Jan Kiszka > Sent: Mittwoch, 10. Juli 2019 08:13 > To: Lange Norbert ; Xenomai > (xenomai@xenomai.org) ; Philippe Gerum > > Subject: Re: Best way to detect if a filedescriptor is a cobalt filedescriptor > (/socket) > > E-

RE: ipipe 4.19: spurious APIC interrupt when setting rt_igp to up

> -Original Message- > From: Jan Kiszka > Sent: Dienstag, 9. Juli 2019 19:54 > To: Lange Norbert ; Xenomai > (xenomai@xenomai.org) ; Philippe Gerum > > Subject: Re: ipipe 4.19: spurious APIC interrupt when setting rt_igp to up > > E-MAIL FROM A NON-ANDRITZ SO

RE: Xenomai crashes when braking into the debugger

> -Original Message- > From: Jan Kiszka > Sent: Mittwoch, 13. November 2019 18:42 > To: Lange Norbert ; Xenomai > (xenomai@xenomai.org) > Subject: Re: Xenomai crashes when braking into the debugger > > NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT

RE: RTnet sendmmsg and ENOBUFS

> -Original Message- > From: Jan Kiszka > Sent: Mittwoch, 13. November 2019 18:39 > To: Lange Norbert ; Xenomai > (xenomai@xenomai.org) > Subject: Re: RTnet sendmmsg and ENOBUFS > > NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR > ATTACHMENTS. >

RTnet sendmmsg and ENOBUFS

Hello, for one of our applications, we have (unfortunatly) a single ethernet connection for Realtime and Nonrealtime. We solve this by sending timeslices with RT first, then filling up the remaining space. When stressing the limits (quite possibly beyond if accounting for bugs), the sendmmsg

Xenomai crashes when braking into the debugger

Hello, I am running into some bad issues with debugging, can't really narrow down when they happen, but usually when I run through GDB and want to "break" (pause execution), it seems to be related to *other* Xenomai programs running at the same time (as said its hard to narrow down). Kind

RE: RTnet sendmmsg and ENOBUFS

e- > From: Xenomai On Behalf Of Lange > Norbert via Xenomai > Sent: Mittwoch, 13. November 2019 18:53 > To: Jan Kiszka ; Xenomai > (xenomai@xenomai.org) > Subject: RE: RTnet sendmmsg and ENOBUFS > > NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR > ATTACHMENTS. > &

RE: Deadlock during debugging

New crash, same thing with ipipe panic trace (the decoded log does not add information to the relevant parts). Is the dump_stack function itself trashing the stack? [ 168.411205] [Xenomai] watchdog triggered on CPU #1 -- runaway thread 'main' signaled [ 209.176742] [ cut here

Deadlock during debugging

Hello, Here's one of my deadlocks, the output seems interleaved from 2 concurrent dumps, I ran the crashlog through decode_stacktrace.sh. I got to this, after enabling a breakpoint in gdb (execution did stop there), setting another breakpoint and hitting continue. [ 135.414273] CPU: 1 PID:

RE: Deadlock during debugging

One more, Note that there seem to be quite different reports, from a recursive fault to some threads getting marked as "runaway". I can reproduce the issue now easily, but its proprietary software I cant reach around. Norbert [ 226.354729] I-pipe: Detected stalled head domain, probably

RE: RTnet sendmmsg and ENOBUFS

> > > > >> > >>> I suppose the receive path works similarly. > >>> > >> > >> RX works by accepting a global-pool buffer (this is where incoming packets > >> first end up in) filled with data in exchange to an empty rtskb from the > socket > >> pool. That filled rtskb is put into the socket pool

RE: [PATCH] rtdm: Do not return an error from send/recvmmsg if there are packets

Hello, Just for consideration, If you can pass both error value and # of successfully sent packets out of the kernel function, perhaps you could return the # (if > 0) and still set errno in case of an (real) error? It would be somewhat different to Linux, but that would not be the only

RE: RTnet sendmmsg and ENOBUFS

> -Original Message- > From: Jan Kiszka > Sent: Freitag, 15. November 2019 14:36 > To: Lange Norbert ; Xenomai > (xenomai@xenomai.org) > Subject: Re: RTnet sendmmsg and ENOBUFS > > NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR > ATTACHMENTS. >

unable to handle kernel paging request

Hello, How can I get to the bottom of bugs that lockup the system completely? I got that error now the 3rd time. [ 1643.652566] BUG: unable to handle kernel paging request at 00044540 [ 1643.659546] PGD 1750d1067 P4D 1750d1067 PUD 1775e7067 PMD 0 [ 1643.665237] Oops: 0010 [#1] SMP NOPTI

urcu/lttng (Userspace) and Xenomai

Hello, I am trying to figure out if Xenomai would work correctly with Lttng. Currently I haven’t figured out how the system manages buffers, but I am checking if this would be generally applicable to Xenomai. I’d like to know if anyone has already used Lttng UST with xenomai threads, and if

RE: urcu/lttng (Userspace) and Xenomai

> -Original Message- > From: Jan Kiszka > Sent: Donnerstag, 21. November 2019 14:46 > To: Lange Norbert ; Xenomai > (xenomai@xenomai.org) > Subject: Re: urcu/lttng (Userspace) and Xenomai > > NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR > ATTACHMEN

RE: Moving on

> -Original Message- > From: Xenomai On Behalf Of Philippe > Gerum via Xenomai > Sent: Montag, 2. Dezember 2019 17:05 > To: Xenomai@xenomai.org > Subject: Moving on > > > It has been two years since I stepped down as Xenomai's lead maintainer. > In the meantime, Jan took over and did a

RE: stalled head domain with 3.1rc4

> -Original Message- > From: Jan Kiszka > Sent: Freitag, 13. Dezember 2019 14:13 > To: Lange Norbert ; Xenomai > (xenomai@xenomai.org) > Subject: Re: stalled head domain with 3.1rc4 > > NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR > ATTACHMENTS. >

stalled head domain with 3.1rc4

Just had a bug msg pop up. Its triggered by enabling tracing, while we have 2 processes running, using IDDP, XDDP and RTNet (just packet sockets, no ip stack). Some points: - trace-cmd stores in tmp, so shouldn't touch other filesystems than tmpfs, sysfs - upon starting this, our

3.1rc4: rcu_sched self-detected stall on CPU

Got this stall, when trying to reboot. Apparently a Xenomai process can't be killed. [ 350.298889] rcu: INFO: rcu_sched self-detected stall on CPU [ 350.304621] rcu:2-: (20999 ticks this GP) idle=546/1/0x4002 softirq=9363/9363 fqs=5108 [ 350.314280] rcu:

RE: stalled head domain with 3.1rc4

3.932092]#func -39 run_local_timers+0x0 (update_process_times+0x3a) [ 293.960301] Scheduler tracepoints stat_sleep, stat_iowait, stat_blocked and stat_runtime require the kernel parameter schedstats=enabl1 > -Original Message- > From: Lange Norbert > Sent: Freita

RE: stalled head domain with 3.1rc4

Added the trace starting 1 second before the bug (might help you more). (last one was the same trace cut at the time of the bug) > -Original Message- > From: Lange Norbert > Sent: Freitag, 13. Dezember 2019 11:54 > To: Lange Norbert > Cc: Philippe Gerum (r...@xenomai.org)

RE: CONFIG_XENO_DRIVERS_NET_CHECKED not possible to enable

> -Original Message- > From: Jan Kiszka > Sent: Dienstag, 17. Dezember 2019 07:53 > To: Lange Norbert ; Xenomai > (xenomai@xenomai.org) > Subject: Re: CONFIG_XENO_DRIVERS_NET_CHECKED not possible to enable > > NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT

RE: [I-PIPE] ipipe-core-4.19.89-x86-9 released

Is there an easily digestible list of i-pipe changes (on top of the upstream Kernel)? Norbert > -Original Message- > From: Xenomai On Behalf Of xenomai--- > via Xenomai > Sent: Dienstag, 17. Dezember 2019 09:47 > To: xenomai@xenomai.org > Subject: [I-PIPE] ipipe-core-4.19.89-x86-9

RE: rtcap destroys packet contents

> -Original Message- > From: Jan Kiszka > Sent: Dienstag, 17. Dezember 2019 08:10 > To: Lange Norbert ; Xenomai > (xenomai@xenomai.org) > Subject: Re: rtcap destroys packet contents > > NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR > ATTACHMENTS. >

Inspecting heap allocations?

Hello, I have some circumstances where I run out of global heap and then simple stull like creating a mutex fails with ENOMEM. My suspicion is an IDDP connection between 2 processes, where 1 process might send a lot small packets before the other will pull them (I will try using a local pool).

  1   2   >