From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx1.redhat.com ([209.132.183.28]) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1RutEQ-0005Bf-A1 for kexec@lists.infradead.org; Tue, 07 Feb 2012 22:09:47 +0000 Date: Tue, 7 Feb 2012 16:57:41 -0500 From: Don Zickus Subject: Re: [PATCH] x86, kdump: No need to disable ioapic in crash path Message-ID: <20120207215741.GD5650@redhat.com> References: <1328206323-25580-1-git-send-email-dzickus@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: kexec-bounces@lists.infradead.org Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: "Eric W. Biederman" Cc: x86@kernel.org, kexec-list , LKML , Vivek Goyal On Thu, Feb 02, 2012 at 03:24:46PM -0800, Eric W. Biederman wrote: > > Eric, brought up a point that because the boot code was restructured we may > > not need to disable the io apic any more in the crash path. The original > > concern that led to the development of disable_IO_APIC, was that the TSC > > calibration on boot up relied on the PIT timer for reference. Access > > to the PIT required 8259 interrupts to be working. This wouldn't work > > if the ioapic needed to be configured. So on panic path, the ioapic was > > reconfigured to use virtual wire mode to allow the 8259 to passthrough. > > A small clarification originally it was the jiffies calibration that > would fail if we could cause the PIT to generate interrupts through the > 8259. The boot would then hang at calibrating jiffies. Ok. Thanks! > > > Those concerns don't hold true now, thanks to the fast TSC calibration code > > not needing the PIT. As a result, we can remove this call and simplify the > > locking needed in the panic path. > > > > I tested kdump on an Ivy Bridge platform, a Pentium4 and an old athlon that > > did not have an ioapic. All three were successful. > > > > Cc: Eric W. Biederman > > Cc: Vivek Goyal > > Signed-off-by: Don Zickus > > > > --- > > I will probably need some help with my explaination as to why this line is not > > needed. Any input is appreciated! > > Can you test and verify that we also do not need the lapic_shutdown() > call and the disable_local_APIC call on the other processors. The same > reasoning that supports us not needing to disable the IO_APIC also > supports us not needing to disable local apic. I did that and it seemed to work on my Ivy Bridge and core2 quad systems. > > Removing disable_IO_APIC in and of itself and then booting isn't quite > sufficient as a practical test to prove this code always works. > Sometimes the IOAPIC was not hooked up to interesting interrupt sources > like the 8259. So what systems should I look for to test? Cheers, Don _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec