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: External email. Do not click on
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
on links or open attachments
> >>>> unless you know the sender and that the content is safe.
> >>>>
> >>>> On 19.08.21 17:24, Lange Norbert wrote:
> >>>>>
> >>>>>
> >>>>>> -Original Message-----
> &g
;> To: Lange Norbert ; Xenomai
> >>>> (xenomai@xenomai.org)
> >>>> Subject: Re: cobalt_assert_nrt should use __cobalt_pthread_kill
> >>>>
> >>>>
> >>>>
> >>>> CAUTION: External email. Do not
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 open attachments
> >> unless you know the send
nks or open attachments unless you
> know the sender and that the content is safe.
>
> On 19.08.21 11:56, Lange Norbert via Xenomai wrote:
> > Hello,
> >
> > I have some small slight issue with the cobalt_assert_nrt function,
> > incase a violation is dete
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
or open attachments unless you
> know the sender and that the content is safe.
>
> On 03.08.21 13:18, Lange Norbert via Xenomai wrote:
> > Hello,
> >
> > There is some bigger kernel oops when an rtnet device is unbound from
> > linux but still accessible via ioctl.
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
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"
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änner 2021
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
> -Original Message-
> From: Xenomai On Behalf Of John Ho via
> Xenomai
> Sent: Donnerstag, 15. Oktober 2020 16:37
> To: xenomai@xenomai.org
> Subject: rtnet not locating ethercat slaves
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> Hi all, thank you so
On debian, dh_shlibdeps (dpkg-shlibdeps) should be able to diagnose this aswell.
Norbert
> -Original Message-
> From: Xenomai On Behalf Of Jan Kiszka
> via Xenomai
> Sent: Dienstag, 15. September 2020 12:39
> To: Vitaly Chikunov ; Xenomai
> Subject: Re: [PATCH] libs: Add linking
> -Original Message-
> From: Xenomai On Behalf Of Jan Holtz via
> Xenomai
> Sent: Montag, 20. Juli 2020 07:05
> To: xenomai@xenomai.org
> Subject: malloc and stl container
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
>Hello,
>i am using xenomai
Hello,
I am reconnecting the ML.
I am not aware of any good documentation for SCHED_TP,
but there is an example in smokey/sched-tp which Id use as starting point.
I don’t think SCHED_TP will measurable affect latency, outside of course in
the case where its “by design” (process needs to wait
ACHMENTS.
>
>
> On 13.07.20 15:37, Lange Norbert via Xenomai wrote:
> > Hello,
> >
> > I am using Xenomai 3.1 and I tried once more to tie Linux to Core0, and RT
> to the remaining Cores.
> > It seems that both Linux and Xenomai favor Core0, as rtnet-sta
Hello,
I am using Xenomai 3.1 and I tried once more to tie Linux to Core0, and RT to
the remaining Cores.
It seems that both Linux and Xenomai favor Core0, as rtnet-stack rtnet-rtpc
seem to always run on that.
Network drivers will process the IRQs on all cores, but realistally all are
handles
> -Original Message-
> From: Alexander Frolov
> Sent: Montag, 13. Juli 2020 13:09
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org)
> Subject: Re: FW: Xenomai with isolcpus and workqueue task
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> On 7/13/20
> -Original Message-
> From: Xenomai On Behalf Of Alexander
> Frolov via Xenomai
> Sent: Montag, 13. Juli 2020 12:27
> To: xenomai@xenomai.org
> Subject: Re: FW: Xenomai with isolcpus and workqueue task
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
>
(fwd to list)
> -Original Message-
> From: Lange Norbert
> Sent: Montag, 13. Juli 2020 10:34
> To: Alexander Frolov
> Subject: RE: Xenomai with isolcpus and workqueue task
>
>
>
> > -Original Message-
> > From: Xenomai On Behalf Of Alexander
> > Frolov via Xenomai
> > Sent:
Hello,
I just found the corectl tool (and the related syscall). After a stop, all
threads previously using cobalt services end up zombified,
apparently never getting reaped. (Only useful thing is to reboot then IMHO).
Maybe if this tool could shutdown everything cleanly, I would run this before
> -Original Message-
> From: Philippe Gerum
> Sent: Montag, 15. Juni 2020 12:03
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) ;
> 'jan.kis...@siemens.com'
> Subject: Re: Still getting Deadlocks with condition variables
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> -Original Message-
> From: Philippe Gerum
> Sent: Mittwoch, 10. Juni 2020 18:48
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) ;
> 'jan.kis...@siemens.com'
> Subject: Re: Still getting Deadlocks with condition variables
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS
> -Original Message-
> From: Philippe Gerum
> Sent: Montag, 8. Juni 2020 16:17
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org)
> Subject: Re: Still getting Deadlocks with condition variables
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> On 6/8/20
ubject: Re: Still getting Deadlocks with condition variables
> >>
> >> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
> >>
> >>
> >> On 05.06.20 16:36, Lange Norbert via Xenomai wrote:
> >>> Hello,
> &
> -Original Message-
> From: Philippe Gerum
> Sent: Sonntag, 7. Juni 2020 22:16
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org)
> Subject: Re: Still getting Deadlocks with condition variables
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> On
ACHMENTS.
>
>
> On 05.06.20 16:36, Lange Norbert via Xenomai wrote:
> > Hello,
> >
> > I brought this up once or twice at this ML [1], I am still getting
> > some occasional lockups. Now the first time without running under an
> > debugger,
> >
> > H
Hello,
I brought this up once or twice at this ML [1], I am still getting some
occasional lockups. Now the first time without running under an debugger,
Harwdare is a TQMxE39M (Goldmont Atom)
Kernel: 4.19.124-cip27-xeno12-static x86_64
I-pipe Version: 12
Xenomai Version: 3.1
Glibc Version 2.28
> -Original Message-
> From: Jan Kiszka
> Sent: Montag, 2. März 2020 16:59
> To: Lange Norbert
> Subject: Re: Ipipe-Patch for kernel version 5.4.23
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> Offlist by intention?
Nope, just Outlook hating me.
omai (xenomai@xenomai.org)
> >> Subject: Re: Interrupt timeout
> >>
> >> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
> >>
> >>
> >> On 25.02.20 16:40, Lange Norbert via Xenomai wrote:
> >>>
> >>>
&g
ACHMENTS.
>
>
> On 25.02.20 16:40, Lange Norbert via Xenomai wrote:
> >
> >
> >> -Original Message-
> >> From: Greg Gallagher
> >> Sent: Dienstag, 25. Februar 2020 16:24
> >> To: Lange Norbert
> >> Cc: Xenomai (xe
ENT, LINKS OR
> ATTACHMENTS.
>
>
> Hi,
>
> On Tue, Feb 25, 2020 at 8:57 AM Lange Norbert via Xenomai
> wrote:
> >
> > Hello,
> >
> > I hope you can give me some pointers to understand why this Bug
> happened.
> > It seems an interrupt
Hello,
I hope you can give me some pointers to understand why this Bug happened.
It seems an interrupt got lost somehow, maybe some issue with leveltriggers?
Note that I run on an Apollo Lake, which would normally use PINCTRL_BROXTON,
but that’s not fixed up for Xenomai yet. The system works
Hello Jan,
yes this fixes the issue for me, what's the downside of not using *_rcuidle,
is that a performance optimization?
Norbert Lange
> -Original Message-
> From: Jan Kiszka
> Sent: Montag, 17. Februar 2020 19:06
> To: Philippe Gerum ; Xenomai
>
> Cc: Lange Norbert
> Subject:
TS.
>
>
> On 17.02.20 17:57, Jan Kiszka via Xenomai wrote:
> > On 17.02.20 17:50, Lange Norbert via Xenomai wrote:
> >> I managed to narrow it down to this:
> >>
> >> trace-cmd start -e 'tlb:tlb_flush'
> >>
> >> Seems to bug
I managed to narrow it down to this:
trace-cmd start -e 'tlb:tlb_flush'
Seems to bug the kernel even if no cobalt thread is running, only a rt_igb and
the rtnet stack.
> -Original Message-
> From: Xenomai On Behalf Of Lange
> Norbert via Xenomai
> Sent: Montag, 17. Feb
Hello,
Enabling traces still can lockup Xenomai, apparently if any cobalt thread is
running.
trace-cmd record -e all
[11598.080137] I-pipe: Detected illicit call from head domain 'Xenomai'
[11598.080137] into a regular Linux service
[11598.091070] CPU: 3 PID: 948 Comm: sshd Not tainted
> -Original Message-
> From: Xenomai On Behalf Of Kloock,
> Lennard via Xenomai
> Sent: Montag, 10. Februar 2020 14:11
> To: xenomai@xenomai.org
> Subject: Installing RTnet
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> Hello all,
>
> i have succesfully
TS.
>
>
> On 20.01.20 19:03, Lange Norbert via Xenomai wrote:
> > Hello,
> >
> > I got a deadlock while running through gdbserver, this is an
> > implementation of a synchronized queue, Fup side waits via condition
> variable, main wants to push data, but main fai
Hello,
I got a deadlock while running through gdbserver, this is an implementation of
a synchronized queue,
Fup side waits via condition variable, main wants to push data, but main fails
to acquire the mutex.
The mutex is an errorchecking type, without priority inheritance, and not used
AUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> On 15.01.20 18:12, Lange Norbert via Xenomai wrote:
> >
> > Reverting commit #0393b8720128 "ptp: fix the race between the release of
> ptp_clock and cdev" fixes the issue.
> > I don't see any locks or simila
Reverting commit #0393b8720128 "ptp: fix the race between the release of
ptp_clock and cdev" fixes the issue.
I don't see any locks or similar involved to it doesn't appear to be related to
Xenomai at all.
Norbert
> -Original Message-
> From: Xenomai On Behalf Of Lan
Hello,
I had no problem with the previous 4.19.89 (and versions back to 4.14), but
this kernel does not like unloading the linux eth driver.
Will try with the plain linux kernel in the coming days, but any help is
appreciated.
Norbert
ethpci=":01:00.0"
echo "$ethpci" >
This is some scheme I am trying to cook up for our internal development,
which should produce production binaries, and offering them for local
development.
It uses Xenomai 3.0.9, some time after 3.1 is released and I am less stressed
with other work I plan to clean up all involved stuff, so
, LINKS OR
> ATTACHMENTS.
>
>
> On 16.12.19 18:49, Lange Norbert via Xenomai wrote:
> > Seems to me like a lot instances of XENO_DRIVERS_NET_CHECKED should
> be
> > renamed to XENO_DRIVERS_RTNET_CHECKED
> >
>
> Good catch, was always wrong. But as the higher-lev
;
>
> On 16.12.19 13:36, Lange Norbert via Xenomai wrote:
> > Hi,
> >
> > I have such a setup, where I push/pull ethernet traffic from an Application
> every millisecond:
> >
> > [App] ---IDDP--> [RTSwitch] --ETH_P_ALL socket--> [rt_igp] [App]
&g
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
Seems to me like a lot instances of XENO_DRIVERS_NET_CHECKED should be renamed
to XENO_DRIVERS_RTNET_CHECKED
Mit besten Grüßen / Kind regards
NORBERT LANGE
AT-RD3
ANDRITZ HYDRO GmbH
Eibesbrunnergasse 20
1120 Vienna / AUSTRIA
p: +43 50805 56684
> -Original Message-
> From: Jan Kiszka
> Sent: Montag, 16. Dezember 2019 15:30
> 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.
>
>
> On 16.12.19 14:45, Jan
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
> >>>>
> >
ect: Re: stalled head domain with 3.1rc4
> >>
> >> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
> >>
> >>
> >> On 13.12.19 13:25, Lange Norbert via Xenomai wrote:
> >>> Same thing with panic trace enabled (another, lo
Hi,
I have such a setup, where I push/pull ethernet traffic from an Application
every millisecond:
[App] ---IDDP--> [RTSwitch] --ETH_P_ALL socket--> [rt_igp]
[App] <---IDDP-- [RTSwitch] <--ETH_P_ALL socket-- [rt_igp]
[Tun] <---tundev---/
Now I am sometimes missing packets that the other side
;
>
> On 13.12.19 13:25, Lange Norbert via Xenomai wrote:
> > Same thing with panic trace enabled (another, longer trace with 4000
> > samples attached)
> >
> > [ 292.743618] I-pipe: Detected stalled head domain, probably caused by a
> bug.
> > [ 2
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:
1 [
> 1842.790801] RAX: ffda RBX: 004013b0 RCX:
> 0045f5d9 [ 1842.797944] RDX: 0001 RSI:
> 7fff2286365f RDI: 0005 [ 1842.805086] RBP:
> 7fff228636c0 R08: R09: [
> 1842.812230] R10: 00
01
> [ 1842.790801] RAX: ffda RBX: 004013b0 RCX:
> 0045f5d9
> [ 1842.797944] RDX: 0001 RSI: 7fff2286365f RDI:
> 0005
> [ 1842.805086] RBP: 00007fff228636c0 R08: R09:
>
> [ 1842.8122
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
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).
> -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
ON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> On 27.11.19 17:20, Lange Norbert via Xenomai wrote:
> > Hello,
> >
> > Systemwide traces would require the same clock, so Linux processes use
> > CLOCK_MONOTONIC (they normally do by
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
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
TS.
>
>
> On 21.11.19 11:26, Lange Norbert via Xenomai wrote:
> > 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 generall
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
adlock during debugging
> >>
> >> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
> >>
> >>
> >> On 18.11.19 17:24, Lange Norbert via Xenomai wrote:
> >>> One more,
> >>>
> >>> Note that there
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
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
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:
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
> -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.
>
>
> On 15.11.19 13:37, Lange
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
>
> >
> >>
> >>> 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
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.
>
&
, LINKS OR
> ATTACHMENTS.
>
>
> On 13.11.19 16:18, Lange Norbert via Xenomai wrote:
> > 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" (pa
;
>
> On 13.11.19 16:10, Lange Norbert via Xenomai wrote:
> > 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
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
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
t; 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
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
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
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
>
> -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 CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> -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
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)
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
> -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.
>
>
> On 09.10.19 12:49, Lange Norbert
> -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.
>
>
&
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
MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> On 29.08.19 16:12, Lange Norbert via Xenomai wrote:
> >
> > I ran into a rather big issue with linux filehandles I use Xenomai
> >
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
A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> On 8/22/19 5:16 PM, Lange Norbert via Xenomai wrote:
> >> -Original Message-
> >> From: Jan Kiszka
> >> Sent: Donnerstag, 22. August
LEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> On 21.08.19 14:12, Lange Norbert via Xenomai wrote:
> > Hello,
> >
> > I use Xenomai master on ipipe-core-4.19.60-x86-5.
> > I start out with an affinity mask of 0xF, in the
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
> -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
>
> -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 SOURCE: AS A SECURITY MEASURE,
MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> On 09.07.19 16:49, Lange Norbert via Xenomai wrote:
> > Hi,
> >
> > I am opening a packetsocket, which is supposed to be realtime.
> -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 SOURCE: AS A SECURITY
;>
> >>> Subject: Re: ipipe 4.19: spurious APIC interrupt when setting rt_igp
> >>> to up
> >>>
> >>> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE,
> PLEASE
> >>> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHM
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
1 - 100 of 140 matches
Mail list logo
