Jeroen Van den Keybus wrote:
It's definitely an Adeos issue and msi.c needs fixing. What about
this patch, do
things improve with it (against 2.6.15-ipipe-1.2-00)?
I going to try the patch later on. I have currently a ´fully
instrumented´ kernel against which this patch would not ever work... I´m
keeping that kernel for now, because I´m also investigating why MSI also
doesn´t work under RTDM. It´s merely a coincidence that the above bug
(MSI interrupts from Linux devices getting blocked) emerged and produced
exactly the same behaviour (system hanging).
But, normally, that path is not used in RT mode, is it ? So something
else is getting in the way.
At the first look of it, I´m a bit wary of touching that msi.c . I was
rather thinking of kicking out __ack_APIC() altogether ? Or is that not
possible ? (I see only problems in p4.c and smp.c - but I haven´t looked
at these very closely.)
We do need __ack_APIC_irq() to run the actual APIC ack code all over the place in
the APIC/IO-APIC support code, so that former regular uses of ack_APIC_irq() can
be left untouched. Adeos already changes significant areas within Linux's innards
in order to control its interrupt sub-system anyway, which in turn hides the gory
details of interrupt prioritization to client software like Xenomai.
drivers/pci/msi.c simply brings a new set of interrupt controllers we need to make
Adeos-aware, just like it has been done for the i8259, the LAPIC and the IO-APIC
supports.
--
Philippe.
