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 descrip
>-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
>-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
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 b
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
&& SPARSEMEM_VMEMMAP
select HAVE_ARCH_KGDB
select HAVE_ARCH_KMEMCHECK
Norbert
>-Original Message-
>From: Jan Kiszka [mailto:jan.kis...@siemens.com]
>Sent: Dienstag, 19. Dezember 2017 08:16
>To: Lange Norbert; Xenomai (xenomai@xenomai.org)
>Subj
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
>-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:
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 build
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" millisec
Hello,
I went ahead and created a script to add support for Xenomai (3+) to CMake. Its
currently sufficient for me,
but I would like to get this in a shape that it is useful and robust enough for
most people.
Ultimately it should end up up streamed to CMake (I hope the binutils-specific
wrapper
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 A NON
>-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 FROM A
>- 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
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
b/testsuite/smokey/net_common/smokey_net_server.c
i
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 | 4 ++--
testsuite/
d regards,
Norbert
-Original Message-
From: Norbert Lange
Sent: Montag, 23. April 2018 16:24
To: xenomai@xenomai.org
Cc: Lange Norbert
Subject: [PATCH 3/3] provide an extended xenomai_init function
E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE EXERCISE
CAUTION WITH E-MAIL CONTEN
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
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 prote
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
-O
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 symb
> 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
>
>>> 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 like
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 a
> > @@ -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);
> > +
Hello,
I am trying to track down some spurios relaxes.
What happens is that I:
- cobalt_init calls mlockall(MCL_CURRENT | MCL_FUTURE);
- allocate and initialize some data in the heap area
- spawn the xenomai-thread
- wait for notification from the xenomai-thread (so that I know, any
ini
I originally had the Xenomai thread tied to another CPU-Core, hence the subject.
The issue happens also if all threads are tied to Core #0.
So the question should read: is memory locking per *thread* necessary?
> -Original Message-
> From: Lange Norbert
> Sent: Freitag, 15. Jä
Hello,
By accident I built 4.19.152-cip37-x86-15 with the wip/dovetail branch. I
understand that this should be supported one day?
In the hope that this is of use for you, I get built following errors during
the modpost step with this config:
ERROR: "__rtdm_nrtsig_execute" [drivers/xenomai/tes
Hello,
There is some bigger kernel oops when an rtnet device is unbound from
linux but still accessible via ioctl.
Effect and backtrace depends on timing, usually the rt_igb module will not
decrease its reference count, and a following soft reboot might hang.
To repoduce, for example with rt_igb
> -Original Message-
> From: Jan Kiszka
> Sent: Dienstag, 3. August 2021 18:04
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org)
> Subject: Re: kernel bug if rtnet device is accesses during unbind
>
>
>
> CAUTION: External email. Do not click on links
Hello,
I have some small slight issue with the cobalt_assert_nrt function,
incase a violation is detected the thread should get a signal,
but the implementation will implicitly get a signal during the execution of
pthread_kill, see:
#0 getpid () at ../sysdeps/unix/syscall-template.S:60
#1 0x0
> -Original Message-
> From: Jan Kiszka
> Sent: Donnerstag, 19. August 2021 12:54
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org)
> Subject: Re: cobalt_assert_nrt should use __cobalt_pthread_kill
>
>
>
> CAUTION: External email. Do not click on li
> -Original Message-
> From: Jan Kiszka
> Sent: Donnerstag, 19. August 2021 17:42
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org)
> Subject: Re: cobalt_assert_nrt should use __cobalt_pthread_kill
>
>
>
> CAUTION: External email. Do not click on li
> -Original Message-
> From: Jan Kiszka
> Sent: Freitag, 20. August 2021 08:37
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org)
> Subject: Re: cobalt_assert_nrt should use __cobalt_pthread_kill
>
>
>
> CAUTION: External email. Do not click on links
> -Original Message-
> From: Jan Kiszka
> Sent: Freitag, 20. August 2021 11:15
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org)
> Subject: Re: cobalt_assert_nrt should use __cobalt_pthread_kill
>
>
>
> CAUTION: External email. Do not click on links or
Hello,
rebuilding from the 3.1.x branch yields an error:
ERROR: "__xnthread_discard" [drivers/xenomai/testing/xeno_switchtest.ko]
undefined!
xeno_switchtest can't be compiled as module because of this (works as built-in)
Mit besten Grüßen / Kind regards
NORBERT LANGE
___
That takes care of the issue, thanks for the quick help.
> -Original Message-
> From: Jan Kiszka
> Sent: Mittwoch, 15. Dezember 2021 13:57
> To: Xenomai
> Cc: Lange Norbert
> Subject: [PATCH] cobalt/thread: Export __xnthread_discard
>
>
>
> CAUTION: E
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
> -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
> -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 CON
(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
> -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
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:
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?
>
>
> -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
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 i
> -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 AN
> -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
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 driver
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
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 s
> -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
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
> rtifconfi
> -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
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 co
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
> -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
> -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-MAIL F
> -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
> -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
> EXERCI
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 one).
> -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
> -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
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 retu
> -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-MAIL F
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
roadb
> -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.
>
>
&
> -Original Message-
> From: Jan Kiszka
> Sent: Mittwoch, 9. Oktober 2019 13:00
> To: Lange Norbert ; François Legal
>
> Subject: Re: [PATCH] Allow RTNet to be builtin kernel
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
&
I managed to build a kernel with statically linked igb, e1000 and e1000e for
linux and rtnet, after running the below script to namespace those drivers (I
only use [rt_]igb, but this driver needs symbols from e1000).
Seems to basically work, with some caveats that might only relate to my change
Hello,
I built the xeno_*test components as loadable modules, but it seems
xeno_heapcheck is either broken or can’t be built as module?
Version is Xenomai v3.1-rc2
~# modprobe xeno_rtdmtest
~# modprobe xeno_heapcheck
[57980.549627] xeno_heapcheck: Unknown symbol xnthread_relax (err -2)
[57980.5
> -Original Message-
> From: Xenomai
> mailto:xenomai-boun...@xenomai.org>> On Behalf
> Of Jan Kiszka
> via Xenomai
> Sent: Montag, 14. Oktober 2019 08:26
> To: Norbert Lange mailto:nolang...@gmail.com>>; Xenomai
> mailto:xenomai@xenomai.org>>
> Subject: Re: running xenomai through
> -Original Message-
> From: Jan Kiszka
> Sent: Montag, 14. Oktober 2019 12:09
> To: Lange Norbert ; Xenomai
>
> Subject: Re: running xenomai through scan-build or: some 100 issues with
> static code analysis
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONT
Signaling the waiting thread happens when you unlock the corresponding mutex,
You need to lock/unlock the mutex around the pthread_cond_signal call.
Regards, Norbert
> -Original Message-
> From: Xenomai On Behalf Of Jan Leupold
> via Xenomai
> Sent: Mittwoch, 23. Oktober 2019 17:52
> To
Nothing has an effect, as the cobalt setup routine binds the main thread to the
single core.
See: https://xenomai.org/pipermail/xenomai/2019-August/041381.html
Every thread you spawn will inherit the same affinity mask (with a single bit
set), and all options (tunables, cmdline) affect the mask
Hello,
I have some problems with Xenomai 3.1rc2, the following function will often
block after printing "b".
This does not happen always and never happens when I run the program through
gdb, and I can't attach
with gdb if its blocked.
Using another port then -1 makes no difference, and there is
---
> From: Xenomai On Behalf Of Lange
> Norbert via Xenomai
> Sent: Dienstag, 29. Oktober 2019 17:32
> To: Xenomai (xenomai@xenomai.org)
> Subject: binding to iddp socket often blocks forever
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
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 c
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 regar
> -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.
>
> -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, LINKS OR
--
> 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.
>
&
> -Original Message-
> From: Jan Kiszka
> Sent: Donnerstag, 14. November 2019 19:18
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org)
> Cc: Philippe Gerum (r...@xenomai.org)
> Subject: Re: RTnet sendmmsg and ENOBUFS
>
> NON-ANDRITZ SOURCE: BE CAUT
>
> >
> >>
> >>> 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 o
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
differe
> -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.
>
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
[
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: 0
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 ]---
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 caused
> -Original Message-
> From: Jan Kiszka
> Sent: Montag, 18. November 2019 18:22
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org)
> Subject: Re: Deadlock during debugging
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
> -Original Message-
> From: Jan Kiszka
> Sent: Dienstag, 19. November 2019 07:51
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org)
> Subject: Re: Deadlock during debugging
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
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 ther
> -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
Hello,
I looked at this sycall, as lttng makes use of it, and the last posts on this
ML would imply that Xenomai is using "IPI" aswell.
This raises a few questions:
- Could an linux app (like lttng), that uses the membarrier syscall
create IRQs/IPIs that ultimately negative affect rea
Hello,
Systemwide traces would require the same clock, so Linux processes use
CLOCK_MONOTONIC (they normally do by default),
Kernel traces should do so too (ktime_get_mono_fast_ns).
Xenomai Processes/Thread have no reliable to produce matching traces. The idea
would be to
configure the tracing f
> -Original Message-
> From: Jan Kiszka
> Sent: Mittwoch, 27. November 2019 18:06
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org)
> Cc: mathieu.desnoy...@efficios.com
> Subject: Re: Request: offer CLOCK_HOST_MONOTONIC for systemwide
> tracing
>
> N
> -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 v
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).
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 p
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)
1 - 100 of 170 matches
Mail list logo
