----- "Feng LI" <funglee@xxxxxxxxx> 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@xxxxxxxxxx > > wrote: > > > > > ----- "Feng LI" < funglee@xxxxxxxxx > 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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/crash-utility > > > -- > Crash-utility mailing list > Crash-utility@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/crash-utility
--- crash-5.0.7/tools.c.orig +++ crash-5.0.7/tools.c @@ -4671,7 +4671,7 @@ machine_type_mismatch(char *file, char * return FALSE; if (query == KDUMP_LOCAL) /* already printed by NETDUMP_LOCAL */ - return TRUE; + return FALSE; error(WARNING, "machine type mismatch:\n"); @@ -4679,7 +4679,7 @@ machine_type_mismatch(char *file, char * fprintf(fp, " %s: %s%s%s\n\n", file, e_machine, alt ? " or " : "", alt ? alt : ""); - return TRUE; + return FALSE; } void command_not_supported()
-- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
