Re: [tip:sched/core] sched/numa: Rewrite the CONFIG_NUMA sched domain support
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: [tip:sched/core] sched/numa: Rewrite the CONFIG_NUMA sched domain support
- From: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
- Date: Tue, 29 May 2012 14:13:47 +0200
- Cc: Yinghai Lu <yinghai@xxxxxxxxxx>, mingo@xxxxxxxxxx, torvalds@xxxxxxxxxxxxxxxxxxxx, cmetcalf@xxxxxxxxxx, tony.luck@xxxxxxxxx, sivanich@xxxxxxx, akpm@xxxxxxxxxxxxxxxxxxxx, ralf@xxxxxxxxxxxxxx, greg.pearson@xxxxxx, ink@xxxxxxxxxxxxxxxxxxxx, tglx@xxxxxxxxxxxxx, rth@xxxxxxxxxxx, kamezawa.hiroyu@xxxxxxxxxxxxxx, paulus@xxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, hpa@xxxxxxxxx, anton@xxxxxxxxx, lethal@xxxxxxxxxxxx, davem@xxxxxxxxxxxxx, benh@xxxxxxxxxxxxxxxxxxx, dhowells@xxxxxxxxxx, mattst88@xxxxxxxxx, fenghua.yu@xxxxxxxxx, linux-tip-commits@xxxxxxxxxxxxxxx
- In-reply-to: <4FC41903.1060705@gmail.com>
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-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Index of Archives]
[Linux Stable Commits]
[Linux Stable Kernel]
[Linux Kernel]
[Linux USB Devel]
[Linux Video &Media]
[Linux Audio Users]
[Yosemite News]
[Linux SCSI]
