From: Borislav Petkov <bp@amd64.org>
To: Tejun Heo <tj@kernel.org>
Cc: Andreas Herrmann <andreas.herrmann3@amd.com>,
Conny Seidel <conny.seidel@amd.com>, Ingo Molnar <mingo@elte.hu>,
LKML <linux-kernel@vger.kernel.org>
Subject: WARNING: at arch/x86/kernel/apic/apic.c:1239 setup_local_APIC+...
Date: Fri, 14 Oct 2011 15:55:16 +0200 [thread overview]
Message-ID: <20111014135516.GC11990@aftab> (raw)
[-- Attachment #1: Type: text/plain, Size: 3949 bytes --]
Hi,
we're hitting the warning below
<arch/x86/kernel/apic/apic.c>:
...
i = early_per_cpu(x86_cpu_to_logical_apicid, cpu);
WARN_ON(i != BAD_APICID && i != logical_smp_processor_id()); <--- HERE
/* always use the value from LDR */
early_per_cpu(x86_cpu_to_logical_apicid, cpu) =
logical_smp_processor_id();
during 32-bit testing, config is attached.
acb8bc09c6185e4d3d582d0076aaa6a89f19d8c5 added this warning
and triggers on the second part of the condition. I've dumped
x86_cpu_to_logical_apicid and logical_smp_processor_id and here's what I
get on a 32-cores box:
...
[ 4.268493] CPU 31 irqstacks, hard=e5b1e000 soft=e5b20000
[ 4.269358] #31 Ok.
[ 4.270358] smpboot cpu 31: start_ip = 80000
[ 0.003999] Initializing CPU#31
[ 0.003999] ------------[ cut here ]------------
[ 0.003999] WARNING: at arch/x86/kernel/apic/apic.c:1239 setup_local_APIC+0x12c/0x3bd()
[ 0.003999] Hardware name: None
[ 0.003999] i: -2147483648, lg_smp_id: 79
[ 0.003999] Modules linked in:
[ 0.003999] Pid: 0, comm: kworker/0:1 Tainted: G W 3.1.0-rc9-37cf9516-linus+ #1
[ 0.003999] Call Trace:
[ 0.003999] [<c1035066>] warn_slowpath_common+0x65/0x7a
[ 0.003999] [<c10350ee>] warn_slowpath_fmt+0x2b/0x2f
[ 0.003999] [<c16603bb>] setup_local_APIC+0x12c/0x3bd
[ 0.003999] [<c165fcae>] start_secondary+0x9f/0x18f
[ 0.003999] ---[ end trace 4eaa2a86a8e2da41 ]---
That's right, x86_cpu_to_logical_apicid wraps around so if I were to
boot a 32-bit kernel on a 64 cores box, I'd get each two cores to have
the same logical apic id.
Oh, and logical_smp_processor_id(), i.e. logical APIC ID starts at 0x20,
acc. to SRAT:
[ 0.000000] SRAT: PXM 0 -> APIC 0x20 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x21 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x22 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x23 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x24 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x25 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x26 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x27 -> Node 0
[ 0.000000] SRAT: PXM 1 -> APIC 0x28 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x29 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x2a -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x2b -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x2c -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x2d -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x2e -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x2f -> Node 1
[ 0.000000] SRAT: PXM 2 -> APIC 0x40 -> Node 2
[ 0.000000] SRAT: PXM 2 -> APIC 0x41 -> Node 2
[ 0.000000] SRAT: PXM 2 -> APIC 0x42 -> Node 2
[ 0.000000] SRAT: PXM 2 -> APIC 0x43 -> Node 2
[ 0.000000] SRAT: PXM 2 -> APIC 0x44 -> Node 2
[ 0.000000] SRAT: PXM 2 -> APIC 0x45 -> Node 2
[ 0.000000] SRAT: PXM 2 -> APIC 0x46 -> Node 2
[ 0.000000] SRAT: PXM 2 -> APIC 0x47 -> Node 2
[ 0.000000] SRAT: PXM 3 -> APIC 0x48 -> Node 3
[ 0.000000] SRAT: PXM 3 -> APIC 0x49 -> Node 3
[ 0.000000] SRAT: PXM 3 -> APIC 0x4a -> Node 3
[ 0.000000] SRAT: PXM 3 -> APIC 0x4b -> Node 3
[ 0.000000] SRAT: PXM 3 -> APIC 0x4c -> Node 3
[ 0.000000] SRAT: PXM 3 -> APIC 0x4d -> Node 3
[ 0.000000] SRAT: PXM 3 -> APIC 0x4e -> Node 3
[ 0.000000] SRAT: PXM 3 -> APIC 0x4f -> Node 3
The warning triggers IMHO because we switch to bigsmp APIC in
default_setup_apic_routing() but the early x86_cpu_to_logical_apicid
enumeration comes from default_x86_32_early_logical_apicid()
which gets called as part of the default apic deal as part of
generic_processor_info().
So, in the end, and AFAICR, the warning triggers because we're comparing
logical APIC IDs from the APIC Logical Destination Register (0xD0) which
have been assigned by BIOS with "1 << cpu" shifted values which wrap on
32-bit.
I'd very much like to know why?
Thanks.
--
Regards/Gruss,
Boris.
Operating Systems Research Center
Advanced Micro Devices, Inc.
[-- Attachment #2: config.gz --]
[-- Type: application/octet-stream, Size: 16878 bytes --]
next reply other threads:[~2011-10-14 13:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-14 13:55 Borislav Petkov [this message]
2011-10-14 16:56 ` WARNING: at arch/x86/kernel/apic/apic.c:1239 setup_local_APIC+ Borislav Petkov
2011-10-14 17:55 ` Tejun Heo
2011-10-15 22:12 ` Borislav Petkov
2011-10-16 22:07 ` Conny Seidel
2011-10-17 7:23 ` Borislav Petkov
2011-10-17 7:38 ` Ingo Molnar
2011-10-17 7:53 ` Borislav Petkov
2011-10-17 7:23 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111014135516.GC11990@aftab \
--to=bp@amd64.org \
--cc=andreas.herrmann3@amd.com \
--cc=conny.seidel@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox