[Xenomai-core] Cannot end interrupt from user space: add rt_intr_end call ?

[Xenomai-core] Cannot end interrupt from user space: add rt_intr_end call ?

[Tomas Kalibera]

Hi,

I think that when I handle interrupts from user space, I cannot 
correctly use I_NOAUTOENA. The thing is that this flag in fact means "do 
not call automatically xnarch_end_irq". The xnarch_end_irq call usually 
maps to unmasking the interrupt, but not always - depending on interrupt 
type (sometimes in eoi, sometimes is nop).

I was thinking that it would be nice if I could call something like 
"xnarch_end_irq" (i.e. rt_intr_end) from user space, so that I could 
correctly use I_NOAUTOENA to control the flow of interrupts.

Cheers,
Tomas

Re: [Xenomai-core] Cannot end interrupt from user space: add rt_intr_end call ?

[Philippe Gerum]

[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]

Tomas Kalibera wrote:
> Hi,
> 
> I think that when I handle interrupts from user space, I cannot 
> correctly use I_NOAUTOENA. The thing is that this flag in fact means "do 
> not call automatically xnarch_end_irq". The xnarch_end_irq call usually 
> maps to unmasking the interrupt, but not always - depending on interrupt 
> type (sometimes in eoi, sometimes is nop).
> 
> I was thinking that it would be nice if I could call something like 
> "xnarch_end_irq" (i.e. rt_intr_end) from user space, so that I could 
> correctly use I_NOAUTOENA to control the flow of interrupts.
>

What would this buy you? xnarch_irq_end() would still handle the unmasking logic
depending on the interrupt type, because it knows how the interrupt was
acknowledged in the first place -- in contrast, the application does not and
should not.

xnarch_end_irq() basically calls the ->unmask() method of the interrupt chip
descriptor, which is the same as calling rt_intr_enable(). Before you do that,
you may want to try the attached patch, which makes sure that
rt_intr_enable/disable are eagerly routed to unmask/mask on x86 for post-2.6.18
kernels. That patch is expected to solve the "rt_intr_disable() not masking
IO-APIC interrupt" issue we discussed earlier.

> Cheers,
> Tomas
> 
> 
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
> 


-- 
Philippe.

[-- Attachment #2: unconditionally-apply-irq-enable-disable-requests-to-pic.patch --]
[-- Type: text/x-diff, Size: 1666 bytes --]

Index: include/asm-x86/wrappers_32.h
===================================================================
--- include/asm-x86/wrappers_32.h	(revision 3708)
+++ include/asm-x86/wrappers_32.h	(working copy)
@@ -163,8 +163,8 @@
 
 #define rthal_irq_chip_end(irq)	rthal_irq_chip_enable(irq)
 #else /* >= 2.6.19 */
-#define rthal_irq_chip_enable(irq)   ({ rthal_irq_descp(irq)->chip->enable(irq); 0; })
-#define rthal_irq_chip_disable(irq)  ({ rthal_irq_descp(irq)->chip->disable(irq); 0; })
+#define rthal_irq_chip_enable(irq)   ({ rthal_irq_descp(irq)->chip->unmask(irq); 0; })
+#define rthal_irq_chip_disable(irq)  ({ rthal_irq_descp(irq)->chip->mask(irq); 0; })
 #define rthal_irq_chip_end(irq)      ({ rthal_irq_descp(irq)->ipipe_end(irq, rthal_irq_descp(irq)); 0; })
 typedef irq_handler_t rthal_irq_host_handler_t;
 
Index: include/asm-x86/wrappers_64.h
===================================================================
--- include/asm-x86/wrappers_64.h	(revision 3708)
+++ include/asm-x86/wrappers_64.h	(working copy)
@@ -31,8 +31,8 @@
 #define rthal_irq_descp(irq)		(irq_desc + irq)
 #define rthal_irq_desc_status(irq)	(rthal_irq_descp(irq)->status)
 
-#define rthal_irq_chip_enable(irq)   ({ rthal_irq_descp(irq)->chip->enable(irq); 0; })
-#define rthal_irq_chip_disable(irq)  ({ rthal_irq_descp(irq)->chip->disable(irq); 0; })
+#define rthal_irq_chip_enable(irq)   ({ rthal_irq_descp(irq)->chip->unmask(irq); 0; })
+#define rthal_irq_chip_disable(irq)  ({ rthal_irq_descp(irq)->chip->mask(irq); 0; })
 #define rthal_irq_chip_end(irq)      ({ rthal_irq_descp(irq)->ipipe_end(irq, rthal_irq_descp(irq)); 0; })
 
 typedef irq_handler_t rthal_irq_host_handler_t;

Re: [Xenomai-core] Cannot end interrupt from user space: add rt_intr_end call ?

[Tomas Kalibera]

Hi Philippe,

thank you for the patch !

> xnarch_end_irq() basically calls the ->unmask() method of the interrupt chip
> descriptor, which is the same as calling rt_intr_enable(). Before you do that,
>   
If I read the sources correctly, for "edge" and "simple" interrupt, 
xnarch_end_irq() calls nothing, for "percpu" it calls ->eoi() . For 
"level", "fasteoi", and "demux", it calls ->unmask().

So calling rt_intr_enable from user space would not always do the same 
as xnarch_end_irq from the kernel, wouldn't it ?

Tomas



Philippe Gerum wrote:
> Tomas Kalibera wrote:
>   
>> Hi,
>>
>> I think that when I handle interrupts from user space, I cannot 
>> correctly use I_NOAUTOENA. The thing is that this flag in fact means "do 
>> not call automatically xnarch_end_irq". The xnarch_end_irq call usually 
>> maps to unmasking the interrupt, but not always - depending on interrupt 
>> type (sometimes in eoi, sometimes is nop).
>>
>> I was thinking that it would be nice if I could call something like 
>> "xnarch_end_irq" (i.e. rt_intr_end) from user space, so that I could 
>> correctly use I_NOAUTOENA to control the flow of interrupts.
>>
>>     
>
> What would this buy you? xnarch_irq_end() would still handle the unmasking logic
> depending on the interrupt type, because it knows how the interrupt was
> acknowledged in the first place -- in contrast, the application does not and
> should not.
>
> xnarch_end_irq() basically calls the ->unmask() method of the interrupt chip
> descriptor, which is the same as calling rt_intr_enable(). Before you do that,
> you may want to try the attached patch, which makes sure that
> rt_intr_enable/disable are eagerly routed to unmask/mask on x86 for post-2.6.18
> kernels. That patch is expected to solve the "rt_intr_disable() not masking
> IO-APIC interrupt" issue we discussed earlier.
>
>   
>> Cheers,
>> Tomas
>>
>>
>>
>> _______________________________________________
>> Xenomai-core mailing list
>> Xenomai-core@domain.hid
>> https://mail.gna.org/listinfo/xenomai-core
>>
>>     
>
>
>   

Re: [Xenomai-core] Cannot end interrupt from user space: add rt_intr_end call ?

[Philippe Gerum]

Tomas Kalibera wrote:
> 
> Hi Philippe,
> 
> thank you for the patch !
> 
>> xnarch_end_irq() basically calls the ->unmask() method of the
>> interrupt chip
>> descriptor, which is the same as calling rt_intr_enable(). Before you
>> do that,
>>   
> If I read the sources correctly, for "edge" and "simple" interrupt,
> xnarch_end_irq() calls nothing, for "percpu" it calls ->eoi() . For
> "level", "fasteoi", and "demux", it calls ->unmask().
> 
> So calling rt_intr_enable from user space would not always do the same
> as xnarch_end_irq from the kernel, wouldn't it ?
>

No it would not, and this is what we want. The patch makes sure that calling
rt_intr_enable/disable() will actually unmask/mask the interrupt at PIC level,
regardless of how the normal ack/handle/end process works for that interrupt.

> Tomas
> 
> 
> 
> Philippe Gerum wrote:
>> Tomas Kalibera wrote:
>>  
>>> Hi,
>>>
>>> I think that when I handle interrupts from user space, I cannot
>>> correctly use I_NOAUTOENA. The thing is that this flag in fact means
>>> "do not call automatically xnarch_end_irq". The xnarch_end_irq call
>>> usually maps to unmasking the interrupt, but not always - depending
>>> on interrupt type (sometimes in eoi, sometimes is nop).
>>>
>>> I was thinking that it would be nice if I could call something like
>>> "xnarch_end_irq" (i.e. rt_intr_end) from user space, so that I could
>>> correctly use I_NOAUTOENA to control the flow of interrupts.
>>>
>>>     
>>
>> What would this buy you? xnarch_irq_end() would still handle the
>> unmasking logic
>> depending on the interrupt type, because it knows how the interrupt was
>> acknowledged in the first place -- in contrast, the application does
>> not and
>> should not.
>>
>> xnarch_end_irq() basically calls the ->unmask() method of the
>> interrupt chip
>> descriptor, which is the same as calling rt_intr_enable(). Before you
>> do that,
>> you may want to try the attached patch, which makes sure that
>> rt_intr_enable/disable are eagerly routed to unmask/mask on x86 for
>> post-2.6.18
>> kernels. That patch is expected to solve the "rt_intr_disable() not
>> masking
>> IO-APIC interrupt" issue we discussed earlier.
>>
>>  
>>> Cheers,
>>> Tomas
>>>
>>>
>>>
>>> _______________________________________________
>>> Xenomai-core mailing list
>>> Xenomai-core@domain.hid
>>> https://mail.gna.org/listinfo/xenomai-core
>>>
>>>     
>>
>>
>>   
> 
> 


-- 
Philippe.

Re: [Xenomai-core] Cannot end interrupt from user space: add rt_intr_end call ?

[Tomas Kalibera]

>> So calling rt_intr_enable from user space would not always do the same
>> as xnarch_end_irq from the kernel, wouldn't it ?
>>     
>
> No it would not, and this is what we want. The patch makes sure that calling
> rt_intr_enable/disable() will actually unmask/mask the interrupt at PIC level,
> regardless of how the normal ack/handle/end process works for that interrupt.
>
>   
OK, and this is the problem why I started calling for rt_intr_end. In 
order to use I_NOAUTOENA from user space correctly, I need to be able to 
end the interrupt correctly from user space. And there is no function to 
do this.

Tomas


>> Tomas
>>
>>
>>
>> Philippe Gerum wrote:
>>     
>>> Tomas Kalibera wrote:
>>>  
>>>       
>>>> Hi,
>>>>
>>>> I think that when I handle interrupts from user space, I cannot
>>>> correctly use I_NOAUTOENA. The thing is that this flag in fact means
>>>> "do not call automatically xnarch_end_irq". The xnarch_end_irq call
>>>> usually maps to unmasking the interrupt, but not always - depending
>>>> on interrupt type (sometimes in eoi, sometimes is nop).
>>>>
>>>> I was thinking that it would be nice if I could call something like
>>>> "xnarch_end_irq" (i.e. rt_intr_end) from user space, so that I could
>>>> correctly use I_NOAUTOENA to control the flow of interrupts.
>>>>
>>>>     
>>>>         
>>> What would this buy you? xnarch_irq_end() would still handle the
>>> unmasking logic
>>> depending on the interrupt type, because it knows how the interrupt was
>>> acknowledged in the first place -- in contrast, the application does
>>> not and
>>> should not.
>>>
>>> xnarch_end_irq() basically calls the ->unmask() method of the
>>> interrupt chip
>>> descriptor, which is the same as calling rt_intr_enable(). Before you
>>> do that,
>>> you may want to try the attached patch, which makes sure that
>>> rt_intr_enable/disable are eagerly routed to unmask/mask on x86 for
>>> post-2.6.18
>>> kernels. That patch is expected to solve the "rt_intr_disable() not
>>> masking
>>> IO-APIC interrupt" issue we discussed earlier.
>>>
>>>  
>>>       
>>>> Cheers,
>>>> Tomas
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Xenomai-core mailing list
>>>> Xenomai-core@domain.hid
>>>> https://mail.gna.org/listinfo/xenomai-core
>>>>
>>>>     
>>>>         
>>>   
>>>       
>>     
>
>
>   

Re: [Xenomai-core] Cannot end interrupt from user space: add rt_intr_end call ?

[Philippe Gerum]

Tomas Kalibera wrote:
> 
>>> So calling rt_intr_enable from user space would not always do the same
>>> as xnarch_end_irq from the kernel, wouldn't it ?
>>>     
>>
>> No it would not, and this is what we want. The patch makes sure that
>> calling
>> rt_intr_enable/disable() will actually unmask/mask the interrupt at
>> PIC level,
>> regardless of how the normal ack/handle/end process works for that
>> interrupt.
>>
>>   
> OK, and this is the problem why I started calling for rt_intr_end. In
> order to use I_NOAUTOENA from user space correctly, I need to be able to
> end the interrupt correctly from user space. And there is no function to
> do this.
>

Call rt_intr_enable(), with the patch applied. This will work.

> Tomas
> 
> 
>>> Tomas
>>>
>>>
>>>
>>> Philippe Gerum wrote:
>>>    
>>>> Tomas Kalibera wrote:
>>>>  
>>>>      
>>>>> Hi,
>>>>>
>>>>> I think that when I handle interrupts from user space, I cannot
>>>>> correctly use I_NOAUTOENA. The thing is that this flag in fact means
>>>>> "do not call automatically xnarch_end_irq". The xnarch_end_irq call
>>>>> usually maps to unmasking the interrupt, but not always - depending
>>>>> on interrupt type (sometimes in eoi, sometimes is nop).
>>>>>
>>>>> I was thinking that it would be nice if I could call something like
>>>>> "xnarch_end_irq" (i.e. rt_intr_end) from user space, so that I could
>>>>> correctly use I_NOAUTOENA to control the flow of interrupts.
>>>>>
>>>>>             
>>>> What would this buy you? xnarch_irq_end() would still handle the
>>>> unmasking logic
>>>> depending on the interrupt type, because it knows how the interrupt was
>>>> acknowledged in the first place -- in contrast, the application does
>>>> not and
>>>> should not.
>>>>
>>>> xnarch_end_irq() basically calls the ->unmask() method of the
>>>> interrupt chip
>>>> descriptor, which is the same as calling rt_intr_enable(). Before you
>>>> do that,
>>>> you may want to try the attached patch, which makes sure that
>>>> rt_intr_enable/disable are eagerly routed to unmask/mask on x86 for
>>>> post-2.6.18
>>>> kernels. That patch is expected to solve the "rt_intr_disable() not
>>>> masking
>>>> IO-APIC interrupt" issue we discussed earlier.
>>>>
>>>>  
>>>>      
>>>>> Cheers,
>>>>> Tomas
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Xenomai-core mailing list
>>>>> Xenomai-core@domain.hid
>>>>> https://mail.gna.org/listinfo/xenomai-core
>>>>>
>>>>>             
>>>>         
>>>     
>>
>>
>>   
> 
> 


-- 
Philippe.