>> First, just like some other contributors, I've come across an issue
>> triggered by a dump being corrupt. In my case it's this code in
>> kernel.c:cpu_maps_init():
>>
>> if (*maskptr & (0x1UL << c)) {
>> cpu = (i * BITS_PER_LONG) + c;
>> kt->cpu_flags[cpu] |= mapinfo[m].cpu_flag;
>> }
>>
>> The mask is corrupt, making Crash believe there are more CPU's than the
>> four we have allocated space for in kernel.c:kernel_init. How do you
>> think this should be handled?
>
> Does the "crash --cpus <number> ..." command-line option work around it?
>
Nope, setting "--cpus 2" I still arrive at the code above with
(gdb) p/x *maskptr
$3 = 0x540dcebf
(gdb)
As you can see, it's not really a valid cpu mask. Either that or I'm
totally deluded as to the capabilities of the hardware CPU-wise =o)
Regards,
Per
> Dave
>
> --
> Crash-utility mailing list
> Crash-utility@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/crash-utility
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
