----- "Bernhard Walle" <bernhard.walle@xxxxxx> 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@xxxxxxx) > > > > ... > > > > (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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
