Re: [Xen-devel] RE: Coredumps and 'crash' utility...

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

[I'll continue this on-list rather than privately like I normally ould
for XE realted questions since it seems the issue is more general than
the fact that you happen to be using XenEnterprise]

On Tue, 2007-10-09 at 20:02 -0400, Roger Cruz wrote: 
> >First, you won't get anywhere with the vmlinuz file; you must 
> >use the kernel's vmlinux file, which must have been built with -g.
> 
> I have confirmed that the domain 0 vmlinux file is compiled with the -g
> switch so the symbol info should be there.  It's also not obvious from
> my post because I didn't rename the file, but the vmlinuz is the
> uncompressed version of the XenSource-provided Domain 0 kernel.

The installed image will have been stripped so you might need to get the
unstripped vmlinux file from our DDK.

> #readelf  -a /proc/vmcore
> readelf: Error: Could not locate '/proc/vmcore'.  System error
> message:
> Value too large for defined data type

If I remember correctly /proc/vmcore is always an ELFCLASS64 file since
it must contain physical addresses which can be >4G even on 32 bit
(PAE). The e_machine field in the ELF header will be EM_386 or EM_X86_64
depending on the hypervisor (not the kernel or userspace).

I have generally found the binutils readelf to not be that great,
especially when faced with ELFCLASS* files which don't match your
userspace. The readelf from elfutils is better in this regard.

In any case I don't think your problems stem from the format of vmcore
-- I am pretty sure it is correct. More likely the version of the tools
you are trying to use cannot cope with the 64 bit-ness, probably because
they were compiled/are running in a 32 bit userspace environment or they
are otherwise confused due to the 32on64 configuration of XE.

> The host machine is an x86_64.  I've been told that the hypervisor
> supports 64-bits and that domain 0 is 32-bits but I'm not 100%.

If you were using pristine XenEnterprise v4 then this would be correct,
however the log you provided shows that your modified hypervisor is
actually 32 bit: 
        (XEN) *** LOADING DOMAIN 0 ***
        (XEN)  Xen  kernel: 32-bit, PAE, lsb
        (XEN)  Dom0 kernel: 32-bit, PAE, lsb, paddr 0xc0100000 -> 0xc0440000

> I don't know with 100% certainty.  It is created with kdump but I don't
> know if they've modified the file format.  

I don't think we did, certainly not on purpose ;-). We made a change to
get the e_machine field in the ELF header to be correct (i.e. match the
hypervisor not the kernel) in a 32on64 bit world, that shouldn't have
broken anything 32on32 though and the patch is upstream.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel