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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
