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

[Dou Liyang <douly.fnst@cn.fujitsu.com>]

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.

Thanks,

Dou

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.
>
> Thanks,
>
> 	tglx
>
>