WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

[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