[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F5F1385.60406@numascale-asia.com>
Date: Tue, 13 Mar 2012 17:29:41 +0800
From: Daniel J Blueman <daniel@...ascale-asia.com>
To: Ingo Molnar <mingo@...e.hu>,
Suresh Siddha <suresh.b.siddha@...el.com>
CC: "H. Peter Anvin" <hpa@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org, x86@...nel.org,
Steffen Persvold <sp@...ascale.com>,
Yinghai Lu <yinghai@...nel.org>
Subject: x2APIC and many-APIC systems...
Ingo, Suresh,
Commit a35fd28256e7736cc84af8931a16224f0bfaaf6c prevents x2APIC
structures being used from the ACPI MADT if the cores don't advertise
the x2APIC feature. Commit c284b42abadbb22083bfde24d308899c08d44ffa
prevents onlining cores with APIC ID >255 in non-x2APIC mode. Since
NumaChip/NumaConnect uses x2APIC structures to describe non-x2APIC
systems (AMD Opteron) with lots of APICs, we thus now can't boot all the
cores.
We are able to set the x2APIC bit in the processor feature flags, so get
caught by the second patch. Is there an appropriate approach to use in
these circumstances? Otherwise, would a patch that separates the APIC ID
handover and future x2APIC MSR access be appropriate?
Many thanks,
Daniel
--
Daniel J Blueman
Principal Software Engineer, Numascale Asia
--
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