Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> 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 on
Gilles Chanteperdrix wrote:
> 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 lim
Jan Kiszka wrote:
> 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 al
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
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
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
Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
Linux (e.g. via xnpod_suspend_thread(). Unfortunately, there is
no way to force a shadow thread into secondary mode to handle pending
Linux signals unless that thread issues a syscall
Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Linux (e.g. via xnpod_suspend_thread(). Unfortunately, there is
>>> no way to force a shadow thread into secondary mode to handle pending
>>> Linux signals unless that thread issues a syscall once in a while. And
>>> that rais
Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Linux (e.g. via xnpod_suspend_thread(). Unfortunately, there is
>> no way to force a shadow thread into secondary mode to handle pending
>> Linux signals unless that thread issues a syscall once in a while. And
>> that raises the question if we sho
Jan Kiszka wrote:
> Linux (e.g. via xnpod_suspend_thread(). Unfortunately, there is
> no way to force a shadow thread into secondary mode to handle pending
> Linux signals unless that thread issues a syscall once in a while. And
> that raises the question if we shouldn't improve this as well while
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 is
invoked, causing the current
21 matches
Mail list logo
