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

[Dave Anderson]

----- 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