Thanks Dave, <div><br></div><div>I tried the patch you attached in the previous email.</div><div><br></div><div>I am using the 32 bit crash utilities, and it seems to be able to load the vmcore (64bit). But</div><div><br></div> <div>I still have a problem, the physical address 0x7fed9050 was padding as 0x7fed9050000, and crash32 exited with error message </div><div><br></div><div><div><readmem: 7fed9050000, PHYSADDR, "xen kdump p2m mfn list page", 4096, (ROE), 894f538></div> <div> addr: 7fed9050000 paddr: 7fed9050000 cnt: 4096</div><div>crash32: read error: physical address: 7fed9050000 type: "xen kdump p2m mfn list page"</div></div><div><br></div><div><br></div><div>Yours</div> <div>Kevin F Li</div><div><br></div><div>ps.</div><div>The output of patched crash32</div><div><br></div><div><br></div><div><div><br></div><div>This GDB was configured as "i686-pc-linux-gnu"...</div><div>GETBUF(128 -> 0)</div> <div> GETBUF(1500 -> 1)</div><div><br></div><div> FREEBUF(1)</div><div>FREEBUF(0)</div><div><readmem: c034e720, KVADDR, "kernel_config_data", 32768, (ROE), 898e8e0></div><div> addr: c034e720 paddr: 34e720 cnt: 2272</div> <div>x86_xen_kdump_p2m_create: p2m_mfn: 0</div><div><readmem: 0, PHYSADDR, "xen kdump p2m mfn page", 4096, (ROE), 894f538></div><div> addr: 0 paddr: 0 cnt: 4096</div><div>00000000: 7fed9050 7fed904c 7fed9058 7fed9054</div> <div>00000010: 7fed9060 7fed905c f000859c f000ff53</div><div>00000020: f000fea5 f000e987 f0000c75 f0000c75</div><div>00000030: 99800b7c f0000c75 f000ef57 f000f545</div><div><br></div><div><readmem: 7fed9050000, PHYSADDR, "xen kdump p2m mfn list page", 4096, (ROE), 894f538></div> <div> addr: 7fed9050000 paddr: 7fed9050000 cnt: 4096</div><div>crash32: read error: physical address: 7fed9050000 type: "xen kdump p2m mfn list page"</div><div><br></div><div>crash32: cannot read xen kdump p2m mfn list page</div> <div><br></div><br><div class="gmail_quote">On Mon, Sep 13, 2010 at 9:02 AM, Dave Anderson <span dir="ltr"><<a href="mailto:anderson@redhat.com">anderson@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im"><br> ----- "Feng LI" <<a href="mailto:funglee@gmail.com">funglee@gmail.com</a>> wrote:<br> <br> > Thanks Dave,<br> ><br> </div><div class="im">> I had tried another combination: 32 bit Xen kernel with 32 bit Dom0<br> > kernel, but I have the similar issue. The vmcore file is still in 64<br> > bit format. (Our system has a large memory configuration 8GB-192GB),<br> > Is there any way I can generate elf32 vmcore file ?<br> ><br> <br> </div>OK, now I'm thinking mabye we've got a regression of some sort. The<br> bare-metal kdump procedure is designed to use the 64-bit vmcore format<br> all of the time because physical memory beyond the 4GB limit cannot<br> be referenced using the fields in a 32-bit vmcore header.<br> <br> However, you can configure 32-bit by modifying /etc/sysconfig/kdump here:<br> <br> # Example:<br> # KEXEC_ARGS="--elf32-core-headers"<br> KEXEC_ARGS=" --args-linux"<br> <br> by making KEXEC_ARGS=" --args-linux --elf32-core-headers"<br> <br> But before doing that, can you try applying the attached patch to<br> the crash utility?<br> <br> Thanks,<br> <font color="#888888"> Dave<br> </font><div><div></div><div class="h5"><br> <br> > Thanks.<br> ><br> ><br> > On Fri, Sep 10, 2010 at 5:03 PM, Dave Anderson < <a href="mailto:anderson@redhat.com">anderson@redhat.com</a> ><br> > wrote:<br> ><br> ><br> ><br> ><br> > ----- "Feng LI" < <a href="mailto:funglee@gmail.com">funglee@gmail.com</a> > wrote:<br> ><br> ><br> > > Thanks Dave.<br> > ><br> > > I attached the output of elfread -a with this email...<br> ><br> > Hmmm -- now that I think about it, it's seems that the crash<br> > utility has never supported dom0 vmcores generated from this<br> > type of Xen hypervisor/dom0 combination.<br> ><br> > Red Hat kernel versions come with the xen.gz and vmlinuz files<br> > packaged together, i.e., both 64-bit or both 32-bit:<br> ><br> > # rpm -qpl kernel-xen-2.6.18-219.el5.x86_64.rpm<br> > /boot/.vmlinuz-2.6.18-219.el5xen.hmac<br> > /boot/System.map-2.6.18-219.el5xen<br> > /boot/config-2.6.18-219.el5xen<br> > /boot/symvers-2.6.18-219.el5xen.gz<br> > /boot/vmlinuz-2.6.18-219.el5xen<br> > /boot/xen-syms-2.6.18-219.el5<br> > /boot/xen.gz-2.6.18-219.el5 <= 64-bit<br> > ...<br> ><br> > # rpm -qpl kernel-xen-2.6.18-219.el5.i686.rpm<br> > /boot/.vmlinuz-2.6.18-219.el5xen.hmac<br> > /boot/System.map-2.6.18-219.el5xen<br> > /boot/config-2.6.18-219.el5xen<br> > /boot/symvers-2.6.18-219.el5xen.gz<br> > /boot/vmlinuz-2.6.18-219.el5xen<br> > /boot/xen-syms-2.6.18-219.el5<br> > /boot/xen.gz-2.6.18-219.el5 <= 32-bit<br> > ...<br> ><br> > So, it's highly unlikely that either internally to Red Hat,<br> > or any of our customers, would ever run such a combination.<br> > And I don't recall ever working with the crash utility to<br> > support it.<br> ><br> > I'm curious whether anybody on this list has ever done this?<br> ><br> > After all these years of Xen existence, you would think that<br> > somebody else would have bumped into this anomoly before...<br> ><br> > Dave<br> ><br> ><br> ><br> ><br> > --<br> > Crash-utility mailing list<br> > <a href="mailto:Crash-utility@redhat.com">Crash-utility@redhat.com</a><br> > <a href="https://www.redhat.com/mailman/listinfo/crash-utility" target="_blank">https://www.redhat.com/mailman/listinfo/crash-utility</a><br> ><br> ><br> > --<br> > Crash-utility mailing list<br> > <a href="mailto:Crash-utility@redhat.com">Crash-utility@redhat.com</a><br> > <a href="https://www.redhat.com/mailman/listinfo/crash-utility" target="_blank">https://www.redhat.com/mailman/listinfo/crash-utility</a><br> </div></div><br>--<br> Crash-utility mailing list<br> <a href="mailto:Crash-utility@redhat.com">Crash-utility@redhat.com</a><br> <a href="https://www.redhat.com/mailman/listinfo/crash-utility" target="_blank">https://www.redhat.com/mailman/listinfo/crash-utility</a><br> <br></blockquote></div><br></div>