----- "Bernhard Walle" <bernhard.walle(a)gmx.de> wrote:
 Dave Anderson schrieb:
 >>
 >> As we know, on x86(32 bits), uint32_t is 4 bytes and uint64_t is 8
 >> bytes. 
 >>
 >> So this line
 >>    140          nr_cpus = (hdr_size - offset) / sizeof(dump_CPU_info_t);
 >>
 >> would not get a correct nr_cpus due to the sizeof().
 >>
 >> A patch to fix this problem as below.
 > 
 > BTW, what exactly are the ramifications without the patch -- does the
 > crash session die during initialization?  How come nobody ran into 
 > this issue given that the code has been in place for almost 2 years?
  
 > 
 > 4.0-4.8  - ... 
 > 
 >          - Change for support of LKCD dumpfile version 8 and later to determine
 >            the backtrace starting registers from the dumpfile header.  Increase
 >            (maximum) NR_CPUS for ia64 to 4096.
 >            (bwalle(a)suse.de)
 > 
 >            ...
 > 
 >            (10/30/07)
 > 
 > Anyway, the patch looks reasonable to me, but I don't touch the LKCD
 > code without a sign-off from the LKCD maintainers on this mailing list.
 > 
 > LKCD maintainers -- do you have any objection to this patch?
 
 Sorry for that mistake, it was me. :-(
 
 It's a copy & paste error (the members are just copied from the
 dump_header_asm_t definition above. And I acknowledge the patch (from
 reading it, I have no test material here any more). Troy may give the
 ultimate acknowledge. ;-)
 
 Regards,
 Bernhard 
Good, thanks Bernhard -- it looked pretty obvious, and I'll put it in.  
I still wish the guy had indicated exactly what the failure mode was.
It looks like, at a minimum, there could be one or two LKCD-specific
warning messages during initialization, but the crash session should
still come up, right?  Given that "nr_cpus" is a local variable and
has nothing to do with crash utility's determination of how many cpus 
there are, I wonder what other problems might arise? 
Dave