[Crash-utility] How to open 32 bit dom0 kdump....

[LI, Feng]

Thanks Dave,

I tried the patch you attached in the previous email.

I am using the 32 bit crash utilities, and it seems to be able to load the
vmcore (64bit). But

I still have a problem, the physical address 0x7fed9050 was padding as
0x7fed9050000, and crash32 exited with error message

<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"


Yours
Kevin F Li

ps.
The output of patched crash32



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 at redhat.com> wrote:

>
> ----- "Feng LI" <funglee at 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 at redhat.com >
> > wrote:
> >
> >
> >
> >
> > ----- "Feng LI" < funglee at 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 at redhat.com
> > https://www.redhat.com/mailman/listinfo/crash-utility
> >
> >
> > --
> > Crash-utility mailing list
> > Crash-utility at redhat.com
> > https://www.redhat.com/mailman/listinfo/crash-utility
>
> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20100913/b819663e/attachment.htm>