[Adeos-main] User space, level triggered interrupt

[Adeos-main] User space, level triggered interrupt

[Reynolds, Terry AMRDEC/SimTech]

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

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
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.
 
My questions are:  how are multiple interrupt pending counts being
generated during a real time task that doesn't yield?  How is it
possible to service several pending interrupts if the pending count gets
cleared every time you check for an interrupt?
 
 
Thanks,
 
 

Terry Reynolds

Simulation Technologies, INC.

 

When trouble arises and things look bad, there is always 

one individual who perceives a solution and is willing to 

take command.  Very often, that individual is crazy.

                                                            Dave Barry

 

[-- Attachment #2: Type: text/html, Size: 4854 bytes --]

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

[Jan Kiszka]

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

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 --]