----- Original Message -----
> On Fri, Feb 01, 2013 at 09:55:43AM -0500, Dave Anderson wrote:
> >
> >
> > ----- Original Message -----
> > >
> > > Dave, I have a development board you can borrow.
> > > It runs fedora 15 armv5tel.
> >
> > Thanks Luc, but it's not worth the travel effort that would take.
> >
> > And given that:
> >
> > (1) Nobody on this list can even find an ARM compressed
> > kdump, apparently kdump/makedumpfile usage is not
> > all that prevalent among ARM users. (?)
>
> We did use compressed kdumps back at Nokia and it worked pretty well. The
> problem is that I don't have any of those dumps available anymore.
>
> That being said, I do have ARM board where I think I can try to make such
> image but it takes some time to setup. If you like, I can try and make the
> resulting kdump image available to you.
>
> It is really needed at least on future ARM platforms. We did use it at Nokia
> and it saved lots of unnecessary disk/network space to preprocess it using
> makedumpfile.
>
> > (2) It's only required for "crash --osrelease dumpfile" and
> > the new "crash --log dumpfile" command line options, and
> > the workaround I'm putting in place works with these older
> > malformed headers.
> > (3) Atsushi Kumagai, the upstream makedumpfile maintainer,
> > is on this list and is aware of it,
> > (4) Eventually one of the ARM developers will probably look
> > into it...
>
> It is important and we should definitely make sure it is available for ARM
> developers. However, I'm working for Intel now so I don't have suitable
> development environment handy. If Jan, Per or Thomas doesn't have anything,
> I'll setup my old ARM (ep93xx board) and make a suitable compressed dump.
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
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
