On 02/02/2016 07:28 PM, Denis Kirjanov wrote: > On 2/1/16, Mahesh J Salgaonkar <[email protected]> wrote: >> From: Mahesh Salgaonkar <[email protected]> >> >> 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 [email protected] https://lists.ozlabs.org/listinfo/linuxppc-dev
