[PATCH], issue EOI to APIC prior to calling crash_kexec in die_nmi path
nhorman at tuxdriver.com
Wed Feb 20 09:57:36 EST 2008
On Tue, Feb 12, 2008 at 04:08:16PM -0500, Neil Horman wrote:
> > Neil, is it possible to do some serial console debugging to find out
> > where exactly we are hanging? Beats me, what's that operation which can
> > not be executed while being in NMI handler and makes system to hang. I am
> > also curious to know if it is nested NMI case.
> > Thanks
> > Vivek
> Some intermediate results:
> I've instrumented head.S in the kernel with the following code:
> #define SEROUT(z) \
> mov $0x3F8,%dx;\
> movb z,%al;\
> outb %dx
> And peppered different ascii characters throughout the startup code from
> startup_32 to right before the jump to start_kernel. When I panic the system
> via an:
> echo c > /proc/sysrq_trigger
> I see an appropriate sequence of characters on the serial console
> When I panic the box by forcing an NMI watchdog timeout however, I see nothing.
> The machine will either hang, or reset into the bios. I think this is
> reasonably conclusive in its indication that we're not getting into the second
> kernel when this problem occurs. Next I'll instrument the purgatory code in a
> simmilar way.
Hey, further update. I instrumented purgatory, and turned on the console
options that Eric mentioned, which resulted in no output to the console, so I've
concluded that we don't get to purgatory at all. Further instrumenting shows
that the last C level printk I can issue is right before we call
relocate_kernel. So it appears that we hang/reset somewhere in there. I'll
instrument down that path shortly.
More information about the kexec