Stéphane ANCELOT wrote:
> my linux user task uses a system() call in order to call a bash script
> to restart the realtime task as follow :
>
> user interface C call :
> system("restart_task.sh");
> give back hand to user interface
>
>
>
>
>
> bash script restart_task.sh :
>
Jan Kiszka wrote:
Jan Kiszka wrote:
Hi all,
fiddling with latest Xenomai trunk and 2.3.x on one of our robots (there
is still a bug in trunk /wrt broken timeouts of rt_dev_read on
xeno_16550A - different issue...), I ran into a weird behaviour of
rtcanrecv:
I have a continuous stream of a few
Hi Jan,
Jan Kiszka wrote:
Hi all,
fiddling with latest Xenomai trunk and 2.3.x on one of our robots (there
is still a bug in trunk /wrt broken timeouts of rt_dev_read on
xeno_16550A - different issue...), I ran into a weird behaviour of
rtcanrecv:
I have a continuous stream of a few thousand p
Hi Philippe,
the "trivial" bugs are fixed already: see #2152 for the reason why
rt_dev_read timeouts took too long (the timer mode was ignored by
xnsynch_sleep_on), and I also found a yet invisible bug in
rtdm_toseq_init that would have picked the wrong time base (#2153).
Now just that rtcanrecv
Wolfgang Grandegger wrote:
> Hi Jan,
>
> Jan Kiszka wrote:
>> Hi all,
>>
>> fiddling with latest Xenomai trunk and 2.3.x on one of our robots (there
>> is still a bug in trunk /wrt broken timeouts of rt_dev_read on
>> xeno_16550A - different issue...), I ran into a weird behaviour of
>> rtcanrecv:
On Thu, 2007-02-08 at 09:38 +0100, Jan Kiszka wrote:
> Hi Philippe,
>
> the "trivial" bugs are fixed already: see #2152 for the reason why
> rt_dev_read timeouts took too long (the timer mode was ignored by
> xnsynch_sleep_on),
Ok.
> and I also found a yet invisible bug in
> rtdm_toseq_init tha
Philippe Gerum wrote:
> On Thu, 2007-02-08 at 09:38 +0100, Jan Kiszka wrote:
>> Hi Philippe,
>>
>> the "trivial" bugs are fixed already: see #2152 for the reason why
>> rt_dev_read timeouts took too long (the timer mode was ignored by
>> xnsynch_sleep_on),
>
> Ok.
>
>> and I also found a yet inv
On Thu, 2007-02-08 at 10:21 +0100, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Thu, 2007-02-08 at 09:38 +0100, Jan Kiszka wrote:
> >> Hi Philippe,
> >>
> >> the "trivial" bugs are fixed already: see #2152 for the reason why
> >> rt_dev_read timeouts took too long (the timer mode was ignored by
Jan Kiszka wrote:
> Philippe Gerum wrote:
>> On Thu, 2007-02-08 at 09:38 +0100, Jan Kiszka wrote:
>>> Hi Philippe,
>>>
>>> the "trivial" bugs are fixed already: see #2152 for the reason why
>>> rt_dev_read timeouts took too long (the timer mode was ignored by
>>> xnsynch_sleep_on),
>> Ok.
>>
>>> a
Jan Kiszka wrote:
> Wolfgang Grandegger wrote:
>> Hi Jan,
>>
>> Jan Kiszka wrote:
>>> Hi all,
>>>
>>> fiddling with latest Xenomai trunk and 2.3.x on one of our robots (there
>>> is still a bug in trunk /wrt broken timeouts of rt_dev_read on
>>> xeno_16550A - different issue...), I ran into a weird
Hi,
Is there a reason why pthread_set_{mode,name}_np are not allowed to be
called from a kernel space POSIX thread ?
If there is none, please apply the patch below.
Thanks.
Index: ksrc/skins/posix/thread.c
===
--- ksrc/skins/posix/
Stelian Pop wrote:
> Hi,
>
> Is there a reason why pthread_set_{mode,name}_np are not allowed to be
> called from a kernel space POSIX thread ?
>
> If there is none, please apply the patch below.
No, this is completely unintended. Thanks.
--
12 matches
Mail list logo