On 02/02/2016 07:28 PM, Denis Kirjanov wrote: > On 2/1/16, Mahesh J Salgaonkar <mah...@linux.vnet.ibm.com> wrote: >> From: Mahesh Salgaonkar <mah...@linux.vnet.ibm.com> >> >> The kernel boot parameter 'nr_cpus=' allows one to specify number of >> possible cpus in the system. In the normal scenario the first cpu (cpu0) >> that shows up is the boot cpu and hence it gets covered under nr_cpus >> limit. >> >> But this assumption will be broken in kdump scenario where kdump kenrel >> after a crash can boot up on an non-zero boot cpu. The paca structure >> allocation depends on value of nr_cpus and is indexed using logical cpu >> ids. This definetly will be an issue if boot cpu id > nr_cpus > And what happend in this case? Have you tried it out?
Yes I have. It results into memory corruption when set_hard_smp_processor_id(boot_cpu_id,..) is called from early_init_dt_scan_cpus() and then kernel fails to boot. Nothing shows up in console and system hangs forever. You can easily reproduce this by configuring kdump service to use 'nr_cpus=1' instead of 'maxcpus=1' and then trigger system crash from any cpu other than 0 e.g. $ taskset -c 10 echo c > /proc/sysrq-trigger Thanks, -Mahesh. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
