linux-kernel - Re: [PATCH], issue EOI to APIC prior to calling crash_kexec in die

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20080220145736.GA3771@localhost.localdomain>
Date:	Wed, 20 Feb 2008 09:57:36 -0500
From:	Neil Horman <nhorman@...driver.com>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
	mingo@...hat.com, "Eric W. Biederman" <ebiederm@...ssion.com>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
	tglx@...utronix.de
Subject: Re: [PATCH], issue EOI to APIC prior to calling crash_kexec in die_nmi path

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
> > 
> 
> 
> Hey-
> 	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.
> 
> Regards
> Neil
> 
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.

Regards
Neil

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/