[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1338293627.26856.51.camel@twins>
Date: Tue, 29 May 2012 14:13:47 +0200
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Jiang Liu <liuj97@...il.com>
Cc: Yinghai Lu <yinghai@...nel.org>, mingo@...nel.org,
torvalds@...ux-foundation.org, cmetcalf@...era.com,
tony.luck@...el.com, sivanich@....com, akpm@...ux-foundation.org,
ralf@...ux-mips.org, greg.pearson@...com, ink@...assic.park.msu.ru,
tglx@...utronix.de, rth@...ddle.net,
kamezawa.hiroyu@...fujitsu.com, paulus@...ba.org,
linux-kernel@...r.kernel.org, hpa@...or.com, anton@...ba.org,
lethal@...ux-sh.org, davem@...emloft.net, benh@...nel.crashing.org,
dhowells@...hat.com, mattst88@...il.com, fenghua.yu@...el.com,
linux-tip-commits@...r.kernel.org
Subject: Re: [tip:sched/core] sched/numa: Rewrite the CONFIG_NUMA sched
domain support
On Tue, 2012-05-29 at 08:32 +0800, Jiang Liu wrote:
> Does this patch fix your issue? https://lkml.org/lkml/2012/5/9/183.
> I have encountered a similar issue on an IA64 platform and the patch above
> works around it. But the root cause is a BIOS bug that the order of CPUs
> in MADT table doesn't conform to the ACPI specification and the first CPU
> in MADT is not the BSP, which breaks some assumption of the booting code
> and causes the core dump.
Is that IA64 arch code that contains those false assumptions or is it
generic (sched) code that contains them? Esp in the latter case I'd be
very interested to hear where these are so we can fix them.
--
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