On Thu, 2006-06-22 at 12:54 +0200, Jan Kiszka wrote:
> Hi,
>
> having to load xeno_timerbench and to open its device just for
> triggering the I-pipe tracer was not a smart decision of mine. This
> patch makes is more comfortable to call the tracer from user space.
> Index: include/asm-generic/sy
On Thu, 2006-06-22 at 18:12 +0200, Jan Kiszka wrote:
> Hi Gilles,
>
> I think some regression slipped into the rt-pthread lib. This example no
> longer works on my box (thread is not executed):
The issue is in src/skins/posix/thread.c. The trampoline does not even
attempt to fire the thread body
On Fri, 2006-06-23 at 10:50 +0200, Philippe Gerum wrote:
> On Thu, 2006-06-22 at 18:12 +0200, Jan Kiszka wrote:
> > Hi Gilles,
> >
> > I think some regression slipped into the rt-pthread lib. This example no
> > longer works on my box (thread is not executed):
>
> The issue is in src/skins/posix/
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hello,
I'm currently implementing a RTDM real-time CAN driver, which raises the
the problem of adding the driver to the Xenomai source tree. My first
idea was to provide RTCAN as a patch for Xenomai:
So you prefer to maintain RTCAN out-of-tree on t
Philippe Gerum wrote:
> On Thu, 2006-06-22 at 18:12 +0200, Jan Kiszka wrote:
>> Hi Gilles,
>>
>> I think some regression slipped into the rt-pthread lib. This example no
>> longer works on my box (thread is not executed):
>
> The issue is in src/skins/posix/thread.c. The trampoline does not even
>
Philippe Gerum wrote:
> On Thu, 2006-06-22 at 12:54 +0200, Jan Kiszka wrote:
>> Hi,
>>
>> having to load xeno_timerbench and to open its device just for
>> triggering the I-pipe tracer was not a smart decision of mine. This
>> patch makes is more comfortable to call the tracer from user space.
>
>
On Thu, 2006-06-22 at 23:37 +0200, Niklaus Giger wrote:
> Hi
>
> Here is my patch for improved versions of xeno-info/load/config/test
> as well as a Ruby test script for the maintainers.
>
> The modified scripts pass the test for most options to xeno-test. The only
> exception is "-v" for verbos
On Fri, 2006-06-23 at 11:27 +0200, Jan Kiszka wrote:
> >> Index: include/nucleus/ipipe_trace.h
> >> ===
> >
> > This file should go to include/asm-generic/ since it depends on the
> > underlying real-time enabler (i.e. I-pipe). This w
Hi all,
Is there a particular reason to enforce the queuing policy
to the "highest priority" thread for a variable condition?
I would expect that we can also specify a FIFO queue at the
creation mode of such an object, as it is the case
of other synchronization objects.
Thanks
On Fri, 2006-06-23 at 11:48 +0200, ROSSIER Daniel wrote:
>
>
> Hi all,
>
>
>
> Is there a particular reason to enforce the queuing policy to the
> "highest priority" thread for a variable condition?
>
The reason was that condvar support for the native skin should closely
follow the POSIX b
Philippe Gerum wrote:
> On Fri, 2006-06-23 at 11:27 +0200, Jan Kiszka wrote:
Index: include/nucleus/ipipe_trace.h
===
>>> This file should go to include/asm-generic/ since it depends on the
>>> underlying real-time enabler (i
Jan Kiszka wrote:
> Jan Kiszka wrote:
> > Hi,
> >
> > wondering why suddenly things crash on invoking the latency test, I
> > realised that I turned the nucleus into a module which was not yet
> > loaded. Here is the oops in this case:
>
> Correction: the nucleus was still compiled in, th
Niklaus Giger wrote:
> Hi Gilles
>
> I did some more testing, about how the vxWorks skins handles
> taskSpawn/taskInit and taskName.
>
> I did not discover any differences between running it on my board under
> vxworks and under using the Xenomai simulator on my PowerBook.
>
> There a
Jan Kiszka wrote:
> Jan Kiszka wrote:
> > Hi,
> >
> > wondering why suddenly things crash on invoking the latency test, I
> > realised that I turned the nucleus into a module which was not yet
> > loaded. Here is the oops in this case:
>
> Correction: the nucleus was still compiled in, th
On Fri, 2006-06-23 at 15:41 +0200, Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
> > Jan Kiszka wrote:
> > > Hi,
> > >
> > > wondering why suddenly things crash on invoking the latency test, I
> > > realised that I turned the nucleus into a module which was not yet
> > > loaded. Here is th
Philippe Gerum wrote:
> On Fri, 2006-06-23 at 15:41 +0200, Gilles Chanteperdrix wrote:
> > Jan Kiszka wrote:
> > > Jan Kiszka wrote:
> > > > Hi,
> > > >
> > > > wondering why suddenly things crash on invoking the latency test, I
> > > > realised that I turned the nucleus into a module
Gilles Chanteperdrix wrote:
> misinterpretation. When issuing syscalls with a fixed muxid whereas
> there is no interface corresponding to this muxid, the nucleus crashes,
> but it is acceptable, user-space interfaces should issue an
> __xn_sys_bind syscall first.
This is not even possible, si
17 matches
Mail list logo
