On Mon, Feb 13, 2012 at 4:52 AM, Eric W. Biederman <ebiederm at xmission.com> wrote: > Yinghai Lu <yinghai at kernel.org> writes: > >> On Sat, Feb 11, 2012 at 7:13 PM, Eric W. Biederman >> <ebiederm at xmission.com> wrote: >>> Yinghai Lu <yinghai at kernel.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
