lkml.org 
[lkml]   [2008]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] x86: update mptable v7
    On Wed, Jun 18, 2008 at 9:32 PM, Eric W. Biederman
    <ebiederm@xmission.com> wrote:
    > "Yinghai Lu" <yhlu.kernel@gmail.com> writes:
    >
    >> On Wed, Jun 18, 2008 at 5:33 PM, Len Brown <lenb@kernel.org> wrote:
    >>>
    >>>
    >>> On Wed, 18 Jun 2008, Yinghai Lu wrote:
    >>>
    >>>> On Wed, Jun 18, 2008 at 3:18 PM, Len Brown <lenb@kernel.org> 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


    \
     
     \ /
      Last update: 2008-06-19 07:13    [W:0.031 / U:32.848 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site