In a search for the problem, I encountered some code which may be at the root of the problem. In file
arch/i386/kernel/io_apic.c
I see that a function mask_and_ack_level_ioapic_vector() is being defined, whereas the original 2.6.15 code did not ever issue any IO_APIC calls (both mask_and_ack_level_ioapic and end_edge_ioapic are void in include/linux/).
Is it possible that this code was transferred with patches for earlier kernels (at least from 2.6.11) ?
I'm going to check this now and hopefully fix it.
I see that a function mask_and_ack_level_ioapic_vector() is being defined, whereas the original 2.6.15 code did not ever issue any IO_APIC calls (both mask_and_ack_level_ioapic and end_edge_ioapic are void in include/linux/).
Is it possible that this code was transferred with patches for earlier kernels (at least from 2.6.11) ?
I'm going to check this now and hopefully fix it.
[ As a matter of fact, the IO_APIC shouldn't play any role in the processing of MSI interrupts, which are addressed at (default) addr. 0xFEE00000 in the CPU. An exception to this are interrupts issued by PCI cards to the IO_APIC itself (default addr.: 0xFEC00020) to trigger IRQs 0-23, which is a feature Linux doesn't seem to use and was seemingly intended for card mftrs. to support MSI without changing the drivers. ]
Jeroen.
