----- "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