[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C5CA3E4.1080908@kernel.org>
Date: Fri, 06 Aug 2010 17:08:04 -0700
From: Yinghai Lu <yinghai@...nel.org>
To: mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org,
ebiederm@...ssion.com, tvrtko.ursulin@...hos.com,
hilld@...arystorm.net, tglx@...utronix.de, hpa@...ux.intel.com
CC: linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/urgent] x86, apic: Map the local apic when parsing the
MP table.
On 08/05/2010 05:15 PM, tip-bot for Eric W. Biederman wrote:
> Commit-ID: 5989cd6a1cbf86587edcc856791f960978087311
> Gitweb: http://git.kernel.org/tip/5989cd6a1cbf86587edcc856791f960978087311
> Author: Eric W. Biederman <ebiederm@...ssion.com>
> AuthorDate: Wed, 4 Aug 2010 13:30:27 -0700
> Committer: H. Peter Anvin <hpa@...ux.intel.com>
> CommitDate: Thu, 5 Aug 2010 16:26:42 -0700
>
> x86, apic: Map the local apic when parsing the MP table.
>
> This fixes a regression in 2.6.35 from 2.6.34, that is
> present for select models of Intel cpus when people are
> using an MP table.
>
> The commit cf7500c0ea133d66f8449d86392d83f840102632
> "x86, ioapic: In mpparse use mp_register_ioapic" started
> calling mp_register_ioapic from MP_ioapic_info. An extremely
> simple change that was obviously correct. Unfortunately
> mp_register_ioapic did just a little more than the previous
> hand crafted code and so we gained this call path.
>
> The problem call path is:
> MP_ioapic_info()
> mp_register_ioapic()
> io_apic_unique_id()
> io_apic_get_unique_id()
> get_physical_broadcast()
> modern_apic()
> lapic_get_version()
> apic_read(APIC_LVR)
>
> Which turned out to be a problem because the local apic
> was not mapped, at that point, unlike the similar point
> in the ACPI parsing code.
>
> This problem is fixed by mapping the local apic when
> parsing the mptable as soon as we reasonably can.
>
> Looking at the number of places we setup the fixmap for
> the local apic, I see some serious simplification opportunities.
> For the moment except for not duplicating the setting up of the
> fixmap in init_apic_mappings, I have not acted on them.
>
> The regression from 2.6.34 is tracked in bug
> https://bugzilla.kernel.org/show_bug.cgi?id=16173
>
> Cc: <stable@...nel.org> 2.6.35
> Reported-by: David Hill <hilld@...arystorm.net>
> Reported-by: Tvrtko Ursulin <tvrtko.ursulin@...hos.com>
> Tested-by: Tvrtko Ursulin <tvrtko.ursulin@...hos.com>
> Signed-off-by: Eric W. Biederman <ebiederm@...ssion.com>
> LKML-Reference: <m1eiee86jg.fsf_-_@...s.ebiederm.org>
> Signed-off-by: H. Peter Anvin <hpa@...ux.intel.com>
> ---
> arch/x86/kernel/apic/apic.c | 2 +-
> arch/x86/kernel/mpparse.c | 16 ++++++++++++++++
> 2 files changed, 17 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> index a96489e..c07e513 100644
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -1606,7 +1606,7 @@ void __init init_apic_mappings(void)
> * acpi lapic path already maps that address in
> * acpi_register_lapic_address()
> */
> - if (!acpi_lapic)
> + if (!acpi_lapic && !smp_found_config)
> set_fixmap_nocache(FIX_APIC_BASE, apic_phys);
>
> apic_printk(APIC_VERBOSE, "mapped APIC to %08lx (%08lx)\n",
this change is not needed, it will break:
1. found mptable, but is using default contruct path.
2. visws path, found found mptable, but get_smp_conf is not called.
YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists