On 03/28/2012 08:23 PM, Makarand Pradhan wrote:
Hi Philippe,
On 28/03/12 12:17 PM, Philippe Gerum wrote:
The log says your code wants to control when the IRQ is enabled again,
by calling rt_intr_enable() from userland. I guess you are setting
I_NOAUTOENA too. Correct?
That is correct. I_NOAUTOENA is used in rt_intr_create. Otherwise the
level trigerred interrupt will not allow the userland processing of the
int. The userland handler is very small and it unconditionally
rt_intr_enables the intr.
Testing indicates that the interrupt is always enabled from user space
within 250 usec after kernel gets the interrupt.
I have noted that unless I see "#end 0x0000002b" and a hit to the
ipic_unmask_irq, the next interrupt is not processed.
And this is getting delayed once in a while which causes a delay in
processing the next interrupt.
So the sequence of events leading to the problem is:
1. Get interrupt: #begin 0x0000002b noted in ipipe trace
2. Intr enabled from user space. Always happens roughly within 250usec.
3. #end 0x0000002b noted in ipipe trace where the int is unmasked by ipipe.
When I see the problem, step 3 is delayed. I am trying to capture a
trace where the begin, int enable and end are captured.
Your thoughts on what might cause this delay would be appreciated.
Which IRQ are you re-enabling from user-space, the multiplexed IRQ 33,
or the cascaded one you receive?
Rgds,
Mak.
--
Philippe.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
