[Xenomai] [PATCH 1/2] lib/alchemy: fix rt_mutex_create return values

From: Henning Schild rt_mutex_create turned an -EPERM from the cobalt kernel syscall path into an -EEXIST. If you have a model where threads create their shadows on demand, when seeing the first -EPERM, that return value must not be changed. Signed-off-by: Henning

[Xenomai] [PATCH 2/2] lib/alchemy: change API context tags

From: Henning Schild changing the prio always changes the secondary-mode thread as well see: http://xenomai.org/migrating-from-xenomai-2-x-to-3-x/#Scheduling Signed-off-by: Henning Schild --- lib/alchemy/task.c | 2 +- 1 file changed,

Re: [Xenomai] [PATCH 1/2] lib/alchemy: fix rt_mutex_create return values

I am not sure i like what is happening there. Maybe we should just allow rt_mutex_create to return whatever syncluster_addobj returns. I just looked at the code and the pattern where any error from syncluster_addobj is turned into an EEXIST is in several places. We have an application that

Re: [Xenomai] secondary mode switches on rt_task_set_priority

On 07/11/2017 12:30 PM, Henning Schild wrote: > Am Tue, 11 Jul 2017 11:45:20 +0200 > schrieb Philippe Gerum : > >> On 07/11/2017 10:41 AM, Henning Schild wrote: >>> Hi, >>> >>> i was asked to assist debugging a case where a SIGXCPU is received >>> after calling

Re: [Xenomai] secondary mode switches on rt_task_set_priority

Am Tue, 11 Jul 2017 11:45:20 +0200 schrieb Philippe Gerum : > On 07/11/2017 10:41 AM, Henning Schild wrote: > > Hi, > > > > i was asked to assist debugging a case where a SIGXCPU is received > > after calling rt_task_set_priority. According to the docs that call > > should not

[Xenomai] strerror or symerror

When looking at some of the test programs coming with xenomai 3 I noticed that they use symerror instead of strerror. e.g. in ./testsuite/gpiotest/gpiotest.c I saw that within xenomai symerror is defined in ./lib/boilerplate/ancillaries.c, and is xenomai specific. Should I use symerror

Re: [Xenomai] secondary mode switches on rt_task_set_priority

On 07/11/2017 10:41 AM, Henning Schild wrote: > Hi, > > i was asked to assist debugging a case where a SIGXCPU is received > after calling rt_task_set_priority. According to the docs that call > should not cause secondary mode switches, but it seems it does. This is a documented issue:

Re: [Xenomai] Cobalt core install linker problem

Am Tue, 11 Jul 2017 14:22:02 + schrieb Simone Zucchi : > Hello everybody, > I'm trying to compile xenomai tools --with-core=cobalt but I keep ha > ving issues on latency tool, seems on linking. > If I try to build --with-core=mercury switch it works flawlessly: ...

Re: [Xenomai] Kernel CONFIG_MIGRATION flag

Am Tue, 11 Jul 2017 14:50:21 + schrieb Simone Zucchi : > Hello everybody, > I hope I won't be considered a spammer because of 2 mails in half an > hour :) No, but for sending the same mail twice in 10s ;). Henning > I couldn't really find any doc about

[Xenomai] Kernel CONFIG_MIGRATION flag

Hello everybody, I hope I won't be considered a spammer because of 2 mails in half an hour :) I couldn't really find any doc about CONFIG_MIGRATION flag and how it could worsen latency over Xenomai. I wanted to disable it, just to be sure, but I can't really work it out.

[Xenomai] Kernel CONFIG_MIGRATION flag

Hello everybody, I hope I won't be considered a spammer because of 2 mails in half an hour :) I couldn't really find any doc about CONFIG_MIGRATION flag and how it could worsen latency over Xenomai. I wanted to disable it, just to be sure, but I can't really work it out.

Re: [Xenomai] Kernel Warning : I-pipe: Detected illicit call from head domain 'Xenomai'

Hi Philippe, Thanks for the answer. Can you refer me to any DMA driver that you integrated with ipipe ? I found out that the DMA driver running is that idam64 and as you mentioned it hooks to the generic DMA engine frame work with the handlers implemented in idma64.c . I still have one question

Re: [Xenomai] Kernel CONFIG_MIGRATION flag

Am Tue, 11 Jul 2017 14:50:15 + schrieb Simone Zucchi : > Hello everybody, > I hope I won't be considered a spammer because of 2 mails in half an > hour :) I couldn't really find any doc about CONFIG_MIGRATION flag > and how it could worsen latency over Xenomai.

[Xenomai] secondary mode switches on rt_task_set_priority

Hi, i was asked to assist debugging a case where a SIGXCPU is received after calling rt_task_set_priority. According to the docs that call should not cause secondary mode switches, but it seems it does. Xenomai 3.0.5 kernel 4.4.43 I did not start digging yet but wanted to ask if someone has