Hi,
Gilles Chanteperdrix wrote:
Enable the I-pipe tracer, recompile your kernel, set
/proc/ipipe/trace/back_trace_points to a larger value, and run latency
with the -f flag. Show us the contents of /proc/ipipe/trace/frozen, and
we may be able to give you an answer.
For more details on the I-pipe tracer, see:
http://www.xenomai.org/index.php/I-pipe:Tracer
Attached find the traces. The first one , frozentrace.txt is without
my application running.
The frozentraceApptxt with my app running and frozentrace_rtcanrecv
with the node alive but only read by rtcanrecv.
frozentraceApp.txt:
:|func -217! rtcan_sja_interrupt (xnintr_irq_handler)
:|func -96 rtcan_rcv (rtcan_sja_interrupt)
and frozentrace_rtcanrecv.txt:
:|func -164! rtcan_sja_interrupt (xnintr_irq_handler)
:|func -39 rtcan_rcv (rtcan_sja_interrupt)
look very consistent: the call to rtcan_sja_interrupt eats more than
100 us.
What does this mean? This is as good as it gets? That is a problem. I
have a couple of thousand euros of new hardware betting on xenomai/rtcan
being real-time enough to do some serious feedback control of machinery.
Must I put that up for sale now? I'll start writing my resignation
letter......:(
But more seriously rtcan_sja_interrupt I presume is a routine (interrupt
handler?) by the sound of things related to the sja chip. Is the
conclusion that something is wrong in rtcan_sja? Surely timing
inconsistencies of 200 micro seconds cannot be design?
I will not be able to work on this tomorrow. So if I make less noise on
the list its only because I am on a plane not because I have lost
interest. :)
Regards,
Roland
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
