This bug fixes the problem that on a 32 bit userland makedumpfile (as common on the PPC platform) the parsing of the 64 bit VMCOREINFO fails with:
# makedumpfile -c /home/sachin/dump/vmcore vmcore.filtered read_vmcoreinfo_symbol: Invalid data in /tmp/vmcoreinfowVoyJK: SYMBOL(mem_section)=c000000000bb4400 We just need to assume that the symbols are always 'unsigned long long' (64 bit) instead of 'unsigned long' (native pointer size on Linux platforms). Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]> --- makedumpfile.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/makedumpfile.c +++ b/makedumpfile.c @@ -2271,10 +2271,10 @@ read_vmcoreinfo_basic_info(void) return TRUE; } -unsigned long +unsigned long long read_vmcoreinfo_symbol(char *str_symbol) { - unsigned long symbol = NOT_FOUND_SYMBOL; + unsigned long long symbol = NOT_FOUND_SYMBOL; char buf[BUFSIZE_FGETS], *endp; unsigned int i; @@ -2291,8 +2291,8 @@ read_vmcoreinfo_symbol(char *str_symbol) if (buf[i - 1] == '\n') buf[i - 1] = '\0'; if (strncmp(buf, str_symbol, strlen(str_symbol)) == 0) { - symbol = strtoul(buf + strlen(str_symbol), &endp, 16); - if ((!symbol || symbol == ULONG_MAX) + symbol = strtoull(buf + strlen(str_symbol), &endp, 16); + if ((!symbol || symbol == ULONGLONG_MAX) || strlen(endp) != 0) { ERRMSG("Invalid data in %s: %s", info->name_vmcoreinfo, buf); _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec