> At least the topmost four/five lines would help. You will find > __ipipe_handle_irq within the call frame each time an interrupt is > taken, so you need to focus on which handler gets actually called. In > the case above, it seems a serial interrupt is involved, and what its > handler does might be the root of the issue.
I'll run these tests tonight for you and post the results. > Creating threads should be kept out of real-time duties, it's just > unsafe in terms of latency (Btw, I hope you do reduce the default glibc > stacksize from 8Mb to something more sensible in a real-time application > context, given that mlockall is in effect). I understand this, and this is something I always follow. However, this is a linux only pthread not being created in a realtime context. The only reason the thread is shadowed is so it can call a few things occasionally to lock an RT_MUTEX. None of these mutexes are held at this time, and the thread might as well be in secondary mode. (and probably is.) > ipipe_handle_irq will be present in every call frame on behalf of an > external or virtual interrupt context, therefore if you get a fault in > the interrupt handler like you reported lately, the time spent in the > fault recovery code will be charged to the interrupt context. Thanks for the explanation. I'll be sure to gather some of these tonight. I sent you the only one I have privately with the kernel. Steven _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
