Jan Kiszka wrote:
Am 11.11.2010 16:46, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
I just hope we finally converge over a solution. Looks like all
possibilities have been explored now. A few more comments on this one:
It probably makes sense to group the status bits accordingly (both their
Am 11.11.2010 16:46, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
I just hope we finally converge over a solution. Looks like all
possibilities have been explored now. A few more comments on this one:
It probably makes sense to group the status bits accordingly (both their
values and
Jan Kiszka wrote:
I just hope we finally converge over a solution. Looks like all
possibilities have been explored now. A few more comments on this one:
It probably makes sense to group the status bits accordingly (both their
values and definitions) and briefly document on which status field
Jan Kiszka wrote:
Anyway, after some thoughts, I think we are going to try and make the
current situation work instead of going back to the old way.
You can find the patch which attempts to do so here:
http://sisyphus.hd.free.fr/~gilles/sched_status.txt
Ack. At last, this addresses the real
On Sun, 2010-11-07 at 02:00 +0100, Jan Kiszka wrote:
Am 06.11.2010 23:49, Philippe Gerum wrote:
On Sat, 2010-11-06 at 21:37 +0100, Gilles Chanteperdrix wrote:
Anders Blomdell wrote:
Gilles Chanteperdrix wrote:
Anders Blomdell wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am
Am 07.11.2010 09:31, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Anyway, after some thoughts, I think we are going to try and make the
current situation work instead of going back to the old way.
You can find the patch which attempts to do so here:
Jan Kiszka wrote:
Am 07.11.2010 09:31, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Anyway, after some thoughts, I think we are going to try and make the
current situation work instead of going back to the old way.
You can find the patch which attempts to do so here:
On Sun, 2010-11-07 at 09:31 +0100, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Anyway, after some thoughts, I think we are going to try and make the
current situation work instead of going back to the old way.
You can find the patch which attempts to do so here:
Am 07.11.2010 10:57, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 07.11.2010 09:31, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Anyway, after some thoughts, I think we are going to try and make the
current situation work instead of going back to the old way.
You can find the patch
Am 07.11.2010 11:03, Philippe Gerum wrote:
On Sun, 2010-11-07 at 09:31 +0100, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Anyway, after some thoughts, I think we are going to try and make the
current situation work instead of going back to the old way.
You can find the patch which attempts
Jan Kiszka wrote:
Am 07.11.2010 11:03, Philippe Gerum wrote:
On Sun, 2010-11-07 at 09:31 +0100, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Anyway, after some thoughts, I think we are going to try and make the
current situation work instead of going back to the old way.
You can find the
Am 07.11.2010 11:12, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 07.11.2010 11:03, Philippe Gerum wrote:
On Sun, 2010-11-07 at 09:31 +0100, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Anyway, after some thoughts, I think we are going to try and make the
current situation work instead
On Sun, 2010-11-07 at 11:14 +0100, Jan Kiszka wrote:
Am 07.11.2010 11:12, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 07.11.2010 11:03, Philippe Gerum wrote:
On Sun, 2010-11-07 at 09:31 +0100, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Anyway, after some thoughts, I think we are
Gilles Chanteperdrix wrote:
Anders Blomdell wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 05.11.2010 00:24, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 23:06, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
At first sight, here you are more breaking things than
Anders Blomdell wrote:
Gilles Chanteperdrix wrote:
Anders Blomdell wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 05.11.2010 00:24, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 23:06, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
At first sight, here you are more
On Sat, 2010-11-06 at 21:37 +0100, Gilles Chanteperdrix wrote:
Anders Blomdell wrote:
Gilles Chanteperdrix wrote:
Anders Blomdell wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 05.11.2010 00:24, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 23:06, Gilles
Am 06.11.2010 23:49, Philippe Gerum wrote:
On Sat, 2010-11-06 at 21:37 +0100, Gilles Chanteperdrix wrote:
Anders Blomdell wrote:
Gilles Chanteperdrix wrote:
Anders Blomdell wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 05.11.2010 00:24, Gilles Chanteperdrix wrote:
Jan Kiszka
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 05.11.2010 00:25, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 23:08, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
rework. Safer for now is likely to revert 56ff4329ff, keeping nucleus
debugging
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 05.11.2010 00:24, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 23:06, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
At first sight, here you are more breaking things than cleaning them.
Still, it has the SMP record for my test
Anders Blomdell wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 05.11.2010 00:24, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 23:06, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
At first sight, here you are more breaking things than cleaning them.
Still, it has the
Am 04.11.2010 01:13, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:56, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:44, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:18, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:11,
Jan Kiszka wrote:
Am 04.11.2010 01:13, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:56, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:44, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:18, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am
Am 04.11.2010 09:45, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 04.11.2010 01:13, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:56, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:44, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:18, Gilles
Jan Kiszka wrote:
Take a step back and look at the root cause for this issue again. Unlocked
if need-resched
__xnpod_schedule
is inherently racy and will always be (not only for the remote
reschedule case BTW).
Ok, let us examine what may happen with this code if we
Anders Blomdell wrote:
Probably being daft here; why not stop fiddling with remote CPU status
bits and always do a reschedule on IPI irq's?
That is what we had been doing for a long time, and stopped between
2.5.4 and 2.5.5, and this is what I say: maybe this was not such a good
idea.
--
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Take a step back and look at the root cause for this issue again. Unlocked
if need-resched
__xnpod_schedule
is inherently racy and will always be (not only for the remote
reschedule case BTW).
Ok, let us examine what may
Am 04.11.2010 10:16, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Take a step back and look at the root cause for this issue again. Unlocked
if need-resched
__xnpod_schedule
is inherently racy and will always be (not only for the remote
reschedule case BTW).
Ok, let
Am 04.11.2010 10:26, Jan Kiszka wrote:
Am 04.11.2010 10:16, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Take a step back and look at the root cause for this issue again. Unlocked
if need-resched
__xnpod_schedule
is inherently racy and will always be (not only for the
Jan Kiszka wrote:
Am 04.11.2010 10:26, Jan Kiszka wrote:
Am 04.11.2010 10:16, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Take a step back and look at the root cause for this issue again. Unlocked
if need-resched
__xnpod_schedule
is inherently racy and will always
Jan Kiszka wrote:
Am 04.11.2010 10:26, Jan Kiszka wrote:
Am 04.11.2010 10:16, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Take a step back and look at the root cause for this issue again. Unlocked
if need-resched
__xnpod_schedule
is inherently racy and will always be (not
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 10:26, Jan Kiszka wrote:
Am 04.11.2010 10:16, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Take a step back and look at the root cause for this issue again. Unlocked
if need-resched
__xnpod_schedule
is
Am 04.11.2010 14:18, Anders Blomdell wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 10:26, Jan Kiszka wrote:
Am 04.11.2010 10:16, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Take a step back and look at the root cause for this issue again.
Unlocked
if need-resched
Jan Kiszka wrote:
Am 04.11.2010 14:18, Anders Blomdell wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 10:26, Jan Kiszka wrote:
Am 04.11.2010 10:16, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Take a step back and look at the root cause for this issue again. Unlocked
Am 04.11.2010 15:53, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 04.11.2010 14:18, Anders Blomdell wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 10:26, Jan Kiszka wrote:
Am 04.11.2010 10:16, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Take a step back and look at the
Jan Kiszka wrote:
At first sight, here you are more breaking things than cleaning them.
Still, it has the SMP record for my test program, still runs with ftrace
on (after 2 hours, where it previously failed after maximum 23 minutes).
My version was indeed still buggy, I'm reworking it ATM.
Jan Kiszka wrote:
rework. Safer for now is likely to revert 56ff4329ff, keeping nucleus
debugging off.
That is not enough. This commit was followed by several others to fix
the fix. You know how things are, someone proposes a fix, which fixes
things for him, but it breaks in the other people
Am 04.11.2010 23:08, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
rework. Safer for now is likely to revert 56ff4329ff, keeping nucleus
debugging off.
That is not enough.
It is, I've reviewed the code today.
This commit was followed by several others to fix
the fix. You know how things
Am 04.11.2010 23:06, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
At first sight, here you are more breaking things than cleaning them.
Still, it has the SMP record for my test program, still runs with ftrace
on (after 2 hours, where it previously failed after maximum 23 minutes).
My
Jan Kiszka wrote:
Am 04.11.2010 23:06, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
At first sight, here you are more breaking things than cleaning them.
Still, it has the SMP record for my test program, still runs with ftrace
on (after 2 hours, where it previously failed after maximum 23
Jan Kiszka wrote:
Am 04.11.2010 23:08, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
rework. Safer for now is likely to revert 56ff4329ff, keeping nucleus
debugging off.
That is not enough.
It is, I've reviewed the code today.
The fallouts I am talking about are:
Am 05.11.2010 00:25, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 23:08, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
rework. Safer for now is likely to revert 56ff4329ff, keeping nucleus
debugging off.
That is not enough.
It is, I've reviewed the code today.
The
Am 05.11.2010 00:24, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 23:06, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
At first sight, here you are more breaking things than cleaning them.
Still, it has the SMP record for my test program, still runs with ftrace
on (after 2
Jan Kiszka wrote:
Am 05.11.2010 00:25, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 23:08, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
rework. Safer for now is likely to revert 56ff4329ff, keeping nucleus
debugging off.
That is not enough.
It is, I've reviewed the code
Am 05.11.2010 00:46, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 05.11.2010 00:25, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 23:08, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
rework. Safer for now is likely to revert 56ff4329ff, keeping nucleus
debugging off.
That
Jan Kiszka wrote:
Am 05.11.2010 00:46, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 05.11.2010 00:25, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 23:08, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
rework. Safer for now is likely to revert 56ff4329ff, keeping nucleus
Jan Kiszka wrote:
Am 05.11.2010 00:24, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 23:06, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
At first sight, here you are more breaking things than cleaning them.
Still, it has the SMP record for my test program, still runs with
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 05.11.2010 00:25, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 23:08, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
rework. Safer for now is likely to revert 56ff4329ff, keeping nucleus
debugging off.
That is not enough.
It
Anders Blomdell wrote:
Jan Kiszka wrote:
Am 01.11.2010 17:55, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 28.10.2010 11:34, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 28.10.2010 09:34, Anders Blomdell wrote:
Anders Blomdell wrote:
Anders Blomdell wrote:
Hi,
I'm trying to use
Am 03.11.2010 12:44, Anders Blomdell wrote:
Anders Blomdell wrote:
Jan Kiszka wrote:
Am 01.11.2010 17:55, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 28.10.2010 11:34, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 28.10.2010 09:34, Anders Blomdell wrote:
Anders Blomdell wrote:
Anders
Am 03.11.2010 12:50, Jan Kiszka wrote:
Am 03.11.2010 12:44, Anders Blomdell wrote:
Anders Blomdell wrote:
Jan Kiszka wrote:
Am 01.11.2010 17:55, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 28.10.2010 11:34, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 28.10.2010 09:34, Anders Blomdell
On 2010-11-03 12.55, Jan Kiszka wrote:
Am 03.11.2010 12:50, Jan Kiszka wrote:
Am 03.11.2010 12:44, Anders Blomdell wrote:
Anders Blomdell wrote:
Jan Kiszka wrote:
Am 01.11.2010 17:55, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 28.10.2010 11:34, Anders Blomdell wrote:
Jan Kiszka wrote:
Am
Am 03.11.2010 13:07, Anders Blomdell wrote:
On 2010-11-03 12.55, Jan Kiszka wrote:
Am 03.11.2010 12:50, Jan Kiszka wrote:
Am 03.11.2010 12:44, Anders Blomdell wrote:
Anders Blomdell wrote:
Jan Kiszka wrote:
Am 01.11.2010 17:55, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 28.10.2010 11:34,
Jan Kiszka wrote:
additional barrier. Can you check this?
diff --git a/include/nucleus/sched.h b/include/nucleus/sched.h
index df56417..66b52ad 100644
--- a/include/nucleus/sched.h
+++ b/include/nucleus/sched.h
@@ -187,6 +187,7 @@ static inline int xnsched_self_resched_p(struct xnsched
*sched)
Anders Blomdell wrote:
Jan Kiszka wrote:
additional barrier. Can you check this?
diff --git a/include/nucleus/sched.h b/include/nucleus/sched.h
index df56417..66b52ad 100644
--- a/include/nucleus/sched.h
+++ b/include/nucleus/sched.h
@@ -187,6 +187,7 @@ static inline int
Anders Blomdell wrote:
Anders Blomdell wrote:
Jan Kiszka wrote:
additional barrier. Can you check this?
diff --git a/include/nucleus/sched.h b/include/nucleus/sched.h
index df56417..66b52ad 100644
--- a/include/nucleus/sched.h
+++ b/include/nucleus/sched.h
@@ -187,6 +187,7 @@ static inline
Am 03.11.2010 17:46, Anders Blomdell wrote:
Anders Blomdell wrote:
Anders Blomdell wrote:
Jan Kiszka wrote:
additional barrier. Can you check this?
diff --git a/include/nucleus/sched.h b/include/nucleus/sched.h
index df56417..66b52ad 100644
--- a/include/nucleus/sched.h
+++
Jan Kiszka wrote:
Am 03.11.2010 17:46, Anders Blomdell wrote:
Anders Blomdell wrote:
Anders Blomdell wrote:
Jan Kiszka wrote:
additional barrier. Can you check this?
diff --git a/include/nucleus/sched.h b/include/nucleus/sched.h
index df56417..66b52ad 100644
--- a/include/nucleus/sched.h
On Wed, 2010-11-03 at 20:38 +0100, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 03.11.2010 17:46, Anders Blomdell wrote:
Anders Blomdell wrote:
Anders Blomdell wrote:
Jan Kiszka wrote:
additional barrier. Can you check this?
diff --git a/include/nucleus/sched.h
Am 03.11.2010 21:41, Philippe Gerum wrote:
On Wed, 2010-11-03 at 20:38 +0100, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 03.11.2010 17:46, Anders Blomdell wrote:
Anders Blomdell wrote:
Anders Blomdell wrote:
Jan Kiszka wrote:
additional barrier. Can you check this?
diff --git
Am 03.11.2010 23:03, Jan Kiszka wrote:
Am 03.11.2010 21:41, Philippe Gerum wrote:
On Wed, 2010-11-03 at 20:38 +0100, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 03.11.2010 17:46, Anders Blomdell wrote:
Anders Blomdell wrote:
Anders Blomdell wrote:
Jan Kiszka wrote:
additional barrier. Can
Am 03.11.2010 23:11, Jan Kiszka wrote:
Am 03.11.2010 23:03, Jan Kiszka wrote:
But we not not always use atomic ops for manipulating status bits (but
we do in other cases where this is no need - different story). This may
fix the race:
Err, nonsense. As we manipulate xnsched::status also
Jan Kiszka wrote:
Am 03.11.2010 23:11, Jan Kiszka wrote:
Am 03.11.2010 23:03, Jan Kiszka wrote:
But we not not always use atomic ops for manipulating status bits (but
we do in other cases where this is no need - different story). This may
fix the race:
Err, nonsense. As we manipulate
Am 04.11.2010 00:11, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 03.11.2010 23:11, Jan Kiszka wrote:
Am 03.11.2010 23:03, Jan Kiszka wrote:
But we not not always use atomic ops for manipulating status bits (but
we do in other cases where this is no need - different story). This may
fix
Jan Kiszka wrote:
Am 04.11.2010 00:11, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 03.11.2010 23:11, Jan Kiszka wrote:
Am 03.11.2010 23:03, Jan Kiszka wrote:
But we not not always use atomic ops for manipulating status bits (but
we do in other cases where this is no need - different
Am 04.11.2010 00:18, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:11, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 03.11.2010 23:11, Jan Kiszka wrote:
Am 03.11.2010 23:03, Jan Kiszka wrote:
But we not not always use atomic ops for manipulating status bits (but
we do in
Jan Kiszka wrote:
Am 04.11.2010 00:18, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:11, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 03.11.2010 23:11, Jan Kiszka wrote:
Am 03.11.2010 23:03, Jan Kiszka wrote:
But we not not always use atomic ops for manipulating status
Am 04.11.2010 00:44, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:18, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:11, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 03.11.2010 23:11, Jan Kiszka wrote:
Am 03.11.2010 23:03, Jan Kiszka wrote:
But we not
Jan Kiszka wrote:
Am 04.11.2010 00:44, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:18, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:11, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 03.11.2010 23:11, Jan Kiszka wrote:
Am 03.11.2010 23:03, Jan Kiszka
Am 04.11.2010 00:56, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:44, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:18, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:11, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 03.11.2010 23:11,
Jan Kiszka wrote:
Am 04.11.2010 00:56, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:44, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:18, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:11, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am
Jan Kiszka wrote:
Am 28.10.2010 11:34, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 28.10.2010 09:34, Anders Blomdell wrote:
Anders Blomdell wrote:
Anders Blomdell wrote:
Hi,
I'm trying to use rt_eepro100, for sending raw ethernet packets,
but I'm
experincing occasionally weird behaviour.
Am 29.10.2010 19:42, Anders Blomdell wrote:
Jan Kiszka wrote:
Please provide the full kernel log, ideally also with the I-pipe tracer
(with panic tracing) enabled.
Will reconfigure/recompile and do that, with full kernel log do you
mean all
bootup info?
That's best to avoid missing some
On 2010-10-29 20.06, Jan Kiszka wrote:
Am 29.10.2010 19:42, Anders Blomdell wrote:
Jan Kiszka wrote:
Please provide the full kernel log, ideally also with the I-pipe tracer
(with panic tracing) enabled.
Will reconfigure/recompile and do that, with full kernel log do you
mean all
bootup
Jan Kiszka wrote:
Am 28.10.2010 11:34, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 28.10.2010 09:34, Anders Blomdell wrote:
Anders Blomdell wrote:
Anders Blomdell wrote:
Hi,
I'm trying to use rt_eepro100, for sending raw ethernet packets,
but I'm
experincing occasionally weird behaviour.
Am 28.10.2010 17:05, Anders Blomdell wrote:
Current results:
1. 2.6.35.7, maxcpus=1; a few thousand rounds, freeze and this after
some time:
BUG: spinlock lockup on CPU#0, raw_test/2924, c0a1b540
Process raw_test (pid: 2924, ti=f18bc000 task=f1bdab00 task.ti=f18bc000)
I-pipe domain
Am 28.10.2010 17:18, Anders Blomdell wrote:
On 2010-10-28 17.09, Jan Kiszka wrote:
Am 28.10.2010 17:05, Anders Blomdell wrote:
Current results:
1. 2.6.35.7, maxcpus=1; a few thousand rounds, freeze and this after
some time:
BUG: spinlock lockup on CPU#0, raw_test/2924, c0a1b540
Process
76 matches
Mail list logo
