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
From: Bernhard Walle <bwalle@xxxxxxx> Subject: [PATCH] Increase NR_CPUS to 16348 References: BZ #334609 Trivial. See discussion in the BZ entry. Signed-off-by: Bernhard Walle <bwalle@xxxxxxx> --- defs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/defs.h +++ b/defs.h @@ -71,7 +71,7 @@ #define NR_CPUS (32) #endif #ifdef IA64 -#define NR_CPUS (1024) +#define NR_CPUS (16384) #endif #ifdef PPC64 #define NR_CPUS (128)
-- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
