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 also be broken in older versions, but only
recent
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 limitation (if not bug) of
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 only
once due to a
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 is
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(cpu-hog). Unfortunately, there is
no way to force a
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 Xenomai CPU hog is caught by
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 visible.
When a Xenomai
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(cpu-hog). Unfortunately,
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 that a
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(cpu-hog). Unfortunately,
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 termination rework made this
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: in
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: in
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 versions, but only
recent thread termination
Jan Kiszka wrote:
Linux (e.g. via xnpod_suspend_thread(cpu-hog). 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
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Linux (e.g. via xnpod_suspend_thread(cpu-hog). 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
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Linux (e.g. via xnpod_suspend_thread(cpu-hog). 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
17 matches
Mail list logo
