[Xenomai-help] Problem with interrupt enabling

[Xenomai-help] Problem with interrupt enabling

[Johan Borkhuis]

Hello,

I am trying to create an RTDM interrupt handler for an external 
interrupt. I use a rtdm_irq_request, followed by a rtdm_irq_enable. This 
caused one interrupt to be processed, but subsequent interrupts were not 
processed.
After adding an extra rtdm_irq_enable to the ISR the interrupts are 
processed. When I look at the other drivers I don't see this. Is this 
needed, or is there a bug/feature in the interrupt handling on my platform?
(I use a MVME3100 with a ppc8540 processor and openPIC interrupt 
controller).

Kind regards,
    Johan Borkhuis

Re: [Xenomai-help] Problem with interrupt enabling

[Jan Kiszka]

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

Johan Borkhuis wrote:
> Hello,
> 
> I am trying to create an RTDM interrupt handler for an external 
> interrupt. I use a rtdm_irq_request, followed by a rtdm_irq_enable. This 

The rtdm_irq_enable is no longer required with RTDM revision 6 and
higher. But that's trunk, it's rev. 5 which still comes with Xenomai
2.3.x. And the enable will also cause no harm with rev. 6.

> caused one interrupt to be processed, but subsequent interrupts were not 
> processed.
> After adding an extra rtdm_irq_enable to the ISR the interrupts are 
> processed. When I look at the other drivers I don't see this. Is this 
> needed, or is there a bug/feature in the interrupt handling on my platform?
> (I use a MVME3100 with a ppc8540 processor and openPIC interrupt 
> controller).

What do you return with your IRQ handler? RTDM_IRQ_HANDLED?

That explicit rtdm_irq_enable is not required by design, would rather be
a bug on certain platforms (where enable != end IRQ), and indicates that
something else is broken, maybe in Xenomai.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Problem with interrupt enabling

[Johan Borkhuis]

Jan Kiszka wrote:
> Johan Borkhuis wrote:
>   
>> Hello,
>>
>> I am trying to create an RTDM interrupt handler for an external 
>> interrupt. I use a rtdm_irq_request, followed by a rtdm_irq_enable. This 
>>     
>
> The rtdm_irq_enable is no longer required with RTDM revision 6 and
> higher. But that's trunk, it's rev. 5 which still comes with Xenomai
> 2.3.x. And the enable will also cause no harm with rev. 6.
>   

I did see some references to the fact that it is no longer needed in the 
future. I am running 2.3.1, so for the moment I will leave it in.

>> caused one interrupt to be processed, but subsequent interrupts were not 
>> processed.
>> After adding an extra rtdm_irq_enable to the ISR the interrupts are 
>> processed. When I look at the other drivers I don't see this. Is this 
>> needed, or is there a bug/feature in the interrupt handling on my platform?
>> (I use a MVME3100 with a ppc8540 processor and openPIC interrupt 
>> controller).
>>     
>
> What do you return with your IRQ handler? RTDM_IRQ_HANDLED?
>   
Yes, I do return RTDM_IRQ_HANDLED.

> That explicit rtdm_irq_enable is not required by design, would rather be
> a bug on certain platforms (where enable != end IRQ), and indicates that
> something else is broken, maybe in Xenomai.
>   

This driver is ported from a standard Linux driver, and in this driver 
an extra call is also not needed.

Kind regards,
    Johan Borkhuis

Re: [Xenomai-help] Problem with interrupt enabling

[Jan Kiszka]

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

Johan Borkhuis wrote:
> Jan Kiszka wrote:
>> Johan Borkhuis wrote:
>>  
>>> Hello,
>>>
>>> I am trying to create an RTDM interrupt handler for an external
>>> interrupt. I use a rtdm_irq_request, followed by a rtdm_irq_enable.
>>> This     
>>
>> The rtdm_irq_enable is no longer required with RTDM revision 6 and
>> higher. But that's trunk, it's rev. 5 which still comes with Xenomai
>> 2.3.x. And the enable will also cause no harm with rev. 6.
>>   
> 
> I did see some references to the fact that it is no longer needed in the
> future. I am running 2.3.1, so for the moment I will leave it in.
> 
>>> caused one interrupt to be processed, but subsequent interrupts were
>>> not processed.
>>> After adding an extra rtdm_irq_enable to the ISR the interrupts are
>>> processed. When I look at the other drivers I don't see this. Is this
>>> needed, or is there a bug/feature in the interrupt handling on my
>>> platform?
>>> (I use a MVME3100 with a ppc8540 processor and openPIC interrupt
>>> controller).
>>>     
>>
>> What do you return with your IRQ handler? RTDM_IRQ_HANDLED?
>>   
> Yes, I do return RTDM_IRQ_HANDLED.

OK, then your code should be fine. Which I-pipe patch are you using?

> 
>> That explicit rtdm_irq_enable is not required by design, would rather be
>> a bug on certain platforms (where enable != end IRQ), and indicates that
>> something else is broken, maybe in Xenomai.
>>   
> 
> This driver is ported from a standard Linux driver, and in this driver
> an extra call is also not needed.

Yep. Sounds like a BUG in I-pipe for me (PPC over Xenomai in general is
known to be fine). Wolfgang, Philippe, any ideas if/why we might lack
proper IRQ ending here?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Problem with interrupt enabling

[Johan Borkhuis]

Jan Kiszka wrote:
> OK, then your code should be fine. Which I-pipe patch are you using?
>   
bash-3.00# cat /proc/ipipe/version
1.5-01
bash-3.00# uname -a
Linux MVME3100 2.6.14.Xenomai #51 Fri May 25 11:36:18 CEST 2007 ppc ppc 
ppc GNU/Linux

>> This driver is ported from a standard Linux driver, and in this driver
>> an extra call is also not needed.
>>     
>
> Yep. Sounds like a BUG in I-pipe for me (PPC over Xenomai in general is
> known to be fine). Wolfgang, Philippe, any ideas if/why we might lack
> proper IRQ ending here?
>
> Jan
>   

Kind regard,
    Johan Borkhuis

Re: [Xenomai-help] Problem with interrupt enabling

[Philippe Gerum]

On Fri, 2007-05-25 at 13:16 +0200, Jan Kiszka wrote:
> Johan Borkhuis wrote:
> > Hello,
> > 
> > I am trying to create an RTDM interrupt handler for an external 
> > interrupt. I use a rtdm_irq_request, followed by a rtdm_irq_enable. This 
> 
> The rtdm_irq_enable is no longer required with RTDM revision 6 and
> higher. But that's trunk, it's rev. 5 which still comes with Xenomai
> 2.3.x. And the enable will also cause no harm with rev. 6.
> 
> > caused one interrupt to be processed, but subsequent interrupts were not 
> > processed.
> > After adding an extra rtdm_irq_enable to the ISR the interrupts are 
> > processed. When I look at the other drivers I don't see this. Is this 
> > needed, or is there a bug/feature in the interrupt handling on my platform?
> > (I use a MVME3100 with a ppc8540 processor and openPIC interrupt 
> > controller).
> 
> What do you return with your IRQ handler? RTDM_IRQ_HANDLED?
> 
> That explicit rtdm_irq_enable is not required by design, would rather be
> a bug on certain platforms (where enable != end IRQ), and indicates that
> something else is broken, maybe in Xenomai.
> 

Xenomai is not involved at this level, it's the I-pipe business here. As
a matter of fact, the current I-pipe/ppc implementation forces the slow
ack path, i.e. disables the source and send EOI in the openpic code,
because we don't want another IRQ from the same source before some stage
has processed the current one. This is due to the deferred-by-design
nature of IRQ handling introduced by the interrupt pipeline, which has
raised some issues (namely interrupt storm) for level-triggered IRQs on
some ppc hw, IIRC.

Calling enable/end is thus needed to reactivate the IRQ source at some
point, even if it's not required by any vanilla kernel configuration
which may instead use the fast ack mode (i.e. send EOI only for
level-triggered interrupts, no masking).

Next powerpc patches should not require this, thanks to the genirq layer
which helps differentiating interrupt flows in a much simpler way.

> Jan
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] Problem with interrupt enabling

[Jan Kiszka]

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

Philippe Gerum wrote:
> On Fri, 2007-05-25 at 13:16 +0200, Jan Kiszka wrote:
>> Johan Borkhuis wrote:
>>> Hello,
>>>
>>> I am trying to create an RTDM interrupt handler for an external 
>>> interrupt. I use a rtdm_irq_request, followed by a rtdm_irq_enable. This 
>> The rtdm_irq_enable is no longer required with RTDM revision 6 and
>> higher. But that's trunk, it's rev. 5 which still comes with Xenomai
>> 2.3.x. And the enable will also cause no harm with rev. 6.
>>
>>> caused one interrupt to be processed, but subsequent interrupts were not 
>>> processed.
>>> After adding an extra rtdm_irq_enable to the ISR the interrupts are 
>>> processed. When I look at the other drivers I don't see this. Is this 
>>> needed, or is there a bug/feature in the interrupt handling on my platform?
>>> (I use a MVME3100 with a ppc8540 processor and openPIC interrupt 
>>> controller).
>> What do you return with your IRQ handler? RTDM_IRQ_HANDLED?
>>
>> That explicit rtdm_irq_enable is not required by design, would rather be
>> a bug on certain platforms (where enable != end IRQ), and indicates that
>> something else is broken, maybe in Xenomai.
>>
> 
> Xenomai is not involved at this level, it's the I-pipe business here. As

I would be careful with this judgement when reading further on...

> a matter of fact, the current I-pipe/ppc implementation forces the slow
> ack path, i.e. disables the source and send EOI in the openpic code,
> because we don't want another IRQ from the same source before some stage
> has processed the current one. This is due to the deferred-by-design
> nature of IRQ handling introduced by the interrupt pipeline, which has
> raised some issues (namely interrupt storm) for level-triggered IRQs on
> some ppc hw, IIRC.
> 
> Calling enable/end is thus needed to reactivate the IRQ source at some
> point, even if it's not required by any vanilla kernel configuration
> which may instead use the fast ack mode (i.e. send EOI only for
> level-triggered interrupts, no masking).

The RTDM API just like the nucleus interrupt layer is precisely about
removing this need from the driver/application developer. Thus, if you
say we need ending here because I-pipe can't help on this arch, we would
see a clear Xenomai bug.

> 
> Next powerpc patches should not require this, thanks to the genirq layer
> which helps differentiating interrupt flows in a much simpler way.
> 

But until then we need a fix. Can we patch rthal_irq_end() on PPC to
address this depending on the I-pipe version?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Problem with interrupt enabling

[Philippe Gerum]

On Fri, 2007-05-25 at 14:00 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Fri, 2007-05-25 at 13:16 +0200, Jan Kiszka wrote:
> >> Johan Borkhuis wrote:
> >>> Hello,
> >>>
> >>> I am trying to create an RTDM interrupt handler for an external 
> >>> interrupt. I use a rtdm_irq_request, followed by a rtdm_irq_enable. This 
> >> The rtdm_irq_enable is no longer required with RTDM revision 6 and
> >> higher. But that's trunk, it's rev. 5 which still comes with Xenomai
> >> 2.3.x. And the enable will also cause no harm with rev. 6.
> >>
> >>> caused one interrupt to be processed, but subsequent interrupts were not 
> >>> processed.
> >>> After adding an extra rtdm_irq_enable to the ISR the interrupts are 
> >>> processed. When I look at the other drivers I don't see this. Is this 
> >>> needed, or is there a bug/feature in the interrupt handling on my platform?
> >>> (I use a MVME3100 with a ppc8540 processor and openPIC interrupt 
> >>> controller).
> >> What do you return with your IRQ handler? RTDM_IRQ_HANDLED?
> >>
> >> That explicit rtdm_irq_enable is not required by design, would rather be
> >> a bug on certain platforms (where enable != end IRQ), and indicates that
> >> something else is broken, maybe in Xenomai.
> >>
> > 
> > Xenomai is not involved at this level, it's the I-pipe business here. As
> 
> I would be careful with this judgement when reading further on...
> 
> > a matter of fact, the current I-pipe/ppc implementation forces the slow
> > ack path, i.e. disables the source and send EOI in the openpic code,
> > because we don't want another IRQ from the same source before some stage
> > has processed the current one. This is due to the deferred-by-design
> > nature of IRQ handling introduced by the interrupt pipeline, which has
> > raised some issues (namely interrupt storm) for level-triggered IRQs on
> > some ppc hw, IIRC.
> > 
> > Calling enable/end is thus needed to reactivate the IRQ source at some
> > point, even if it's not required by any vanilla kernel configuration
> > which may instead use the fast ack mode (i.e. send EOI only for
> > level-triggered interrupts, no masking).
> 
> The RTDM API just like the nucleus interrupt layer is precisely about
> removing this need from the driver/application developer. Thus, if you
> say we need ending here because I-pipe can't help on this arch, we would
> see a clear Xenomai bug.

If you reread my post in the intended context, you should understand it
as "the I-pipe is the only one responsible for handling the incoming
interrupts", and the all time approach has been to mask them until they
get processed (save the special exception if IRQ0 on x86 due to ISA bus
sluggishness). In that context, it's a I-pipe issue (the masking), not a
Xenomai one.

Said differently, Xenomai has always assumed that the I-pipe did mask
the incoming IRQ source while processing it, leaving the decision to
unmask it to the driver's ISR, depending on its return value to the
primary ISR handler in the nucleus.

> 
> > 
> > Next powerpc patches should not require this, thanks to the genirq layer
> > which helps differentiating interrupt flows in a much simpler way.
> > 
> 
> But until then we need a fix. Can we patch rthal_irq_end() on PPC to
> address this depending on the I-pipe version?
> 

Looking at the code from rthal_irq_end() in v2.3.1, the presence of a
->end() handler would indeed cause it to be invoked first (before
attempting ->enable() as a fallback option), which would end up in
openpic_end_irq() from arch/ppc/syslib/open_pic.c. What I suspect now is
that no regular action handler has been defined for this IRQ (i.e. no
request_irq() on this source from the Linux world), and therefore this
code would lead to a nop.

In which case, it would be an I-pipe bug, since there is no reason to
prevent the real-time domain from using an IRQ Linux does not care of.

> Jan
> 
-- 
Philippe.

Re: [Xenomai-help] Problem with interrupt enabling

[Jan Kiszka]

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

Philippe Gerum wrote:
> On Fri, 2007-05-25 at 14:00 +0200, Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> On Fri, 2007-05-25 at 13:16 +0200, Jan Kiszka wrote:
>>>> Johan Borkhuis wrote:
>>>>> Hello,
>>>>>
>>>>> I am trying to create an RTDM interrupt handler for an external 
>>>>> interrupt. I use a rtdm_irq_request, followed by a rtdm_irq_enable. This 
>>>> The rtdm_irq_enable is no longer required with RTDM revision 6 and
>>>> higher. But that's trunk, it's rev. 5 which still comes with Xenomai
>>>> 2.3.x. And the enable will also cause no harm with rev. 6.
>>>>
>>>>> caused one interrupt to be processed, but subsequent interrupts were not 
>>>>> processed.
>>>>> After adding an extra rtdm_irq_enable to the ISR the interrupts are 
>>>>> processed. When I look at the other drivers I don't see this. Is this 
>>>>> needed, or is there a bug/feature in the interrupt handling on my platform?
>>>>> (I use a MVME3100 with a ppc8540 processor and openPIC interrupt 
>>>>> controller).
>>>> What do you return with your IRQ handler? RTDM_IRQ_HANDLED?
>>>>
>>>> That explicit rtdm_irq_enable is not required by design, would rather be
>>>> a bug on certain platforms (where enable != end IRQ), and indicates that
>>>> something else is broken, maybe in Xenomai.
>>>>
>>> Xenomai is not involved at this level, it's the I-pipe business here. As
>> I would be careful with this judgement when reading further on...
>>
>>> a matter of fact, the current I-pipe/ppc implementation forces the slow
>>> ack path, i.e. disables the source and send EOI in the openpic code,
>>> because we don't want another IRQ from the same source before some stage
>>> has processed the current one. This is due to the deferred-by-design
>>> nature of IRQ handling introduced by the interrupt pipeline, which has
>>> raised some issues (namely interrupt storm) for level-triggered IRQs on
>>> some ppc hw, IIRC.
>>>
>>> Calling enable/end is thus needed to reactivate the IRQ source at some
>>> point, even if it's not required by any vanilla kernel configuration
>>> which may instead use the fast ack mode (i.e. send EOI only for
>>> level-triggered interrupts, no masking).
>> The RTDM API just like the nucleus interrupt layer is precisely about
>> removing this need from the driver/application developer. Thus, if you
>> say we need ending here because I-pipe can't help on this arch, we would
>> see a clear Xenomai bug.
> 
> If you reread my post in the intended context, you should understand it
> as "the I-pipe is the only one responsible for handling the incoming
> interrupts", and the all time approach has been to mask them until they
> get processed (save the special exception if IRQ0 on x86 due to ISA bus
> sluggishness). In that context, it's a I-pipe issue (the masking), not a
> Xenomai one.
> 
> Said differently, Xenomai has always assumed that the I-pipe did mask
> the incoming IRQ source while processing it, leaving the decision to
> unmask it to the driver's ISR, depending on its return value to the
> primary ISR handler in the nucleus.
> 
>>> Next powerpc patches should not require this, thanks to the genirq layer
>>> which helps differentiating interrupt flows in a much simpler way.
>>>
>> But until then we need a fix. Can we patch rthal_irq_end() on PPC to
>> address this depending on the I-pipe version?
>>
> 
> Looking at the code from rthal_irq_end() in v2.3.1, the presence of a
> ->end() handler would indeed cause it to be invoked first (before
> attempting ->enable() as a fallback option), which would end up in
> openpic_end_irq() from arch/ppc/syslib/open_pic.c. What I suspect now is
> that no regular action handler has been defined for this IRQ (i.e. no
> request_irq() on this source from the Linux world), and therefore this
> code would lead to a nop.
> 
> In which case, it would be an I-pipe bug, since there is no reason to
> prevent the real-time domain from using an IRQ Linux does not care of.

OK, if Xenomai or I-pipe -- we agree it's a bug, not a temporary
shortcoming. :)

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Problem with interrupt enabling

[Philippe Gerum]

On Fri, 2007-05-25 at 15:05 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Fri, 2007-05-25 at 14:00 +0200, Jan Kiszka wrote:
> >> Philippe Gerum wrote:
> >>> On Fri, 2007-05-25 at 13:16 +0200, Jan Kiszka wrote:
> >>>> Johan Borkhuis wrote:
> >>>>> Hello,
> >>>>>
> >>>>> I am trying to create an RTDM interrupt handler for an external 
> >>>>> interrupt. I use a rtdm_irq_request, followed by a rtdm_irq_enable. This 
> >>>> The rtdm_irq_enable is no longer required with RTDM revision 6 and
> >>>> higher. But that's trunk, it's rev. 5 which still comes with Xenomai
> >>>> 2.3.x. And the enable will also cause no harm with rev. 6.
> >>>>
> >>>>> caused one interrupt to be processed, but subsequent interrupts were not 
> >>>>> processed.
> >>>>> After adding an extra rtdm_irq_enable to the ISR the interrupts are 
> >>>>> processed. When I look at the other drivers I don't see this. Is this 
> >>>>> needed, or is there a bug/feature in the interrupt handling on my platform?
> >>>>> (I use a MVME3100 with a ppc8540 processor and openPIC interrupt 
> >>>>> controller).
> >>>> What do you return with your IRQ handler? RTDM_IRQ_HANDLED?
> >>>>
> >>>> That explicit rtdm_irq_enable is not required by design, would rather be
> >>>> a bug on certain platforms (where enable != end IRQ), and indicates that
> >>>> something else is broken, maybe in Xenomai.
> >>>>
> >>> Xenomai is not involved at this level, it's the I-pipe business here. As
> >> I would be careful with this judgement when reading further on...
> >>
> >>> a matter of fact, the current I-pipe/ppc implementation forces the slow
> >>> ack path, i.e. disables the source and send EOI in the openpic code,
> >>> because we don't want another IRQ from the same source before some stage
> >>> has processed the current one. This is due to the deferred-by-design
> >>> nature of IRQ handling introduced by the interrupt pipeline, which has
> >>> raised some issues (namely interrupt storm) for level-triggered IRQs on
> >>> some ppc hw, IIRC.
> >>>
> >>> Calling enable/end is thus needed to reactivate the IRQ source at some
> >>> point, even if it's not required by any vanilla kernel configuration
> >>> which may instead use the fast ack mode (i.e. send EOI only for
> >>> level-triggered interrupts, no masking).
> >> The RTDM API just like the nucleus interrupt layer is precisely about
> >> removing this need from the driver/application developer. Thus, if you
> >> say we need ending here because I-pipe can't help on this arch, we would
> >> see a clear Xenomai bug.
> > 
> > If you reread my post in the intended context, you should understand it
> > as "the I-pipe is the only one responsible for handling the incoming
> > interrupts", and the all time approach has been to mask them until they
> > get processed (save the special exception if IRQ0 on x86 due to ISA bus
> > sluggishness). In that context, it's a I-pipe issue (the masking), not a
> > Xenomai one.
> > 
> > Said differently, Xenomai has always assumed that the I-pipe did mask
> > the incoming IRQ source while processing it, leaving the decision to
> > unmask it to the driver's ISR, depending on its return value to the
> > primary ISR handler in the nucleus.
> > 
> >>> Next powerpc patches should not require this, thanks to the genirq layer
> >>> which helps differentiating interrupt flows in a much simpler way.
> >>>
> >> But until then we need a fix. Can we patch rthal_irq_end() on PPC to
> >> address this depending on the I-pipe version?
> >>
> > 
> > Looking at the code from rthal_irq_end() in v2.3.1, the presence of a
> > ->end() handler would indeed cause it to be invoked first (before
> > attempting ->enable() as a fallback option), which would end up in
> > openpic_end_irq() from arch/ppc/syslib/open_pic.c. What I suspect now is
> > that no regular action handler has been defined for this IRQ (i.e. no
> > request_irq() on this source from the Linux world), and therefore this
> > code would lead to a nop.
> > 
> > In which case, it would be an I-pipe bug, since there is no reason to
> > prevent the real-time domain from using an IRQ Linux does not care of.
> 
> OK, if Xenomai or I-pipe -- we agree it's a bug, not a temporary
> shortcoming. :)

Clearly, yes.

> 
> Jan
> 
-- 
Philippe.

Re: [Xenomai-help] Problem with interrupt enabling

[Philippe Gerum]

On Fri, 2007-05-25 at 13:04 +0200, Johan Borkhuis wrote:
> Hello,
> 
> I am trying to create an RTDM interrupt handler for an external 
> interrupt. I use a rtdm_irq_request, followed by a rtdm_irq_enable. This 
> caused one interrupt to be processed, but subsequent interrupts were not 
> processed.
> After adding an extra rtdm_irq_enable to the ISR the interrupts are 
> processed. When I look at the other drivers I don't see this. Is this 
> needed, or is there a bug/feature in the interrupt handling on my platform?
> (I use a MVME3100 with a ppc8540 processor and openPIC interrupt 
> controller).
> 

Does this help?

--- arch/ppc/syslib/open_pic.c~	2006-11-17 15:55:24.000000000 +0100
+++ arch/ppc/syslib/open_pic.c	2007-05-26 11:09:03.000000000 +0200
@@ -833,7 +833,7 @@
 {
 #if defined(__SLOW_VERSION__) || defined(CONFIG_IPIPE)
 	if (!(irq_desc[irq_nr].status & (IRQ_DISABLED|IRQ_INPROGRESS))
-	    && irq_desc[irq_nr].action)
+	    && (!ipipe_root_domain_p || irq_desc[irq_nr].action))
 		openpic_enable_irq(irq_nr);
 #else
 	if ((irq_desc[irq_nr].status & IRQ_LEVEL) != 0)

> Kind regards,
>     Johan Borkhuis
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] Problem with interrupt enabling

[Johan Borkhuis]

Philippe Gerum wrote:
> Does this help?
> --- arch/ppc/syslib/open_pic.c~	2006-11-17 15:55:24.000000000 +0100
> +++ arch/ppc/syslib/open_pic.c	2007-05-26 11:09:03.000000000 +0200
> @@ -833,7 +833,7 @@
>  {
>  #if defined(__SLOW_VERSION__) || defined(CONFIG_IPIPE)
>  	if (!(irq_desc[irq_nr].status & (IRQ_DISABLED|IRQ_INPROGRESS))
> -	    && irq_desc[irq_nr].action)
> +	    && (!ipipe_root_domain_p || irq_desc[irq_nr].action))
>  		openpic_enable_irq(irq_nr);
>  #else
>  	if ((irq_desc[irq_nr].status & IRQ_LEVEL) != 0)
>
>   
This does indeed fix the problem. Thanks!

Kind regards,
    Johan Borkhuis

Re: [Xenomai-help] Problem with interrupt enabling

[Philippe Gerum]

On Tue, 2007-05-29 at 08:24 +0200, Johan Borkhuis wrote:
> Philippe Gerum wrote:
> > Does this help?
> > --- arch/ppc/syslib/open_pic.c~	2006-11-17 15:55:24.000000000 +0100
> > +++ arch/ppc/syslib/open_pic.c	2007-05-26 11:09:03.000000000 +0200
> > @@ -833,7 +833,7 @@
> >  {
> >  #if defined(__SLOW_VERSION__) || defined(CONFIG_IPIPE)
> >  	if (!(irq_desc[irq_nr].status & (IRQ_DISABLED|IRQ_INPROGRESS))
> > -	    && irq_desc[irq_nr].action)
> > +	    && (!ipipe_root_domain_p || irq_desc[irq_nr].action))
> >  		openpic_enable_irq(irq_nr);
> >  #else
> >  	if ((irq_desc[irq_nr].status & IRQ_LEVEL) != 0)
> >
> >   
> This does indeed fix the problem. Thanks!

Ok. I've uploaded an amended patch for the legacy 2.6.14/ppc support
here:
http://download.gna.org/adeos/patches/v2.6/ppc/older/adeos-ipipe-2.6.14-ppc-1.5-03.patch

This patch will be shipped with the upcoming 2.3.2 too.

> 
> Kind regards,
>     Johan Borkhuis
> 
-- 
Philippe.