[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAE9FiQVj12UCGbOe4wZfx-L8tdab-1si-RA=vBnNeZ7cUNqyyg@mail.gmail.com>
Date: Mon, 13 Feb 2012 08:51:00 -0800
From: Yinghai Lu <yinghai@...nel.org>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: linux-kernel@...r.kernel.org, mingo@...hat.com, hpa@...or.com,
torvalds@...ux-foundation.org, kexec@...ts.infradead.org,
vgoyal@...hat.com, akpm@...ux-foundation.org, tglx@...utronix.de,
dzickus@...hat.com, mingo@...e.hu,
linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
crash path
On Mon, Feb 13, 2012 at 4:52 AM, Eric W. Biederman
<ebiederm@...ssion.com> wrote:
> Yinghai Lu <yinghai@...nel.org> writes:
>
>> On Sat, Feb 11, 2012 at 7:13 PM, Eric W. Biederman
>> <ebiederm@...ssion.com> wrote:
>>> Yinghai Lu <yinghai@...nel.org> writes:
>>>> After reverting this commit, kdump is working again.
>>>>
>>>> So assume you need to drop this patch.
>>>
>>> It sounds like there is a bug in ioapic initialization in the context of
>>> VT-d. Where do you fail?
>>>
>> before get debug print out from second kernel, the system get reset.
>
> Ouch.
>
> Don can you work with with Yinghai to figure out what is different
> between your test configuration and his?
>
> YH did you have early printk enabled?
yes.
I always have "console=uart8250,io,0x3f8,115200n8" appended.
also i have local patches that print info from
arch/x86/boot/compressed/misc.c::decompress_kernel()
and
arch/x86/kernel/head64.c::x86_64_start_kernel()
>
> YH Did I understand you properly that things work if you don't enable
> VT-d?
that is default setting for BIOS and OS.
will check if disable that will help.
> By VT-d are you referring to interrupt remapping?
yes, include interrupt rempapping and dma remapping.
>
> For anyone watching. The premise of this patch was that we can boot
> the kernel without resorting to legacy tricks that require us to
> put the interrupt controllers in PIT mode.
>
> Apparently there is some weird corner case that YH can reproduce that
> Don did not have in his test set that YH does that causes things to
> fail.
>
> I really don't see any likely candidates when looking at the code. The
> most I can see is some code that we don't run when interrupt remapping
> is enabled in disable_IO_APIC.
>
> So I suspect we have a bug in our apic initialization somewhere, but
> apic initialization should happen after printk are enabled. Or at least
> after early printks so the reset YH is reporting doesn't make much sense.
will try Don's first version patch that only removing disable_IO_APIC.
Yinghai
--
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/
Powered by blists - more mailing lists