[Crash-utility] [help]crash can't anaylyse xen guest paravirtulized linux vmcore

[hu jun]

SLES11:/opt/kdump # nm -Bn vmlinux | grep -e ffffffff806f7360 -e ffffffff80674690
ffffffff80674690 B phys_to_machine_mapping
ffffffff806f7360 B max_pfn

ffffffff806f7360 should   be "end_pfn" or "max_pfn", you are right!



> Date: Wed, 26 Oct 2011 11:54:42 -0400
> From: anderson at redhat.com
> To: crash-utility at redhat.com
> Subject: Re: [Crash-utility] [help]crash can't anaylyse xen guest	paravirtulized linux vmcore
> 
> 
> 
> ----- Original Message -----
> > 
> > 
> > ----- Original Message -----
> > > 
> > > 
> > > SLES11:/opt/tar_rpm/crash-5.1.9 # ./crash -d8 /opt/kdump/vmlinux
> > > /opt/kdump/sles11_1.mem > /tmp/crash_output3
> > > 
> > > 
> > > output see attachement.
> > > 
> > > 
> > > 
> > > Thank your response.
> > 
> > It's been a long time since I've looked at the particulars of a Xen dumpfile
> > given that Red Hat has discontinued Xen for KVM, so I'm a bit rusty.  In any
> > case, upon the first memory read, while trying to walk through the page table
> > data to resolve a kernel virtual address, it comes to a dead end.  I have no
> > idea why, nor do I have any further suggestions.
> > 
> > Can the SLES-qualified members of the list confirm that "xm dump" still creates
> > dumpfiles that crash can handle?
> > 
> > Dave
> 
> FWIW, it's actually making the second kernel virtual address read:
> 
>   $ grep pgd: crash_output3
>   [ffffffff806f7360] pgd: 9af04067  mfn: 9af04  pgd_index: 1fe
>   [ffffffff80674690] pgd: 9af04067  mfn: 9af04  pgd_index: 1fe
>   $
> 
> where, depending upon the kernel version, ffffffff806f7360 should
> be "end_pfn" or "max_pfn".  It ended up resolving that first virtual
> address to a page table and page, but the data there doesn't make sense:
> 
>   $ grep "end pfn:" crash_output3
>   end pfn: 0
>   $
> 
> So even though it appeared to work OK, it's apparently bogus.
> 
> Then I believe that the second virtual address of ffffffff80674690
> should be "p2m_top", and while trying to walk the page tables for 
> that virtual address, it failed.
> 
> If you do this:
> 
>   $ nm -Bn vmlinux | grep -e ffffffff806f7360 -e ffffffff80674690
> 
> you can at least verify that.  But unfortunately it doesn't really
> help understand what's happening.
> 
> Dave
> 
> --
> 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/20111026/0f1f6e5d/attachment.htm>