Messages in this thread Patch in this message | | | Date | Mon, 26 Sep 2016 15:35:44 -0400 (EDT) | From | Thomas Gleixner <> | Subject | Re: [x86-tip] strange nr_cpus= boot regression |
| |
On Mon, 26 Sep 2016, Thomas Gleixner wrote: > Can you please provide your .config and the dmesg of a bad and a good run?
Don't bother. I found it.
It's a merge artifact. So git bisect pointing at the merge commit is entirely correct.
mainline moves
num_processors++;
to a different place in the function. See commit c291b0151585.
Now the nodeid patch set in x86/apic does not have this commit and so f7c28833c2520 removes num_processors++ from the original location before c291b0151585.
Now merging both branches does not conflict because both remove it from the original location. Though both add it to new locations and it ends up with both instances of num_processors++ in place.
Which of course makes each invocation increment twice and therefor cuts the number of cpus in half.
So it's my fault that I did not merge x86/urgent into x86/apic before I added the nodeid bits. And of course because the thing did not reject and the merge of it into master gave no conflicts I did not notice ....
Here is a patch against tip/master which fixes the issue at least for Boris. I'm going to merge that other commit into x86/apic and fix it up so we don't end up with that mess again.
Thanks,
tglx
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c index 46bb29958509..f266b8a92a9e 100644 --- a/arch/x86/kernel/apic/apic.c +++ b/arch/x86/kernel/apic/apic.c @@ -2171,8 +2171,6 @@ int __generic_processor_info(int apicid, int version, bool enabled) return -ENOSPC; } - num_processors++; - /* * Validate version */
| |