> -Original Message-
> From: Jan Kiszka
> Sent: Freitag, 13. Dezember 2019 14:44
> 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.
>
> -Original Message-
> From: Jan Kiszka
> Sent: Montag, 16. Dezember 2019 13:57
> 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.
>
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
> -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.
&
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
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
>
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
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
> -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 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
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
> -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
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)
> -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
> -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
> -Original Message-
> From: Jan Kiszka
> Sent: Dienstag, 25. Februar 2020 18:05
> To: Lange Norbert ; Greg Gallagher
>
> Cc: Xenomai (xenomai@xenomai.org)
> Subject: Re: Interrupt timeout
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATT
> -Original Message-
> From: Greg Gallagher
> Sent: Dienstag, 25. Februar 2020 16:24
> To: Lange Norbert
> Cc: Xenomai (xenomai@xenomai.org) ; Philippe
> Gerum (r...@xenomai.org)
> Subject: Re: Interrupt timeout
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONT
> -Original Message-
> From: Jan Kiszka
> Sent: Dienstag, 25. Februar 2020 16:47
> To: Lange Norbert ; Greg Gallagher
>
> Cc: Xenomai (xenomai@xenomai.org)
> Subject: Re: Interrupt timeout
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATT
> -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 intenti
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
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
> -Original Message-
> From: Jan Kiszka
> Sent: Montag, 17. Februar 2020 18:16
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org)
> Subject: Re: Still some lockups when enabling ftrace
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMEN
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
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
> -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
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
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" >
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
> -Original Message-
> From: Jan Kiszka
> Sent: Dienstag, 21. Jänner 2020 18:46
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org)
> Subject: Re: Cobalt deadlock for no apparent reason
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMEN
> -Original Message-
> From: Jan Kiszka
> Sent: Mittwoch, 15. Jänner 2020 23:07
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org)
> Subject: Re: 4.19.94-cip18-xeno10 regression: bugs out when changing
> drivers
>
> NON-ANDRITZ SOURCE: BE C
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
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 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
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
(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 Alexa
> -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
> AT
, LINKS OR
> ATTACHMENTS.
>
>
> -----Original Message-
> >> From: Lange Norbert
> >> Sent: Montag, 13. Juli 2020 10:34
> >> To: Alexander Frolov
> >> Subject: RE: Xenomai with isolcpus and workqueue task
> >>
> >>
> >>
>
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: Jan Kiszka
> Sent: Montag, 13. Juli 2020 19:52
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org)
> Subject: Re: xenomai.supported_cpus not working as intended?
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATT
> -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 C
> -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 C
> -Original Message-
> From: Jan Kiszka
> Sent: Montag, 8. Juni 2020 12:09
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org)
> Subject: Re: Still getting Deadlocks with condition variables
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATT
> -Original Message-
> From: Jan Kiszka
> Sent: Freitag, 5. Juni 2020 17:40
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org)
> Subject: Re: Still getting Deadlocks with condition variables
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATT
> -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
>
> -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
> A
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: 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
for its timeslice).
Norbert
From: 孙世龙 sunshilong
Sent: Samstag, 18. Juli 2020 07:51
To: Lange Norbert
Cc: Meng, Fino
Subject: Re: Are there some methods that could limit how much CPU resources
could be a single Xenomai process or thread?
Hi, Norbert
Thank you for the clarification.
>You
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
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"
> -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,
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
> -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
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,
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
101 - 163 of 163 matches
Mail list logo
