Vivek Goyal wrote: > Did you also check IRR bits on LAPIC. May be some interrupt is already > being served and your new interrupts has been queued on LAPIC and IRR bit > on LAPIC is set?
That's it. Whenever the IO-APIC IRR bit is set, I see the LAPIC IRR bit set, too. I never see any ISR bits set. Very rarely I see that IRQs are IRQ_PENDING or IRQ_INPROGRESS, but that's apparently unrelated to the problem. Actually, I often see APIC IRR bits set, but it only seems to matter for IRQs coming from the secondary IO-APIC. Unfortunately, just writng APIC_EOI in this situation (when an IRR bit is set) has no effect. I have tried to set the IRQ_DISABLED flag for all IRQs. From my understanding, if I re-enable IRQs, that disables the actual IRQ handlers, but the ack() function of the IRQ chip (which, in our case, sends EOI) is called anyway. *That appears to work*, in the kdump kernel the IRR is cleared. I'll run an overnight test with that technique tonight. Martin -- Martin Wilck PRIMERGY System Software Engineer FSC IP ESP DE6 Fujitsu Siemens Computers GmbH Heinz-Nixdorf-Ring 1 33106 Paderborn Germany Tel: ++49 5251 8 15113 Fax: ++49 5251 8 20409 Email: mailto:[EMAIL PROTECTED] Internet: http://www.fujitsu-siemens.com Company Details: http://www.fujitsu-siemens.com/imprint.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
