Hi Dave,
Because we will increase the CONFIG_NR_CPUS in our kernel on Itanium
in the future (from now 1024 to 4096). This also affects crash. IMO
it's a good idea to have that change also in the mainline crash to be
able to also use the mainline crash for analysing SLES dumps.
The first patch [1] attached implements this -- it's quite trivial, of
course. :) Yes, the number is higher than 4096, but then we don't have
to increase the constant again in future again and again.
The drawback is that the mainline crash still has the compile time
NR_CPUS == kernel CONFIG_NR_CPUS dependency for LKCD dumps. So, after
applying the patch, LKCD dumps may break on IA64.
The solution for that problem is to calculate the number of CPUs for
IA64 at runtime. The 2nd patch implements this, and also reads the
registers from the LKCD dump header instead of guessing on the stack.
This fixes a problem here -- unfortunately, I don't still have that
dump to provide further details.
I posted a similar patch (the reason that I re-based the patch is to
touch less files and to address some of the concerns you and Troy had)
in the past. I think we finally need to merge something in that
direction mainline.
I can split the patch so that you only apply the part which calculates
the number of CPUs at runtime which blocks increasing NR_CPUS for
kdump. But I'd like to get first your and Troy's opinion on this, I
know, he's maintaining the LKCD part of crash.
Thanks,
Bernhard