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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
