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