Re: [x86-tip] strange nr_cpus= boot regression

From: Dou Liyang
Date: Mon Sep 26 2016 - 22:07:42 EST

Hi tglx,

I'm sorry for the late reply.
Awfully sorry that I could not do anything help.

In fact, it's my fault.
I should re-base my patches after the commit c291b0151585 in time.

I learned a lot from it.
Thank a lot, and once again my apologies.



At 09/27/2016 01:36 AM, Thomas Gleixner wrote:
CC'ed: Dou Liyang

On Mon, 26 Sep 2016, Mike Galbraith wrote:

I've encountered a strange regression in tip, symptom is that if you
boot with nr_cpus=nr_you_have, what actually boots is nr_you_have/2.
Do not pass nr_cpus=, and all is well.

What's the number of possible cpus in your system?

Bisection repeatedly goes as below, pointing to the nodeid merge,
despite both timers/core and x86/apic (nodeid) being fine. Take tip
HEAD, extract all of the commits from nodeid (plus the fix), and revert
them in a quilt tree, the tree remains busted.

So you remove all the nodeid commits from tip/master and it's still broken?

Checkout the timers/core merge commit, and merge nodeid with that, it is
indeed bad.

Bisecting takes you right the merge commit, with no commit
being 'bad', see logs.

That's more than strange. An empty merge commit being the culprit.