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
27 matches
Mail list logo
