On Thursday, January 31, 2013, Dave Anderson wrote:

----- Original Message -----
> On Wed, Jan 30, 2013 at 05:30:22PM -0500, Dave Anderson wrote:
> > I'm wondering whether that's the case with all ARM compressed
> > kdump files? Or maybe the dumps I have were created during early
> > development of ARM kexec/kdump? Or is it a bug with the
> > makedumpfile facility on ARM?
>
> I would expect a bug in the makedumpfile (since I wrote the ARM support there
> originally ;-))

Which is kind of strange, since the makedumpfile code that does the
compressed kdump creation from the ELF vmcore looks to be common to
all arches. And if the original ARM /proc/vmcore was created incorrectly,
then crash would seemingly have a problem pulling out the vmcoreinfo
data from an ARM ELF kdump -- but it works just fine with those.

I don't have any kind of ARM development environment in which to
debug makedumpfile. So for now I'm going to put a horrific ARM-only
kludge in the crash utility to look for the "OSRELEASE=xxx" string in
the kdump sub_header block, and assign the size_vmcoreinfo and
offset_vmcoreinfo values by hand. The "VMCOREINFO" string itself,
which is in the ELF note header just prior to the actual data, is
also missing. Weird...

>
> > So my question is, do any of you have an ARM compressed kdump that
> > you can verify has its "offset_vmcoreinfo" and "size_vmcoreinfo"
> > fields set?
>
> Unfortunately my sample dumps (except few) were lost when I left Nokia and
> those that I still have are not compressed, it seems.

OK thanks -- Per doesn't have any either, so maybe Jan does?

Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility