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
_______________________________________________
Xenomai-core mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-core
