Re: [Xenomai-core] Potential problem with rt_eepro100

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

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.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux