[tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in crash path

Yinghai Lu yinghai at kernel.org
Wed Mar 7 13:27:07 EST 2012


2012/3/7 Vivek Goyal <vgoyal at redhat.com>:
> On Wed, Mar 07, 2012 at 07:53:16PM +0900, Fernando Luis Vázquez Cao wrote:
>> On 03/01/2012 08:19 AM, Eric W. Biederman wrote:
>>
>> >Don Zickus<dzickus at redhat.com>  writes:
>> >>It probably is, except I never hacked on idt code before and my assembly
>> >>isn't that good.  I have been trying to find examples to copy from to give
>> >>it a try.  So far I was using early_idt_handlers with early_printk to see
>> >>if I could capture some printk messages while jumping from the first
>> >>kernel to the second kernel (when the other early_idt_handlers would kick
>> >>in for the second kernel).
>> >>
>> >>Tips?  Better examples?
>> >That is a particularly good example.  When I took a quick look earlier
>> >that is the first place we reload the idt in the kernel boot so that is
>> >one of two places that needs to be modified.
>>
>> Hi Eric, Don
>>
>> Sorry for chiming in so late.
>>
>> We run into the same NMI problems and wrote some patches that tackle
>> the kernel boot side of things. They have been extensively tested using
>> qemu-kvm and things seem to be working as expected (after receiving an
>> early NMI the kernel continues without problem; after the iret there is no
>> stack corruption or register corruption).
>
> What happens if NMI happens while we are still in purgatory code?
>
yes, you are right. that is too late to set that in arch/x86/kernel/head64.c

i even not get print out "early console in decompress_kernel"
from arch/x86/boot/compressed/misc.c::decompress_kernel()

Yinghai



More information about the kexec mailing list