This GDB was configured as "i686-pc-linux-gnu"...

GETBUF(128 -> 0)

GETBUF(1500 -> 1)

FREEBUF(1)

FREEBUF(0)

<readmem: c034e720, KVADDR, "kernel_config_data", 32768, (ROE), 898e8e0>

addr: c034e720 paddr: 34e720 cnt: 2272

x86_xen_kdump_p2m_create: p2m_mfn: 0

<readmem: 0, PHYSADDR, "xen kdump p2m mfn page", 4096, (ROE), 894f538>

addr: 0 paddr: 0 cnt: 4096

00000000: 7fed9050 7fed904c 7fed9058 7fed9054

00000010: 7fed9060 7fed905c f000859c f000ff53

00000020: f000fea5 f000e987 f0000c75 f0000c75

00000030: 99800b7c f0000c75 f000ef57 f000f545

<readmem: 7fed9050000, PHYSADDR, "xen kdump p2m mfn list page", 4096, (ROE), 894f538>

addr: 7fed9050000 paddr: 7fed9050000 cnt: 4096

crash32: read error: physical address: 7fed9050000 type: "xen kdump p2m mfn list page"

crash32: cannot read xen kdump p2m mfn list page

On Mon, Sep 13, 2010 at 9:02 AM, Dave Anderson <anderson@redhat.com> wrote:

----- "Feng LI" <funglee@gmail.com> wrote:

> Thanks Dave,
>

> I had tried another combination: 32 bit Xen kernel with 32 bit Dom0
> kernel, but I have the similar issue. The vmcore file is still in 64
> bit format. (Our system has a large memory configuration 8GB-192GB),
> Is there any way I can generate elf32 vmcore file ?
>

OK, now I'm thinking mabye we've got a regression of some sort. The
bare-metal kdump procedure is designed to use the 64-bit vmcore format
all of the time because physical memory beyond the 4GB limit cannot
be referenced using the fields in a 32-bit vmcore header.

However, you can configure 32-bit by modifying /etc/sysconfig/kdump here:

# Example:
# KEXEC_ARGS="--elf32-core-headers"
KEXEC_ARGS=" --args-linux"

by making KEXEC_ARGS=" --args-linux --elf32-core-headers"

But before doing that, can you try applying the attached patch to
the crash utility?

Thanks,
Dave

> Thanks.
>
>
> On Fri, Sep 10, 2010 at 5:03 PM, Dave Anderson < anderson@redhat.com >
> wrote:
>
>
>
>
> ----- "Feng LI" < funglee@gmail.com > wrote:
>
>
> > Thanks Dave.
> >
> > I attached the output of elfread -a with this email...
>
> Hmmm -- now that I think about it, it's seems that the crash
> utility has never supported dom0 vmcores generated from this
> type of Xen hypervisor/dom0 combination.
>
> Red Hat kernel versions come with the xen.gz and vmlinuz files
> packaged together, i.e., both 64-bit or both 32-bit:
>
> # rpm -qpl kernel-xen-2.6.18-219.el5.x86_64.rpm
> /boot/.vmlinuz-2.6.18-219.el5xen.hmac
> /boot/System.map-2.6.18-219.el5xen
> /boot/config-2.6.18-219.el5xen
> /boot/symvers-2.6.18-219.el5xen.gz
> /boot/vmlinuz-2.6.18-219.el5xen
> /boot/xen-syms-2.6.18-219.el5
> /boot/xen.gz-2.6.18-219.el5 <= 64-bit
> ...
>
> # rpm -qpl kernel-xen-2.6.18-219.el5.i686.rpm
> /boot/.vmlinuz-2.6.18-219.el5xen.hmac
> /boot/System.map-2.6.18-219.el5xen
> /boot/config-2.6.18-219.el5xen
> /boot/symvers-2.6.18-219.el5xen.gz
> /boot/vmlinuz-2.6.18-219.el5xen
> /boot/xen-syms-2.6.18-219.el5
> /boot/xen.gz-2.6.18-219.el5 <= 32-bit
> ...
>
> So, it's highly unlikely that either internally to Red Hat,
> or any of our customers, would ever run such a combination.
> And I don't recall ever working with the crash utility to
> support it.
>
> I'm curious whether anybody on this list has ever done this?
>
> After all these years of Xen existence, you would think that
> somebody else would have bumped into this anomoly before...
>
> Dave
>
>
>
>
> --
> Crash-utility mailing list
> Crash-utility@redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
>
> --
> Crash-utility mailing list
> Crash-utility@redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility

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