> Please ignore my first wrong mail ;-)
> I am trying to found the bug in xenomai for PXA270 machine (xenomai 2.3.4,
> ipipe 1.7-06 and kernel 2.6.20).
> I have localised that the problem is coming when rt_task_create call
> __ipipe_restore_pipeline_head (called by xnlock_put_irq_restore) in
> I think that the problem is the call to __clear_bit(IPIPE_STALL_FLAG,
Is it the operation itself or the effect on cpudata.status? I mean, can
you safely do a __clear_bit followed by a __set_bit, which would rule
out an invalid memory access?
> If I don't execute this function on the rt_task_create the system doesn't
> freeze (but my application doesn't work correctly).
> I don't know what the problem is. Do you have an idea or a suggestion?
At least /me is lacking a full picture. So I would suggest, in order to
ease the understanding of your scenario for everyone, to
a) post your modification in form of a patch (diff -up).
b) catch the problematic execution path with the ipipe tracer - now
that it no longer fails lethally. Just put an ipipe_trace_freeze at
a point that is unique and close to the hot spot (e.g. after
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
Xenomai-core mailing list