[Crash-utility] How to open 32 bit dom0 kdump....

[Dave Anderson]

----- "Feng LI" <funglee at gmail.com> wrote:

> Hey Dave,
> 
> I attached the crash -d1 output with this email...
> 
> Do you think whether anything wrong with my vmcore ?

I'm not sure...

The dom0 "p2m_mfn" value required by the crash utility is 
contained in the Xen XEN_ELFNOTE_CRASH_INFO note in the 
vmcore header.  That note contains this data structure,
as defined in "include/xen/elfcore.h" in the Xen hypervisor
source tree:
  
  typedef struct {
      unsigned long xen_major_version;
      unsigned long xen_minor_version;
      unsigned long xen_extra_version;
      unsigned long xen_changeset;
      unsigned long xen_compiler;
      unsigned long xen_compile_date;
      unsigned long xen_compile_time;
      unsigned long tainted;
  #ifdef CONFIG_X86
      unsigned long xen_phys_start;
      unsigned long dom0_pfn_to_mfn_frame_list_list;
  #endif
  } crash_xen_info_t; 

When a dom0 crashes, it goes through machine_crash_shutdown()
in the hypervisor's "arch/x86/crash.c" file, where it gets a 
pointer to the crash_xen_info structure, and then appends the
CONFIG_X86-only xen_phys_start and dom0_pfn_to_mfn_frame_list_list
fields: 
  
  void machine_crash_shutdown(void)
  {
      crash_xen_info_t *info;
  
      local_irq_disable();
  
      nmi_shootdown_cpus();
  
      disable_IO_APIC();
  
      hvm_disable();
  
      info = kexec_crash_save_info();
      info->xen_phys_start = xen_phys_start;
      info->dom0_pfn_to_mfn_frame_list_list =
          arch_get_pfn_to_mfn_frame_list_list(dom0);
  }

And then the crash utility reads the dom0_pfn_to_mfn_frame_list_list
value, and stores it in the "p2m_mfn" field that I referenced in the
last email.

Now, looking at your crash -d1 output, here's the XEN_ELFNOTE_CRASH_INFO,
where it should have picked up the bf969 as the p2m_mfn value:

Elf64_Nhdr:
               n_namesz: 4 ("Xen")
               n_descsz: 80
                 n_type: 1000001 (XEN_ELFNOTE_CRASH_INFO)
                         00000003 00000000 00000004 00000000 
                         d7beb409 00000000 d7bed168 00000000 
                         d7bed138 00000000 d7beb3c5 00000000 
                         d7beb3e2 00000000 00000000 00000000 
                         d7a00000 00000000 000bf969 00000000 
... [ snip ] ...

But it read it as a 0, as evidenced by the "p2m_mfn: 0" shown
below:

... [ snip ] ...

This GDB was configured as "i686-pc-linux-gnu"...

x86_xen_kdump_p2m_create: p2m_mfn: 0

... [ snip ] ...

In the meantime, I provisioned a RHEL5 32-bit x86 system with a 32-bit dom0,
and forced a crash.  As expected, it created a 64-bit ELF vmcore, which
does *not* display the "mismatch" warning message like yours does.  But more 
importantly, the XEN_ELFNOTE_CRASH_INFO dump on my vmcore looks like this,
where the p2m_mfn is 2c199:

Elf64_Nhdr:
               n_namesz: 4 ("Xen")
               n_descsz: 40
                 n_type: 1000001 (XEN_ELFNOTE_CRASH_INFO)
                         00000003 00000001 0018e97f 0018e98a 
                         00190120 0018e932 0018e94f 00000001 
                         00000000 0002c199

Note that the fields in your vmcore are 64-bit values, while those above
in the RHEL5 are 32-bit values.  That presumably is due to the fact that
you are running a 64-bit hypervisor?  (whereas my RHEL5 the hypervisor is
a 32-bit)  Are you *sure* that you are running a 32-bit hypervisor?

In any case, the p2m_mfn value in the vmcore header can be overridden
on the crash command line.  What happens if you enter:

  # crash vmlinux vmcore --p2m_mfn bf969

I'm guessing that you'll probably bump into yet another oddity, but it's
worth a shot...

Dave