> It turns out my problem was caused by an interrupt storm. I > had set up the interrupt to propagate to the Linux domain. > When my rt task transferred to the Linux domain from the page > fault it wasn't able to clear the device interrupt flag. The > interrupt was reenabled at the PIC level after Linux was done > with it, and as soon as that happened it got interrupted again. > > My fix was to disable the interrupt at the device level as > soon as rt_intr_wait returns, and reenable it before calling > rt_intr_wait. I'm still not sure why I was getting that exception.
I'm still getting exceptions like I was getting before. With the interrupt fix I had in there, the system stays responsive, just that task gets killed. I'm still trying to track down the problem. I'm using rt_intr_wait so I am synchronized with an external FPGA, but it is just periodic. If I replace the rt_intr_wait with a timed wait with rt_wait_period it does not crash. There seems to be some interaction with the rt_intr_wait I still do not understand. I'm trying to make sense of the exception numbers it prints in messages like the following. Maybe this will give me some better insight to what is happening. [ 24.480199] Xenomai: Switching dsp_task to secondary mode after exception #1792 in kernel-space at 0xc0062f48 (pid 595) I tried turning on the I-pipe tracer to get some more information, but it crashes on startup. _______________________________________________ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
