Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760129AbXK0XT7 (ORCPT ); Tue, 27 Nov 2007 18:19:59 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754727AbXK0XTw (ORCPT ); Tue, 27 Nov 2007 18:19:52 -0500 Received: from mx1.redhat.com ([66.187.233.31]:42597 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754094AbXK0XTv (ORCPT ); Tue, 27 Nov 2007 18:19:51 -0500 Message-ID: <474CA520.60804@redhat.com> Date: Tue, 27 Nov 2007 15:15:44 -0800 From: Ben Woodard User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: "Eric W. Biederman" CC: Neil Horman , Neil Horman , kexec@lists.infradead.org, Andi Kleen , linux-kernel@vger.kernel.org, hbabu@us.ibm.com, vgoyal@in.ibm.com Subject: Re: [PATCH] kexec: force x86_64 arches to boot kdump kernels on boot cpu References: <20071127014740.GA28622@hmsreliant.think-freely.org> <200711271445.56792.ak@suse.de> <20071127142826.GB31376@hmsreliant.think-freely.org> <200711271543.11809.ak@suse.de> <20071127144856.GC31376@hmsreliant.think-freely.org> <474C832C.1060903@redhat.com> <20071127210558.GI14887@hmsendeavour.rdu.redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2728 Lines: 68 Eric W. Biederman wrote: > Neil Horman writes: > >>> ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 > > Ben, what chipset is this? nVidia MCP55 pro It is the original version of http://www.supermicro.com/Aplus/motherboard/Opteron8000/MCP55/H8QM8-2.cfm i.e. not the -2. However, they don't seem to advertise the original version. Supermicro assures me that they are practically the same but I haven't played with the -2 version yet. > >> Ok, I think from what I understand of what we're reading here, the apic2 = -1 >> and pin2 = -1 indicate that the 8259 has no direct connection to any cpu, which >> means that on shutdown disable_IO_APIC should take us into virtual wire mode. >> As such enabling the APIC early in boot should fix us, but more consisely, >> rewriting the entry in the IOAPIC to deliver int0 to the only running cpu should >> accomplish the same goal for this problem. Does that sound reasonable (at least >> as a test to ensure we understand the problem) to everyone? > > Close. There are two options with virtual wire mode. > - Either the local apic is in virtual wire mode, and somehow the > legacy interrupts make it to the local cpu. > - Or an ioapic is in virtual wire mode and the legacy interrupt > controller is connected to it. > > So I guess fundamentally for any SMP system that only supports the > cpu being in local apic mode and only routes interrupts to the boot > strap processor we could be in trouble. That is what our current > information about your system suggests. > > However most systems actually connect the i8254 PIC interrupt > controller to the ioapic in virtual wire mode. As I recall the > standard mapping is to ioapic 0, pin 0. With ioapic 0, pin 2 being > the timer interrupt (Possibly it is the other way around). > > So as a test we could feed those values into ioapic_8259 and see > if the kdump case works. I believe we prefer putting the ioapic > into virtual wire mode over putting the cpu into virtual wire > mode. We can only control which cpu receives the legacy interrupts if > we are putting the ioapic in virtual wire mode. > > It may also be an interesting test to just enable the timer for the > ioapic in early boot, as you have suggested. I don't have a clue what > that will do. > > Eric > > _______________________________________________ > kexec mailing list > kexec@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec -- -ben -=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/