Steven Seeger wrote: >> Send those backtraces, please, and a disassembly of your running > kernel >> privately to me. > > I don't have the backtraces because they'd occur and the system would > freeze. I wasn't using serial console because my application uses both > serial ports. I even noticed ipipe_ calls and 16554_ serial calls in the > same backtrace. > > Next time one occurs, I will be sure to post it. >
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. >> Sorry, I just don't understand where the problem is, or maybe I did > not >> understand what you are exactly doing/expecting here. > > I wanted to be warned if my main state thread ever went to secondary > domain, so I used T_WARNSW. However, I posted this condition wrong. The > SIGXCPU is caused by my calling assert() because my state thread had an > overrun, which it should not have. The system is doing nothing at this > point, but calling pthread_create() in a shadowed thread causes an > overrun. The shadowed thread is priority 1, and the state thread is > priority 50. The state thread runs at 100Hz so this should not be too > bad on the system. > 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). >> If you actually take faults on behalf of the tick timer handler, then > no >> wonder why the CPU figures explode. > > I don't understand what you mean here? > 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. >> Older versions, or older kernels? > > Xenomai 2.2 era. I think I used 2.6.18 or something. It was a long time > ago. > Steven > > -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
