linux-kernel - Re: [PATCH] Make Intel 8-way Xeons boot again

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100110102638.GA7838@elte.hu>
Date:	Sun, 10 Jan 2010 11:26:38 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	ananth@...ibm.com, suresh.b.siddha@...el.com,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	lkml <linux-kernel@...r.kernel.org>, stable@...nel.org,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>
Subject: Re: [PATCH] Make Intel 8-way Xeons boot again


* Yinghai Lu <yinghai@...nel.org> wrote:

> On Sat, Jan 9, 2010 at 6:30 PM, Ananth N Mavinakayanahalli
> <ananth@...ibm.com> wrote:
> > On Sat, Jan 09, 2010 at 01:13:39PM -0800, Yinghai Lu wrote:
> >> On Sat, Jan 9, 2010 at 2:10 AM, Ananth N Mavinakayanahalli
> >> <ananth@...ibm.com> wrote:
> >> > On an 8-way system with Intel Xeon X7350 CPUs, booting 2.6.32 or newer
> >> > kernels fails at:
> >> >
> >> > ...
> >> > CPU0: Intel(R) Xeon(R) CPU ? ? ? ? ? X7350 ?@ 2.93GHz stepping 0b
> >> > Booting Node ? 0, Processors ?#1 #2 #3 #4 #5 #6 #7 Ok.
> >> > Brought up 8 CPUs
> >> > Total of 8 processors activated (46906.05 BogoMIPS).
> >> >
> >> > Git bisect showed 2fbd07a5f as the offending commit.
> >> >
> >> > With the patch below, I am able to boot the latest Linus' git tree on
> >> > the machine. If this patch is correct, it needs to get into the stable
> >> > tree too.
> >> >
> >> > Signed-off-by: Ananth N Mavinakayanahalli <ananth@...ibm.com>
> >> > ---
> >> > Index: linux-2.6/arch/x86/kernel/apic/probe_64.c
> >> > ===================================================================
> >> > --- linux-2.6.orig/arch/x86/kernel/apic/probe_64.c ? ? ?2010-01-09 14:54:29.000000000 +0530
> >> > +++ linux-2.6/arch/x86/kernel/apic/probe_64.c ? 2010-01-09 14:57:53.000000000 +0530
> >> > @@ -70,7 +70,7 @@
> >> > ? ? ? ?if (apic == &apic_flat) {
> >> > ? ? ? ? ? ? ? ?switch (boot_cpu_data.x86_vendor) {
> >> > ? ? ? ? ? ? ? ?case X86_VENDOR_INTEL:
> >> > - ? ? ? ? ? ? ? ? ? ? ? if (num_processors > 8)
> >> > + ? ? ? ? ? ? ? ? ? ? ? if (num_processors >= 8)
> >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?apic = &apic_physflat;
> >> > ? ? ? ? ? ? ? ? ? ? ? ?break;
> >> > ? ? ? ? ? ? ? ?case X86_VENDOR_AMD:
> >>
> >> can you send out whole bootlog with apic=debug?
> >
> > Here it is:
> > ACPI: LAPIC (acpi_id[0x00] lapic_id[0x0c] enabled)
> > ACPI: LAPIC (acpi_id[0x01] lapic_id[0x10] enabled)
> > ACPI: LAPIC (acpi_id[0x02] lapic_id[0x0d] enabled)
> > ACPI: LAPIC (acpi_id[0x03] lapic_id[0x11] enabled)
> > ACPI: LAPIC (acpi_id[0x04] lapic_id[0x0e] enabled)
> > ACPI: LAPIC (acpi_id[0x05] lapic_id[0x12] enabled)
> > ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0f] enabled)
> > ACPI: LAPIC (acpi_id[0x07] lapic_id[0x13] enabled)
> ...
> > Setting APIC routing to flat
> > Getting VERSION: 50014
> > Getting VERSION: 50014
> > Getting ID: c000000
> > Getting ID: f3000000
> > Getting LVT0: 700
> > Getting LVT1: 400
> > enabled ExtINT on CPU#0
> > ESR value before enabling vector: 0x00000040 ?after: 0x00000000
> > ENABLING IO-APIC IRQs
> > ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
> > CPU0: Intel(R) Xeon(R) CPU ? ? ? ? ? X7350 ?@ 2.93GHz stepping 0b
> ...
> 
> the BSP's physical apic id is 0x0c instead of 0.
> 
> not sure Suresh test that or not.

In any case this commit needs to be reverted as the assumption that it's safe 
to do this optimization is evidently not true.

	Ingo
--
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/