ommit 352b0355f617bfbb38f9bd7b1f7d74967f44c857
Author: Ronny Meeus
Date: Mon Jan 25 15:11:52 2021 +0100
copperplate/timerobj: fix corrupted timer list.
We observe an issue that the timer-list gets corrupted resulting in an
endless loop executed by the timer-server thread.
Durin
commit b38a39bcd758872201e71c07a24d8b5e7f26c3ac
Author: Ronny Meeus
Date: Mon Jan 25 15:11:52 2021 +0100
We observe an issue that the timer-list gets corrupted resulting in an
endless loop executed by the timer-server thread.
During the processing of the timeout list, a pointer to
Op vr 22 jan. 2021 om 08:57 schreef Ronny Meeus :
> Op vr 4 dec. 2020 om 16:29 schreef Philippe Gerum :
> >
> >
> > Ronny Meeus writes:
> >
> > > Op di 1 dec. 2020 om 14:51 schreef Philippe Gerum :
> > >>
> > >>
> > >> Ron
Op vr 4 dec. 2020 om 16:29 schreef Philippe Gerum :
>
>
> Ronny Meeus writes:
>
> > Op di 1 dec. 2020 om 14:51 schreef Philippe Gerum :
> >>
> >>
> >> Ronny Meeus via Xenomai writes:
> >>
> >> > Op di 1 dec. 2020 om 12:06 schre
Op di 1 dec. 2020 om 14:51 schreef Philippe Gerum :
>
>
> Ronny Meeus via Xenomai writes:
>
> > Op di 1 dec. 2020 om 12:06 schreef Jan Kiszka :
> >>
> >> On 01.12.20 11:26, Ronny Meeus via Xenomai wrote:
> >> > Hello Xenomai community,
> >&g
Op di 1 dec. 2020 om 12:06 schreef Jan Kiszka :
>
> On 01.12.20 11:26, Ronny Meeus via Xenomai wrote:
> > Hello Xenomai community,
> >
> > it looks like we have a race condition in the timer object handling.
> > The scope of the below mentioned issue is the alarm int
Hello Xenomai community,
it looks like we have a race condition in the timer object handling.
The scope of the below mentioned issue is the alarm interface of the
alchemy skin:
int rt_alarm_start(RT_ALARM *alarm, RTIME value, RTIME interval)
The documentation mentions that this start can be calle
Op vr 31 jan. 2020 om 14:30 schreef Jan Kiszka :
>
> On 31.01.20 12:37, Ronny Meeus wrote:
> > Op vr 31 jan. 2020 om 11:41 schreef Jan Kiszka :
> >>
> >> On 31.01.20 10:46, Ronny Meeus via Xenomai wrote:
> >>> Hello
> >>>
> >>> Fo
Op vr 31 jan. 2020 om 11:41 schreef Jan Kiszka :
>
> On 31.01.20 10:46, Ronny Meeus via Xenomai wrote:
> > Hello
> >
> > Following patch corrects an issue when passing the EVOBJ_ALL mode to the
> > eventobj_wait function.
> >
> > The expected behavi
Hello
Following patch corrects an issue when passing the EVOBJ_ALL mode to the
eventobj_wait function.
The expected behavior of this function to my understanding is:
eventobj_wait in EVOBJ_ALL mode is supposed to return when all the bits
specified by the caller are set in core.value (=pending eve
On Thu, Sep 7, 2017 at 12:24 PM, Ronny Meeus wrote:
> Hello
>
> has threadX ever been considered as a candidate to be simulated by Xenomai?
> Or does somebody already have a private implementation available that
> has good enough quality to be upstreamed?
>
> Any informati
assume it is a generic problem it the common
services of the registry's obstack are used.
>
> On 08/31/2017 04:02 PM, Ronny Meeus wrote:
>> Hello
>>
>> I have a test application that creates a psos queue and sends a lot of
>> messages to it.
>> The applic
Hello
has threadX ever been considered as a candidate to be simulated by Xenomai?
Or does somebody already have a private implementation available that
has good enough quality to be upstreamed?
Any information related to this is much appreciated.
Thanks
Ronny
___
Hello
I have a test application that creates a psos queue and sends a lot of
messages to it.
The application code can be found below.
Depending on the memory configuration it can be that error are
generated after some
time but that is not the issue. When dump the queue in the debug
interface I se
On Fri, Jan 6, 2017 at 12:00 PM, Philippe Gerum wrote:
> On 01/06/2017 10:54 AM, Ronny Meeus wrote:
>> On Fri, Jan 6, 2017 at 10:29 AM, Philippe Gerum wrote:
>>> On 01/06/2017 10:21 AM, Ronny Meeus wrote:
>>>> That logic I had seen before.
>>>> As I un
On Fri, Jan 6, 2017 at 10:29 AM, Philippe Gerum wrote:
> On 01/06/2017 10:21 AM, Ronny Meeus wrote:
>> That logic I had seen before.
>> As I understand the code it just tries 3 times to connect to the daemon
>> and if not successful, it just tries to start it again and reconn
On Tue, Dec 27, 2016 at 10:56 AM, Philippe Gerum wrote:
> On 12/13/2016 08:23 AM, Ronny Meeus wrote:
>> Hello
>>
>> Context: we use the Mercury core (xenomai-3.0.3).
>>
>> in commit 880b3acbd876a65f8fbe8c27b09762b06c06e846:
>> copperplate/registry: force SCH
To keep the namespace as clean as possible for the applications
don't include standard header files.
diff --git a/include/psos/psos.h b/include/psos/psos.h
--- a/include/psos/psos.h
+++ b/include/psos/psos.h
@@ -24,7 +24,7 @@
#ifndef _XENOMAI_PSOS_PSOS_H
#define _XENOMAI_PSOS_PSOS_H
-#include
On Thu, Dec 15, 2016 at 6:25 PM, Philippe Gerum wrote:
> On 12/15/2016 05:16 PM, Ronny Meeus wrote:
>> On Thu, Dec 15, 2016 at 3:47 PM, Philippe Gerum wrote:
>>> On 12/15/2016 12:47 PM, Ronny Meeus wrote:
>>>> bootstrap.o is linked to the application code.
>
On Thu, Dec 15, 2016 at 3:47 PM, Philippe Gerum wrote:
> On 12/15/2016 12:47 PM, Ronny Meeus wrote:
>> bootstrap.o is linked to the application code.
>> In case the execution of the static constructors is postponed
>> in the applicaion and the auto-init feature is used, t
On Fri, Dec 9, 2016 at 11:48 AM, Philippe Gerum wrote:
> On 12/06/2016 03:56 PM, Ronny Meeus wrote:
>> Hello
>>
>> Round-robin scheduling is implemented in Mercury by
>> starting a per-thread timer that sends a signal to the thread
>> when its budget is consu
bootstrap.o is linked to the application code.
In case the execution of the static constructors is postponed
in the applicaion and the auto-init feature is used, the
xenomai_init is called 2 times:
- once in the path of the wrap_main
- later in the context of the static constructor
A check is alre
Before this patch the system memory pool's (tlsf variant) behavior was
to grow in case allocations were done when depleted. This is a
contradiction with the expected behavior (see mem-pool-size tunable
documentation). When the pool is depleted, an error should be retuned
instead of growing the pool
Hello
Context: we use the Mercury core (xenomai-3.0.3).
in commit 880b3acbd876a65f8fbe8c27b09762b06c06e846:
copperplate/registry: force SCHED_OTHER on helper threads
of
Sun Jul 26 12:37:15 2015 +0200
The scheduling class of the registry threads is forced to
SCHED_OTHER at priority 0.
This chang
In the pSOS interface region 0 can be used by applications to allocate
memory from. It contains 'system' memory and is created by default during
system init. Region 0 is currently not supported by the xenomai psos skin.
This patch adds functionality to configure the total size and the unit
size by
This patch introduces a tunable in the mercury copperplate code that allows
to put an upper limit on the priority used by the created thread objects.
Before this patch the complete OS scheduler's FIFO range was used and it was
not possible to restrict it. Restricting it can be useful in case other
Hello
Round-robin scheduling is implemented in Mercury by
starting a per-thread timer that sends a signal to the thread
when its budget is consumed.
There are several good reasons to implement round-robin
in this way, one of them being the complete freedom at
application level to decide what the
Before this patch the system memory pool's (tlsf variant) behavior was
to grow in case allocations were done when depleted. This is a
contradiction with the expected behavior (see mem-pool-size tunable
documentation). When the pool is depleted, an error should be retuned
instead of growing the pool
In the pSOS interface region 0 can be used by applications to allocate
memory from. It contains 'system' memory and is created by default during
system init. Region 0 is currently not supported by the xenomai psos skin.
This patch adds functionality to configure the total size and the unit
size by
This patch introduces a tunable in the mercury copperplate code that allows
to put an upper limit on the priority used by the created thread objects.
Before this patch the complete OS scheduler's FIFO range was used and it was
not possible to restrict it. Restricting it can be useful in case other
On Tue, Dec 6, 2016 at 1:06 PM, Philippe Gerum wrote:
> On 12/05/2016 05:36 PM, Ronny Meeus wrote:
>> Hello
>>
>> we use the pSOS skin over the Mercury core.
>>
>> I'm preparing a set of patches that introduce new tunables.
>> What I observe is that in
Hello
we use the pSOS skin over the Mercury core.
I'm preparing a set of patches that introduce new tunables.
What I observe is that in a small test applications it works well but once I
start to use these in our real applications, I observe that the tunables are
not called.
I have identified th
On Sun, Dec 4, 2016 at 11:26 AM, Philippe Gerum wrote:
> On 12/03/2016 09:39 PM, Ronny Meeus wrote:
>> On Sat, Dec 3, 2016 at 6:18 PM, Philippe Gerum wrote:
>>> On 11/30/2016 08:30 AM, Ronny Meeus wrote:
>>>> This patch introduces a weak function in the mercury cop
On Sat, Dec 3, 2016 at 6:18 PM, Philippe Gerum wrote:
> On 11/30/2016 08:30 AM, Ronny Meeus wrote:
>> This patch introduces a weak function in the mercury copperplate code
>> that allows to put an upper limit on the priority used by the created thread
>> objects.
>&g
On Fri, Dec 2, 2016 at 3:01 PM, Philippe Gerum wrote:
> On 12/02/2016 02:03 PM, Ronny Meeus wrote:
>> Hello
>>
>> Context: I'm using the pSOS interface over the Mercury core (version 3.0.3).
>>
>> I have a question about option:
>> –mem-pool-size
>&g
Hello
Context: I'm using the pSOS interface over the Mercury core (version 3.0.3).
I have a question about option:
–mem-pool-size
described on page
http://xenomai.org/2015/05/application-setup-and-init/
Is the parameter specifying the maximum size that will be used Xenomai
or is this the initial
On Thu, Dec 1, 2016 at 6:44 PM, Philippe Gerum wrote:
> On 11/30/2016 10:42 AM, Ronny Meeus wrote:
>> In the pSOS interface region 0 can be used by applications to allocate
>> memory from. It contains 'system' memory and is created by default during
>> system
In the pSOS interface region 0 can be used by applications to allocate
memory from. It contains 'system' memory and is created by default during
system init. Region 0 is currently not supported by the xenomai psos skin.
This patch adds functionality to configure a 'pseudo 0' region that will
be us
This patch introduces a weak function in the mercury copperplate code
that allows to put an upper limit on the priority used by the created thread
objects.
Before this patch the complete OS scheduler's FIFO range was used and it was
not possible to restrict it. Restricting it can be useful in case
The psos.h file pollutes the application's namespace with defines
of the boilerplate code because the tunables.h is included. In our
application we already have a definition of the list_entry macro,
resulting in a redefinition. The psos.h should be kept clean.
Following small test program clearly
In boilerplate function 'get_program_name', basename is used.
When libgen.h is incuded in your program, the basename gets the POSIX
version (no const char*, see 'man basename'):
char *basename(char *path);
This results in the following compiler warning:
boilerplate/setup.h: In function 'const cha
On Tue, Nov 29, 2016 at 9:55 AM, Philippe Gerum wrote:
> On 11/29/2016 07:32 AM, Ronny Meeus wrote:
>> The psos.h file pollutes the application's namespace with defines
>> of the boilerplate code because the tunables.h is included. In our
>> application we alread
The psos.h file pollutes the application's namespace with defines
of the boilerplate code because the tunables.h is included. In our
application we already have a definition of the list_entry macro,
resulting in a redefinition. The psos.h should be kept clean.
Following small test program clearly
On Mon, Nov 28, 2016 at 4:51 PM, Philippe Gerum wrote:
> On 11/28/2016 01:18 PM, Ronny Meeus wrote:
> > This patch adds support for mips/mips64 in configure.ac.
> > It has been tested on Mercury only.
> >
> > diff --git a/configure.ac b/configure.ac
> > --- a/co
In boilerplate function 'get_program_name', basename is used.
When libgen.h is incuded in your program, the basename gets the POSIX
version (no const char*, see 'man basename'):
char *basename(char *path);
This results in the following compiler warning:
boilerplate/setup.h: In function 'const cha
This patch adds support for mips/mips64 in configure.ac.
It has been tested on Mercury only.
diff --git a/configure.ac b/configure.ac
--- a/configure.ac
+++ b/configure.ac
@@ -135,6 +135,10 @@ case "$build_for" in
XENO_TARGET_ARCH=blackfin
CONFIG_XENO_DEFAULT_PERIOD=10
Hello
the attached patch adds support for mips/mips64 to the confugure.ac script.
Has been used/tested for the Mercury core only.
---
Best regards,
Ronny
-- next part --
A non-text attachment was scrubbed...
Name: configure_ac_mips-support.patch
Type: application/octet-str
On Wed, Feb 10, 2016 at 7:06 AM, Ronny Meeus wrote:
> On Tue, Feb 9, 2016 at 9:23 PM, Ronny Meeus wrote:
>
>> Philippe
>>
>> I have ported the patch to our version of Xenomai and started the test.
>> It runs already for several minutes without issues so it looks
On Tue, Feb 9, 2016 at 9:23 PM, Ronny Meeus wrote:
> Philippe
>
> I have ported the patch to our version of Xenomai and started the test.
> It runs already for several minutes without issues so it looks like
> the problem is solved also with the patch below.
> I will let it
On Tue, Feb 9, 2016 at 12:23 PM, Philippe Gerum wrote:
> On 02/05/2016 09:27 AM, Ronny Meeus wrote:
>> Hello
>>
>> we are using the pSOS interface on top of the Mercury core.
>> Under heavy stress conditions we see sporadically that messages are
>> getting los
Hello
we are using the pSOS interface on top of the Mercury core.
Under heavy stress conditions we see sporadically that messages are
getting lost.
Attached you find a test application (multi_queue.c) that helped me
to find the issue and verify that the attached patch actually solves
the issue a
On Sat, May 2, 2015 at 8:48 PM, Ronny Meeus wrote:
>> This is a priority inversion issue caused by the handshake mechanism
>> between the caller of t_delete() and the killed task finalizer. I
>> eventually reproduced it after I figured out that pinning all tasks on
>> the
> This is a priority inversion issue caused by the handshake mechanism
> between the caller of t_delete() and the killed task finalizer. I
> eventually reproduced it after I figured out that pinning all tasks on
> the same CPU was required to trigger such bug. This patch should help:
>
> http://git
On Thu, Apr 30, 2015 at 3:09 PM, Philippe Gerum wrote:
> On 04/30/2015 02:39 PM, Ronny Meeus wrote:
>> If I run the test I see:
>>
>> /tmp # ./task_delete
>> Start of test
>> Create and start main task:Create task M:
>> Create task L:
>> Start task M:
On Thu, Apr 30, 2015 at 12:01 PM, Philippe Gerum wrote:
> On 04/30/2015 10:14 AM, Ronny Meeus wrote:
>> Hello
>>
>> we are using the xenomai-forge mercury core together with the pSOS interface.
>>
>> We observe following issue: we have 3 tasks at different prio
Hello
we are using the xenomai-forge mercury core together with the pSOS interface.
We observe following issue: we have 3 tasks at different priorities
(see test code attached).
The task with the middle priority is running forever (while (1)).
The higest prio task is responsible cleaning up the
On Thu, Dec 18, 2014 at 6:21 PM, Ronny Meeus wrote:
>>
>> That implies you know the prios of the involved threads. Doesn't sound
>> like a generic solution either.
>>
>> Jan
>>
>
> I think Xenomai knows the involved threads.
>
> Philippe,
&g
>
> That implies you know the prios of the involved threads. Doesn't sound
> like a generic solution either.
>
> Jan
>
I think Xenomai knows the involved threads.
Philippe,
is the list of waiting threads not kept in the thread object?
Ronny
___
Xenoma
On Thu, Dec 18, 2014 at 4:35 PM, Jan Kiszka wrote:
> On 2014-12-18 16:30, Gilles Chanteperdrix wrote:
>> On Thu, Dec 18, 2014 at 04:25:40PM +0100, Ronny Meeus wrote:
>>> On Thu, Dec 18, 2014 at 4:04 PM, Gilles Chanteperdrix
>>> wrote:
>>>> On Thu, Dec 1
On Thu, Dec 18, 2014 at 4:04 PM, Gilles Chanteperdrix
wrote:
> On Thu, Dec 18, 2014 at 03:58:52PM +0100, Jan Kiszka wrote:
>> On 2014-12-18 15:12, Gilles Chanteperdrix wrote:
>> > Otherwise, have you tried some alternate libc, such as musl:
>> > http://www.musl-libc.org/
>> >
>> > The following bl
> Philippe, Jan
>>
>> as long as this issue is not fixed in glibc, it is not OK to use
>> conditional variables
>> in application space for real-time applications in my opinion.
>
> ...when combining them with PI mutexes, right. For real-time QEMU/KVM, I
> worked around this by using prio-ceiling m
On Thu, Dec 18, 2014 at 10:04 AM, Jan Kiszka wrote:
> On 2014-12-18 09:00, Ronny Meeus wrote:
>>>
>>> A release of the glibc that fixes this issue. I must admit that I did
>>> not track this problem lately. Jan likely knows better here.
>>>
>>
>>
>
> A release of the glibc that fixes this issue. I must admit that I did
> not track this problem lately. Jan likely knows better here.
>
Jan,
what version glibc solves the priority inversion issue on conditional variables?
I already tried the glibc 2.18 but the issue is still there.
Regards,
R
On Tue, Dec 16, 2014 at 6:58 PM, Philippe Gerum wrote:
> On 12/16/2014 06:36 PM, Ronny Meeus wrote:
>> On Sun, Dec 7, 2014 at 5:26 PM, Ronny Meeus wrote:
>>> Hello
>>>
>>> we are using the xenomai-forge implementation.
>>> We from time to time s
On Sun, Dec 7, 2014 at 5:26 PM, Ronny Meeus wrote:
> Hello
>
> we are using the xenomai-forge implementation.
> We from time to time see an issue that the timer-internal thread is
> consuming a complete core. It is seen when we send broadcast traffic that
> needs to be handled b
Hello
we are using the xenomai-forge implementation.
We from time to time see an issue that the timer-internal thread is
consuming a complete core. It is seen when we send broadcast traffic that
needs to be handled by the Linux kernel (ARP).
The kernel thread's priority handling the packets in th
On Tue, Oct 21, 2014 at 10:24 AM, Gilles Chanteperdrix <
gilles.chanteperd...@xenomai.org> wrote:
> On 10/21/2014 10:14 AM, Philippe Gerum wrote:
> > On 10/20/2014 10:24 PM, Ronny Meeus wrote:
> >> Hello
> >>
> >> we are using the xenomai-forge mercury
Hello
we are using the xenomai-forge mercury core together with the pSOS
interface.
What I observe is that our application is spending a lot of time in the
timer-handling.
Please note that the application consists of a lot of threads (>150) that
use things like pSOS event timers (periodic and one-
>
>
>
>
> IIUC, this would add the quite unexpected requirement of having to reopen
> a file for getting fresh data. read() should actually (re-)read the current
> object state each time it is invoked, and not resend some frozen state
> collected by the corresponding open() indefinitely.
>
> e.g. t
>
>
> test code snippet:
>
> static void test_task(u_long a,u_long b,u_long c,u_long d)
> {
> while (1)
> tm_wkafter(1000);
> }
>
> static void main_task(u_long a,u_long b,u_long c,u_long d)
> {
> u_long tid,args[4] = {0,0,0,0};
> int i;
> char name[32];
>
> for (i=0;i<256;i++) {
>
On Tue, Oct 1, 2013 at 12:13 PM, K. De Mey wrote:
> Hello everybody,
>
> We use xenomai-forge for a project. I however came across a problem when
> adding the "--enabled-registry" option.
> It seems that the FUSE functions (for example fuse_main()) that are being
> used are the compat functions o
Hello
If the sm_p service is called with the SM_NOWAIT flag and the semaphore is
not available the EWOULDBLOCK error code is returned to the application.
This is not correct since the application expects to see only pSOS
errorcodes.
The attached patch solves the issue.
I have also included a sma
On Tue, Jun 4, 2013 at 2:41 PM, Philippe Gerum wrote:
> On 06/04/2013 12:56 PM, Ronny Meeus wrote:
>
>> Hello
>>
>> we are currently running with recent version of xenomai-forge.
>> The issue we see is a crash while running the attached application code
>>
Hello
we are currently running with recent version of xenomai-forge.
The issue we see is a crash while running the attached application code
(pSOS interface).
Basically the test creates a number of "chained" (called batches) tasks.
After setting up the batch, the first task starts a timer and whe
On Mon, Mar 25, 2013 at 4:52 PM, Philippe Gerum wrote:
> On 03/25/2013 03:16 PM, Ronny Meeus wrote:
>> Hello
>>
>> I'm doing some more tests related to task creation and deletion.
>> The complete testcode is attached to the mail.
>>
>> I basically
Hello
I'm doing some more tests related to task creation and deletion.
The complete testcode is attached to the mail.
I basically have a task that creates, starts and deletes other tasks in a loop:
for (i=0;i<500;i++) {
printf("Priority %d\n",i);
check("t_create loop3",t_create ("TEST"
On Sat, Mar 23, 2013 at 10:21 AM, Philippe Gerum wrote:
> On 03/23/2013 10:16 AM, Philippe Gerum wrote:
>>
>> On 03/22/2013 08:05 PM, Ronny Meeus wrote:
>>>
>>> On Fri, Mar 22, 2013 at 7:11 PM, Philippe Gerum wrote:
>>>>
>>>> On 03/15/
On Fri, Mar 22, 2013 at 7:11 PM, Philippe Gerum wrote:
> On 03/15/2013 02:10 PM, Ronny Meeus wrote:
>>
>> Hello
>>
>> In august last year I reported a problem with round-robin scheduling
>> in the pSOS skin.
>> See mail thread "xenomai-forge: round-ro
On Fri, Mar 15, 2013 at 3:52 PM, Ronny Meeus wrote:
> The pSOS skin uses a default timeslice of 1000 sec.
> In comments it is mentioned that the value is specified in ms
> while the place where the variable is used assumes that it is
> in ticks.
>
> Rename time_slice to time
intended 1ms
to 5ms to reduce the overhead a bit.
Signed-off-by: Ronny Meeus
diff --git a/lib/psos/init.c b/lib/psos/init.c
--- a/lib/psos/init.c
+++ b/lib/psos/init.c
@@ -39,7 +39,7 @@ unsigned int psos_long_names;
static unsigned int clock_resolution = 100; /* 1ms */
-static unsigned int
Hello
In august last year I reported a problem with round-robin scheduling
in the pSOS skin.
See mail thread "xenomai-forge: round-robin scheduling in pSOS skin".
Now that we stepped up to the latest version of Xenomai-forge, I was
retrying the same test I did at that time.
I observe that the sit
On Fri, Mar 8, 2013 at 4:06 PM, Philippe Gerum wrote:
> On 03/08/2013 04:03 PM, Philippe Gerum wrote:
>>
>> On 03/08/2013 03:16 PM, Ronny Meeus wrote:
>>>
>>> Hello
>>>
>>> I see that the interface of copperplate_init has been changed from:
>&
Hello
I see that the interface of copperplate_init has been changed from:
void copperplate_init(int argc, char *const argv[]);
to
void copperplate_init(int *argcp, char *const **argvp);
This is disturbing if I have an application that needs to be run on
the 2 versions of xenomai.
Is there any co
On Thu, Mar 7, 2013 at 8:51 PM, Ronny Meeus wrote:
> On Thu, Mar 7, 2013 at 4:56 PM, Philippe Gerum wrote:
>> On 03/07/2013 11:32 AM, Philippe Gerum wrote:
>>>
>>> On 03/07/2013 11:02 AM, Ronny Meeus wrote:
>>>>
>>>>
>>>> thanks for
On Thu, Mar 7, 2013 at 4:56 PM, Philippe Gerum wrote:
> On 03/07/2013 11:32 AM, Philippe Gerum wrote:
>>
>> On 03/07/2013 11:02 AM, Ronny Meeus wrote:
>>>
>>>
>>> thanks for the patch.
>>> With this patch the test application is working fin
On Wed, Mar 6, 2013 at 4:49 PM, Philippe Gerum wrote:
> On 03/06/2013 03:32 PM, Ronny Meeus wrote:
>>
>> si_code=SI_TIMER, si_pid=51, si_uid=0, si_value={int=273724880,
>> ptr=0x1050b5d0}}, NULL, 16) = 32
>> 11309 15.442127 +++ killed by SIGKILL +++
>>
>&g
On Wed, Mar 6, 2013 at 2:49 PM, Philippe Gerum wrote:
> On 03/02/2013 12:13 PM, Ronny Meeus wrote:
>
>> An update on the investigation:
>> I was able to make this issue disappear by changing the timeout value
>> of the smallest timers we use.
>> We use a couple of
On Tue, Mar 5, 2013 at 3:08 PM, Philippe Gerum wrote:
> On 03/05/2013 01:43 PM, Ronny Meeus wrote:
>>
>> On Sat, Mar 2, 2013 at 12:13 PM, Ronny Meeus
>> wrote:
>>>
>>> On Fri, Mar 1, 2013 at 9:41 AM, Philippe Gerum wrote:
>>>>
>
On Tue, Mar 5, 2013 at 3:47 PM, Philippe Gerum wrote:
> On 03/05/2013 03:25 PM, Ronny Meeus wrote:
>>
>> On Tue, Mar 5, 2013 at 3:08 PM, Philippe Gerum wrote:
>>>
>>> On 03/05/2013 01:43 PM, Ronny Meeus wrote:
>>>>
>>>>
>
On Tue, Mar 5, 2013 at 3:08 PM, Philippe Gerum wrote:
> On 03/05/2013 01:43 PM, Ronny Meeus wrote:
>>
>> On Sat, Mar 2, 2013 at 12:13 PM, Ronny Meeus
>> wrote:
>>>
>>> On Fri, Mar 1, 2013 at 9:41 AM, Philippe Gerum wrote:
>>>>
>
On Sat, Mar 2, 2013 at 12:13 PM, Ronny Meeus wrote:
> On Fri, Mar 1, 2013 at 9:41 AM, Philippe Gerum wrote:
>> On 03/01/2013 09:30 AM, Gilles Chanteperdrix wrote:
>>>
>>> On 03/01/2013 09:30 AM, Philippe Gerum wrote:
>>>
>>>> On 03/01/2013 09:26 A
13 09:22 AM, Philippe Gerum wrote:
>>>>
>>>>> On 02/28/2013 09:22 PM, Thomas De Schampheleire wrote:
>>>>>>
>>>>>> On Thu, Feb 28, 2013 at 9:10 PM, Gilles Chanteperdrix
>>>>>> wrote:
>>>>>>>
>
On Thu, Feb 28, 2013 at 9:10 PM, Gilles Chanteperdrix
wrote:
> On 02/28/2013 08:19 PM, Ronny Meeus wrote:
>
>> Hello
>>
>> we are using the PSOS interface of Xenomai forge, running completely
>> in user-space using the mercury code.
>> We deploy our appl
Hello
we are using the PSOS interface of Xenomai forge, running completely
in user-space using the mercury code.
We deploy our application on different processors, one product is
running on PPC multicore (P4040, P4080, P4034) and another one on
Cavium (8 core device).
The Linux version we use is 2
94 matches
Mail list logo
