From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <488F98B0.1040202@domain.hid> Date: Wed, 30 Jul 2008 00:24:48 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <487E1BE8.1000306@domain.hid> <488DD994.8020501@domain.hid> <488F2749.9010605@domain.hid> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-core] Error propagating ISR to Linux domain List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ulrich Schwab Cc: xenomai-core Ulrich Schwab wrote: > On Tue, Jul 29, 2008 at 4:20 PM, Gilles Chanteperdrix > wrote: >> Gilles Chanteperdrix wrote: >>> Ulrich Schwab wrote: >>>> why not checking for irq origin like this: >>>> int my_isr_handler (xnintr_t *irq) >>>> { >>>> if ( ! test_my_card_for_irq_origin ) >>>> return XN_ISR_NONE | XN_ISR_PROPAGATE; >>>> ... /* handling */ >>>> return XN_ISR_HANDLED; >>>> } >>>> >>>> this way XN_ISR_PROPAGATE is never returned in the not-shared case. >>> I think this idea needs an answer; the answer is no: it will not work. >>> Because the IRQ will remain masked until Linux handles it, which >>> basically means that the RT irq will wait for non-RT activity, you loose >>> real-time response. >> It will not work, but not for the reason I mention: Adeos WILL re-enable >> the IRQ at interrupt controller level after the end of this handler, >> however, since the interrupt was not cleared on the peripheral side, the >> peripheral will reassert the interrupt when the interrupt is unmasked at >> interrupt controller level, so the CPU will enter an infinite loop >> invoking the ISR. >> >> -- >> Gilles. >> > Are You sure? > IIRC the infinte loop You describe occurs when XN_ISR_PROPAGATE is > removed from the code above. Yes, I am sure, the only solution that works is the one I posted. -- Gilles.