Hi Gilles
Thanks a lot and i truly admire your netiquette.
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distr
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> Jan Kiszka wrote:
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Hi,
>>
>> the watchdog is currently broken in trunk ("zombie [...] would not
>> die..."). In fact, it should also be broken in older version
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> Jan Kiszka wrote:
Meanwhile I played with some light-weight approach to relax a thread
that received a signal (according to do_sigwake_event). Worked, but only
once due to a limitation (if not bug) of I-pipe x86:
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> Jan Kiszka wrote:
Meanwhile I played with some light-weight approach to relax a thread
that received a signal (according to do_sigwake_event). Worked, but only
once due to a limitation (if not bug) of I-pipe x86:
Jan Kiszka wrote:
> Philippe Gerum wrote:
>> Jan Kiszka wrote:
>>> Philippe Gerum wrote:
Jan Kiszka wrote:
> Hi,
>
> the watchdog is currently broken in trunk ("zombie [...] would not
> die..."). In fact, it should also be broken in older versions, but only
> recent thread
Jan Kiszka wrote:
> Philippe Gerum wrote:
>> Jan Kiszka wrote:
>>> Meanwhile I played with some light-weight approach to relax a thread
>>> that received a signal (according to do_sigwake_event). Worked, but only
>>> once due to a limitation (if not bug) of I-pipe x86: in __ipipe_run_isr,
>>> it do
Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> Jan Kiszka wrote:
the watchdog strikes. The second one brought me to another issue: Raise
SIGKILL for the current thread and make sure that it can be processed by
Linux (e.g. via xnpod_suspend_thread(). Unfo
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Meanwhile I played with some light-weight approach to relax a thread
>> that received a signal (according to do_sigwake_event). Worked, but only
>> once due to a limitation (if not bug) of I-pipe x86: in __ipipe_run_isr,
>> it does not handle the case th
Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> Jan Kiszka wrote:
the watchdog strikes. The second one brought me to another issue: Raise
SIGKILL for the current thread and make sure that it can be processed by
Linux (e.g. via xnpod_suspend_thread(). Unfo
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> Jan Kiszka wrote:
Hi,
the watchdog is currently broken in trunk ("zombie [...] would not
die..."). In fact, it should also be broken in older versions, but only
recent thread termination rework made this
Jan Kiszka wrote:
> Philippe Gerum wrote:
>> Jan Kiszka wrote:
>>> Hi,
>>>
>>> the watchdog is currently broken in trunk ("zombie [...] would not
>>> die..."). In fact, it should also be broken in older versions, but only
>>> recent thread termination rework made this visible.
>>>
>>> When a Xenoma
Andreas Glatz wrote:
> Hi,
>
> On Mon, 2009-03-09 at 17:08 +0100, Philippe Gerum wrote:
>> Andreas Glatz wrote:
>>> Hi,
>>>
>>> Calling rt_queue_create in a real-time task is supposed to fail
>>> according to the documentation.
>>>
>> It fails from kernel space, otherwise, from user-space, your a
Jan Kiszka wrote:
> Philippe Gerum wrote:
>> Jan Kiszka wrote:
>>> the watchdog strikes. The second one brought me to another issue: Raise
>>> SIGKILL for the current thread and make sure that it can be processed by
>>> Linux (e.g. via xnpod_suspend_thread(). Unfortunately, there is
>>> no way to f
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Hi,
>>
>> the watchdog is currently broken in trunk ("zombie [...] would not
>> die..."). In fact, it should also be broken in older versions, but only
>> recent thread termination rework made this visible.
>>
>> When a Xenomai CPU hog is caught by the w
Hi,
On Mon, 2009-03-09 at 17:08 +0100, Philippe Gerum wrote:
> Andreas Glatz wrote:
> > Hi,
> >
> > Calling rt_queue_create in a real-time task is supposed to fail
> > according to the documentation.
> >
>
> It fails from kernel space, otherwise, from user-space, your application
> would
> si
Andreas Glatz wrote:
> Hi,
>
> Calling rt_queue_create in a real-time task is supposed to fail
> according to the documentation.
>
It fails from kernel space, otherwise, from user-space, your application would
simply be moved to a Linux context automatically for processing the
rt_queue_create(
Jan Kiszka wrote:
> Hi,
>
> the watchdog is currently broken in trunk ("zombie [...] would not
> die..."). In fact, it should also be broken in older versions, but only
> recent thread termination rework made this visible.
>
> When a Xenomai CPU hog is caught by the watchdog, xnpod_delete_thread
I do not have Xenomai code in front of me, but I see no reason why
this should be a problem but I don't have Xenomai code easily
accessible right now so I can't provide any further insight.
Steven
___
Xenomai-core mailing list
Xenomai-core@gna.org
Hi,
On Mon, 2009-03-09 at 10:36 -0400, Steven Seeger wrote:
> Andreas,
>
> I do not know your situation but it is generally better to not
> allocate things in realtime contexts because it is not deterministic.
Of course :) So my plan is to preallocate the memory for the
memory pool of all queu
Vandana Sasidharan wrote:
> Hi
> Can anyone tell me what tool chain is required to build a test set-up for
> the xenosim simulator?
1- we already answered this question;
2- your are replying to a mail which is unrelated, for us people which
use references-aware mailers, this makes your mail appea
Andreas,
I do not know your situation but it is generally better to not
allocate things in realtime contexts because it is not deterministic.
You may consider redesigning your applications to use pre-allocated
queues as it would be better overall.
Regards,
Steven
On Mar 9, 2009, at 10:20 A
Hi,
Calling rt_queue_create in a real-time task is supposed to fail
according to the documentation.
I found out, that the reason for this is, that the memory for
the queue memory pool is allocated with vmalloc/kmalloc.
Is there another reason?
I still would like to be able to call rt_queue_cr
Hi
Can anyone tell me what tool chain is required to build a test set-up for
the xenosim simulator?
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipien
[ Updated according to discussion. ]
xnshadow_relax is no longer needed as do_exit, the caller of this hook,
always runs in secondary mode, ie. over the ROOT thread. Enforce this
assumptions by leaving a XENO_BUGON behind.
And as the target thread is relaxed already, ie. suspended, there is
also
Jan Kiszka wrote:
> Philippe Gerum wrote:
>> Jan Kiszka wrote:
>>> Philippe Gerum wrote:
Jan Kiszka wrote:
> Hi,
>
> this looks suspicious to me:
>
> static inline void do_taskexit_event(struct task_struct *p)
> {
> ...
> if (xnpod_shadow_p())
>
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Hi,
>>
>> this looks suspicious to me:
>>
>> static inline void do_taskexit_event(struct task_struct *p)
>> {
>> ...
>> if (xnpod_shadow_p())
>> xnshadow_relax(0);
>>
>> A) The only call context of this hook is do_exit() - and that
Jan Kiszka wrote:
> Philippe Gerum wrote:
>> Jan Kiszka wrote:
>>> Hi,
>>>
>>> this looks suspicious to me:
>>>
>>> static inline void do_taskexit_event(struct task_struct *p)
>>> {
>>> ...
>>> if (xnpod_shadow_p())
>>> xnshadow_relax(0);
>>>
>>> A) The only call context of this
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> Jan Kiszka wrote:
Hi,
this looks suspicious to me:
static inline void do_taskexit_event(struct task_struct *p)
{
...
if (xnpod_shadow_p())
xnshadow_relax(0);
[ Enhanced version, removing more unneeded code. ]
xnshadow_relax is no longer needed as do_exit, the caller of this hook,
always runs in secondary mode, ie. over the ROOT thread. Enforce this
assumptions by leaving a XENO_BUGON behind.
And as the target thread is relaxed already, ie. suspended,
29 matches
Mail list logo
