On Fri, 2006-12-08 at 22:35 +0100, Philippe Gerum wrote:
On Fri, 2006-12-08 at 20:05 +0100, Jan Kiszka wrote:
Philippe Gerum wrote:
On Fri, 2006-12-08 at 19:02 +0100, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Index: ksrc/nucleus/shadow.c
Jan Kiszka wrote:
Thomas Wiedemann wrote:
Hi,
there seems to be a bug in rt_task_create(). When no more memory is
available, the module usage counter of xeno_native is decremented. I
guess it is not incremented before, however, so the counter gets 0 and
wraps then to a negative number. It is
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Thomas Wiedemann wrote:
Hi,
there seems to be a bug in rt_task_create(). When no more memory is
available, the module usage counter of xeno_native is decremented. I
guess it is not incremented before, however, so
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Thomas Wiedemann wrote:
Hi,
there seems to be a bug in rt_task_create(). When no more memory is
available, the module usage counter of xeno_native is decremented.
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Index: ksrc/nucleus/shadow.c
===
--- ksrc/nucleus/shadow.c (révision 1930)
+++ ksrc/nucleus/shadow.c (copie de travail)
@@ -888,6 +888,9 @@
p =
Thomas Wiedemann wrote:
Hi,
there seems to be a bug in rt_task_create(). When no more memory is
available, the module usage counter of xeno_native is decremented. I
guess it is not incremented before, however, so the counter gets 0 and
wraps then to a negative number. It is therefore not
