Re: [Crash-utility] Question for ARM developers/users w/respect to makedumpfile

----- Original Message ----- Yeah, I'm just interested in whether the malformed kdump_sub_headers still occur with later versions of makedumpfile (header version 5). About as far as I've taken it is to play with the kdump_sub_header structure, cast it to the block read from the dumpfile, and then display it. And if I do the following, both the "offset_vmcoreinfo" and the "size_vmcoreinfo" field values become "correct": struct kdump_sub_header_XXX { unsigned long phys_base; int dump_level; /* header_version 1 and later */ // int split; /* header_version 2 and later */ // unsigned long start_pfn; /* header_version 2 and later */ // unsigned long end_pfn; /* header_version 2 and later */ unsigned long junk1; unsigned long junk2; unsigned long junk3; unsigned long junk4; off_t offset_vmcoreinfo; /* header_version 3 and later */ unsigned long size_vmcoreinfo; /* header_version 3 and later */ off_t offset_note; /* header_version 4 and later */ unsigned long size_note; /* header_version 4 and later */ off_t offset_eraseinfo; /* header_version 5 and later */ unsigned long size_eraseinfo; /* header_version 5 and later */ } So their locations are "off" by 4 bytes, i.e., the size of junk4, since the split, start_pfn and end_pfn fields match up with junk1, junk2 and junk3. But the the ELF note header data that precedes the actual vmcoreinfo string data, which contains the "VMCOREINFO" string, was never copied to the dumpfile. And because the makedumpfile code that does all that stuff is arch-independent, it's a mystery... Thanks, Dave