Steve Deiters wrote:
>> 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.
Could you try and reproduce this bug without the FPGA ? For instance by
requesting a virq (rthal_alloc_virq) in an RTDM driver, then posting
this virq (rthal_trigger_virq) from an RTDM timer? If you encounter the
same issue, we will be able to reproduce your issue. If not, then
chances may be that the problem comes from accessing the FPGA register
in the irq handler code.
--
Gilles.
_______________________________________________
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
