[Xenomai-help] Re: [Adeos-main] User space, level triggered interrupt

[Xenomai-help] Re: [Adeos-main] User space, level triggered interrupt

[Jan Kiszka]

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

Reynolds, Terry AMRDEC/SimTech wrote:
> Hi,
> 
> Unfortunately I'm tied to this version of linux (2.6.10).  

Very unfortunate, indeed.

> 
> I have the PCI driver allocate the IRQ and register a handler for it, so
> I'll be able to learn the IRQ number.  I've tried not propagating the
> IRQ from Fusion, but the code never seems to proceed past the first
> interrupt.
> 
> As I understood the interrupt pipeline, if my realtime task didn't idle
> itself, then Linux didn't get a chance to do anything, include
> processing IRQ's!

Yep.

> 
> The only way I can think of for the interrupt count to increment is for
> the Linux isr to get called, and return IRQ_HANDLED, without clearing
> the actual interrupt line.  (the user app. has to clear it)

The I_AUTOENA flag tells the system to immediately re-enable the IRQ
line. Your user-space task will then be executed *after* the IRQ line
got enabled (leaving SMP systems aside here). By combining I_AUTOENA and
I_PROPAGATE you then risk to re-enable the line twice: the second time
after Linux got hold of and handled the event. Cannot say what this
means in practice for your arch though.

> 
> If I didn't have Linux return the irq_handled, how would I mark the IRQ
> as being handled from a user space application?

You could call rt_intr_enable, though this is not totally clean. Some
archs (PPC32 is one of them I think) distinguish between *enabling* and
*ending* an interrupt. We had a long discussion on this on xenomai-core,
and while the nucleus is now clean in this respect (also it's
documentation), the native (former rtai) skin still does not deal with
this issue yet. If you decide to not let the skin enable the line for
you, then calling rt_intr_enable may not always fit. But, unfortunately,
there is no rt_intr_end() even in latest Xenomai...

[Could someone help my memory with the current status of open-coded IRQ
handling in native/POSIX threads? I only know that I have some early
RTDM code hanging around somewhere, but that will become a different
usage model.]

Even worse for you, I'm not sure if Fusion 0.9 handled this
differentiation correctly at all. nucleus/intr.c only talks about
xnarch_enable_irq() on return from the handler:

http://www.rts.uni-hannover.de/xenomai/lxr/source/nucleus/intr.c?v=fusion-0.9#L365

> 
> PS.  I wasn't sure where the 'best' group to post this as it's an Fusion
> / Adeos application and not a I-Pipe version.
> 

Definitely Xenomai, I CC'ed the help list (subscription required for
postings).

Jan


> 
> Terry. 
> 
> -----Original Message-----
> From: jan.kiszka@domain.hid [mailto:jan.kiszka@domain.hid
> Sent: Thursday, June 29, 2006 1:32 PM
> To: Reynolds, Terry AMRDEC/SimTech
> Cc: adeos-main@gna.org
> Subject: Re: [Adeos-main] User space, level triggered interrupt
> 
> Reynolds, Terry AMRDEC/SimTech wrote:
>> Hi All,
>>  
>> I'm trying to understand what I'm seeing in my real-time code where I 
>> handle a PCI interrupt, using it to handshake with a program running 
>> on another computer connected via a PCI reflective memory card.  This 
>> is on a G5 ppc64 kernel.
>>  
>> When I register the driver for the PCI card, I allocate an IRQ for it,
> 
>> and install the kernel ISR which only returns IRQ_HANDLED.  I mmap the
> 
> Wait, do you share the IRQ this way between RT and non-RT? I mean is the
> Linux handler still registered when you attach to it via Fusion? What
> jobs still should be done in non-RT context? Note that this can cause
> nasty prio inversions with the RT code.
> 
>> registers on the card, as the user application has to access them to 
>> clear the PCI interrupt after the IRQ is detected.
>>  
>> My realtime application is based on Fusion 0.9, but I've looked at the
> 
>> Xenomai version of the rt_intr_wait code and don't see any
> differences.
>> The realtime code accesses the card's pci driver to read the IRQ 
>> number, and creates a user space interrupt object (passing I_PROPAGATE
> 
>> & I_AUTOENA ).  What's strange is that when I call rt_intr_wait for an
> 
>> instance where only one interrupt has fired, but several micro-seconds
> 
>> have passed prior to the wait function, the wait returns values 
>> indicating that several interrupts are pending.  Calling the wait 
>> function without allowing any spare time returns a correct 'one'
>> interrupt having fired.  Calling the wait once seems to clear the 
>> interrupt pending count.
> 
> It does [1] (also in Xenomai).
> 
>>  
>> My questions are:  how are multiple interrupt pending counts being 
>> generated during a real time task that doesn't yield?  How is it
> 
> Hard to say without knowing your code (or at least the central parts of
> it). But such problems can nicely be analysed these days with the Adeos
> I-pipe tracer. Once you detect a failure in your app, you can trigger a
> freeze and go back several thousands of kernel function calls in the
> trace history. This typically gives a nice picture of what happened and
> what should better have not happened.
> 
> It may "only" require an update of your code base. But given the
> improvements and fixes along the path from Fusion 0.9 to Xenomai 2.1
> (2.2 soon), it may be worth it. Do you depend on a specific kernel
> version that's no longer supported? Or does your project require fixed
> versions?
> 
>> possible to service several pending interrupts if the pending count 
>> gets cleared every time you check for an interrupt?
>>  
> 
> First, you get the number of occurred IRQs on return of rt_intr_wait.
> And second, a typical IRQ handler (if threaded or not) looks like this:
> 
> while (hardware_says_there_are_events) {
> 	handle_some_hardware_event;
> }
> 
> So the IRQ event itself is just a trigger to handle n >= 1 hardware
> events.
> 
> 
> I'm just scratching my head if this is an adeos-related question ;). I
> would say xenomai-core is a better place for this discussion, covering
> more the RTOS than the low-level hardware abstractions.
> 
> Jan
> 
> 
> [1]http://www.rts.uni-hannover.de/xenomai/lxr/source/skins/rtai/syscall.
> c?v=fusion-0.9#L3100
> 


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