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.



Reply via email to