Re: [PATCH] x86: Remove wrong error message in x86_default_fixup_cpu_id

From: Daniel J Blueman
Date: Tue Feb 21 2012 - 06:05:23 EST


On 21/02/2012 10:27, Borislav Petkov wrote:
On Mon, Feb 20, 2012 at 06:17:05PM +0100, Andreas Herrmann wrote:

It's only called from amd.c:srat_detect_node(). The introduced
condition for calling the fixup code is true for all AMD multi-node
processors, e.g. Magny-Cours and Interlagos. There we have 2 NUMA
nodes on one socket. And thus there are cores having different
numa-node-id but with equal phys_proc_id. For example on such a system
we now get

[ 0.228109] Booting Node 0, Processors #1
[ 0.232337] smpboot cpu 1: start_ip = 83000
[ 0.252088] #2
[ 0.253746] smpboot cpu 2: start_ip = 83000
[ 0.272086] #3
[ 0.276018] smpboot cpu 3: start_ip = 83000
[ 0.296088] #4
[ 0.297745] smpboot cpu 4: start_ip = 83000
[ 0.316088] #5
[ 0.320021] smpboot cpu 5: start_ip = 83000
[ 0.340113] Ok.
[ 0.342324] Booting Node 1, Processors #6
[ 0.344344] smpboot cpu 6: start_ip = 83000
[ 0.016000] NUMA core number 1 differs from configured core number 0
[ 0.372110] #7
[ 0.373771] smpboot cpu 7: start_ip = 83000
[ 0.016000] NUMA core number 1 differs from configured core number 0
[ 0.396104] #8
[ 0.397764] smpboot cpu 8: start_ip = 83000
[ 0.016000] NUMA core number 1 differs from configured core number 0
[ 0.420109] #9
[ 0.421773] smpboot cpu 9: start_ip = 83000
[ 0.016000] NUMA core number 1 differs from configured core number 0
[ 0.444113] #10
[ 0.445865] smpboot cpu 10: start_ip = 83000
[ 0.016000] NUMA core number 1 differs from configured core number 0
[ 0.468111] #11
[ 0.472030] smpboot cpu 11: start_ip = 83000
[ 0.016000] NUMA core number 1 differs from configured core number 0

These NUMA core numbering error messages are plain wrong.

The confusing/misleading error message was introduced with commit
64be4c1c2428e148de6081af235e2418e6a66dda (x86: Add x86_init platform
override to fix up NUMA core numbering) and should be removed.

Reported-by: Borislav Petkov<borislav.petkov@xxxxxxx>
Signed-off-by: Andreas Herrmann<andreas.herrmann3@xxxxxxx>
---
arch/x86/kernel/cpu/common.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)

BTW, I wonder why the fixup code isn't called from the Intel path. At
least the mentioned patch suggests that something more generic was
introduced here.
Right, and I would remove the check in amd.c:srat_detect_node() instead
of removing the printk statement in the default implementation.

IOW, we need more info on why the check was added only to the AMD path?
Daniel?

The check and fixup wasn't needed in the Intel path thus far, so wasn't added.

We could specialise the 'if (c->phys_proc_id != node)' test to check for x86_cpuinit.fixup_cpu_id being NULL and drop the default override, if that is preferred?

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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/