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:martin.wilck at fujitsu-siemens.com Internet: http://www.fujitsu-siemens.com Company Details: http://www.fujitsu-siemens.com/imprint.html
