From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755462AbYFSFLT (ORCPT ); Thu, 19 Jun 2008 01:11:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751333AbYFSFLK (ORCPT ); Thu, 19 Jun 2008 01:11:10 -0400 Received: from rv-out-0506.google.com ([209.85.198.234]:43264 "EHLO rv-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751290AbYFSFLI (ORCPT ); Thu, 19 Jun 2008 01:11:08 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=upMtw3OtZvQJMA2K+1L5oHivV+3SJjwyxq9cuvbqRZpxW/AkQWRdEllGpVA12iRan5 bsAlKd7TMqdf62Lxei9eEyaUUq2FeTLeC+vhux9fI6d3upXPvAZ9YzyTLgi3VBW3hRnW 8LG06mO1MVsS458ia4/BE31OE55mqChyfLp2M= Message-ID: <86802c440806182211u6949cbe2r3cd8b987d06eb284@mail.gmail.com> Date: Wed, 18 Jun 2008 22:11:08 -0700 From: "Yinghai Lu" To: "Eric W. Biederman" Subject: Re: [PATCH] x86: update mptable v7 Cc: "Len Brown" , "Ingo Molnar" , "Thomas Gleixner" , "H. Peter Anvin" , "Andrew Morton" , "linux-kernel@vger.kernel.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200805041823.57198.yhlu.kernel@gmail.com> <200805191252.36814.yhlu.kernel@gmail.com> <200805251600.26325.yhlu.kernel@gmail.com> <200806011317.38622.yhlu.kernel@gmail.com> <86802c440806181532g348864e1u3d067f8366046a7f@mail.gmail.com> <86802c440806181749g2faf1892iea693717ea919631@mail.gmail.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 18, 2008 at 9:32 PM, Eric W. Biederman wrote: > "Yinghai Lu" writes: > >> On Wed, Jun 18, 2008 at 5:33 PM, Len Brown wrote: >>> >>> >>> On Wed, 18 Jun 2008, Yinghai Lu wrote: >>> >>>> On Wed, Jun 18, 2008 at 3:18 PM, Len Brown wrote: >>>> > >>>> > >>>> > On Sun, 1 Jun 2008, Yinghai Lu wrote: >>>> > >>>> >> >>>> >> make mptable to be consistent to acpi routing, so we could >>>> >> 1. kexec kernel with acpi=off >>>> >> 2. workaround BIOS that acpi routing is working, but mptable is not right. >>>> >> so can use kernel/kexec to start other os that doesn't have good acpi >> support >>>> > >>>> > Is this an effort to boot an ACPI-mode kernel, >>>> > and then kexec a non-ACPI kernel? >>>> >>>> Yes, >>> >>> Why is this feature needed? >>> There are a number of ways that the resulting kernel may fail, >>> all platform specific. >> >> other os still doesn't have update acpi irq routing support. but has >> broken mptable. > > Which is at least in part a reason to go back to the BIOS manufacturer > and get them to fix their table. > > I can see a warning coming from the kernel if these two tables are inconsistent > though. > >>>> > Doing so could confuse the heck out of the platform firmware, >>>> > which will think that an ACPI-mode kernel is still running. >>>> > >>>> > Note that it is a historic artifact, now considered a bug, >>>> > that ACPI uses the MPS code. We should be divorcing these >>>> > two bodies of code rather than mixing them further. >>>> >>>> how about adding config option to not compile mptable related info? >>> >>> That's the idea. >>> CONFIG_MPS=n CONFIG_ACPI=y should build and run on >>> every PC built in this century. >>> >>> This was prototyped a long while back, but the >>> tree has churned so much since then the old >>> prototype is worthless. >> >> will look at it tonight. >> >> when EFI is popular, there is no reason to compile mps related stuff >> in kernel again. esp for 64 bit. > > ? EFI has nothing to do with this. ACPI is popular today and EFI preserves > EFI. > >> BTW, it is funny that Suse still has fallsafe boot entry with acpi=off. > > Silly question. Given that even writing to this table is platform specific. > Any chance we can do this any a userspace utility writing through /dev/mem > for the systems that need it? We can even bundle the utility in the kexec-tools > package to make it easier to distribute. interesting, never thought that. need to call pci_acpi_enable_irq==>mp_config_acpi_gsi in kernel to save mp_irqs... also we could use old kernel kexec second kernel (with this patch and acpi, and uptable) and then use second kernel to kexec last kernel... YH