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 according
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
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 f
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 th
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
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.
>>>
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 th
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.
>>
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:
> >>> ht
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:
>
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:
http://sisyphus.hd.fr
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:
>>> 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 add
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 Chanteperd
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:
> >>
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:
>
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 clea
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 clea
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 p
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 off
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.
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
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 56f
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: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,
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
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 t
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:
47dac49c71e89
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 aft
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).
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 h
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
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
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:
>>
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 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.
>> Un
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 inhe
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
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 b
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 (n
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)
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 exa
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.
--
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 i
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:
>
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 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 wro
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 wro
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 wro
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: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
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 o
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
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 n
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). T
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 manip
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
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
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 thi
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/nucleu
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
+++
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/sc
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 int
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 xnsched_self_resched_p(
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)
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 wr
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 wr
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.1
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:
An
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 rt_eepro100
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 rt_eepro100,
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.
V
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
>>>
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
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,
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 raw_test (pid: 2924, ti=f18bc000
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 domai
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
78 matches
Mail list logo