Re: [Xenomai-core] Potential problem with rt_eepro100

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2417 bytes --]

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 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)
>>>>>>>>    if (current_sched != (__sched__))    {                \
>>>>>>>>        xnarch_cpu_set(xnsched_cpu(__sched__), 
>>>>>>>> current_sched->resched);    \
>>>>>>>>        setbits((__sched__)->status, XNRESCHED);                \
>>>>>>>> +      xnarch_memory_barrier();                        \
>>>>>>>>    }                                    \
>>>>>>>>  } while (0)
>>>>>>> In progress, if nothing breaks before, I'll report status tomorrow 
>>>>>>> morning.
>>>>>> It still breaks (in approximately the same way). I'm currently putting a 
>>>>>> barrier in the other macro doing a RESCHED, also adding some tracing to 
>>>>>> see if a read barrier is needed.
>>>>> Nope, no luck there either. Will start interesting tracepoint 
>>>>> adding/conversion :-(
>>>>
>>>> Strange. But it was too easy anyway...
>>>>
>>>>> Any reason why xn_nucleus_sched_remote should ever report status = 0?
>>>>
>>>> Really don't know yet. You could trigger on this state and call
>>>> ftrace_stop() then. Provided you had the functions tracer enabled, that
>>>> should give a nice pictures of what happened before.
>>>
>>> Isn't there a race betweeen these two (still waiting for compilation to 
>>> be finished)?
>>
>> We always hold the nklock in both contexts.
>>
> 
> 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 outside of nklock
protection, we must _always_ use atomic ops.

This screams for a cleanup: local-only bits like XNHTICK or XNINIRQ
should be pushed in a separate status word that can then be safely
modified non-atomically.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]