Hello Eric, > How bad is it if you just run with irqpoll in the kdump kernel? > If running with irqpoll is usable that is probably preferable > to putting in a hardware work around we can survive without.
Yes, I tried that. No effect. > Have you done any looking at moving where the kernel initalizes > io_apics? One of the todo items on the path is to leave > io_apic mode enabled and just startup the kernel in io_apic > mode. I have tried to recover from the "IRR set" situation in several ways by changing setup_IO_APIC_irq(). But I haven't found a way to recover from this situation once disable_IO_APIC() had been called. I concluded thatthe sequence of events "send INT message - never receive EOI - disable IO-APIC pin" messes up the IO-APIC (at least this specific one in the PCIEx-PCI bridge of the ICH7). The current state of affairs is that the only thing that "worked" was to re-enable irqs. > When doing that a version of your work around (if needed) > would certainly be reasonable. > My general concern is that the trickier we get in the code > running in the crashed kernel the less reliable the entire > process will be. That's certainly correct. I am grateful for all hints that simplify my patch. Thanks, 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/
