Tested on my POWER8 machine.

In D17806#394036, @sbruno wrote:

This panic is fairly reliable on our Power8 box. Is it related to this change or is it unrelated? I'm not convinced this panic should keep this review blocked as it resolves other things.

panic: Memory modified after free 0xc0000000850584a0(32) val=0 @ 0xc0000000850584a0

cpuid = 31
time = 1544381394
KDB: stack backtrace:
0xe000000090207030: at .kdb_backtrace+0x5c
0xe000000090207160: at .vpanic+0x1b4
0xe000000090207220: at .panic+0x38
0xe0000000902072b0: at .trash_ctor+0x58
0xe000000090207330: at .trash_fini+0x1c
0xe0000000902073b0: at .uma_zdestroy+0x164
0xe000000090207460: at .uma_zdestroy+0x42c
0xe0000000902074f0: at .sys_swapoff+0x2c4
0xe000000090207580: at .uma_zfree_pcpu_arg+0x340
0xe000000090207610: at .zone_drain+0x18
0xe000000090207690: at .uma_avail+0x4c4
0xe000000090207720: at .zone_drain+0x410
0xe0000000902077b0: at .uma_reclaim_worker+0x20c
0xe000000090207860: at .fork_exit+0xd0
0xe000000090207900: at .fork_trampoline+0x10
0xe000000090207930: at -0x4
KDB: enter: panic

Great!
Thanks for fixing the issue I left behind on this!

In D17601#379168, @mmacy wrote:

I just rebased to today's HEAD from that of the 6th. This change makes my system unbootable. I haven't delved in to it, but my guess is I don't have enough contiguous memory below the limit (my system has 512GB)

In D16633#353456, @jhibbits wrote:

Approved. A cleaner solution might be to add another SI_SUB_ node, or reuse an existing one for all cases. But this unblocks us, and is sufficient. SI_SUB_INIT_IF looks like a good one (no need to do it now).

Yes, it is working fine for me.
I tried a couple different number of CPUs, with and without usefdt, and it all worked fine.
Although for me /chosen/cpu always seems to exist, so the /chosen/fdtbootcpu part wasn't tested.

• Use /chosen/{cpu,fdtbootcpu} to detect boot CPU

Minor style fix

Ok, good to know, let me try that.

In D15174#320379, @nwhitehorn wrote:

We should fix that, too, though. This code assumes that we are booting on CPU 0 -- the same assumption could continue as a stopgap until we figure out a reliable way to evaluate the boot processor.

In D15174#320058, @nwhitehorn wrote:

Is there a reason not to just adopt the PowerNV version of this code, which already does the right thing?

Made cpu discovery accept non-contiguous ids

• Made cpu discovery accept non-contiguous ids

Thanks @jhibbits! Can you commit the change for me?

• Addressing review's comments