Dave, 

I regenerate the vmcore dump file to make sure I used the correct version of dom0 which we have unstripped kernel from critix. 

The p2m_mfn pointer is still empty... :( I attached the output we have .. :( 

Too bad... It seems that I am going no where. 
Thanks for your help.

Yours
Kevin F. Li 

P.S.
I did cat /proc/iomem before I generate the vmcore dump.

it shows
9ead4000-9fb2cfff : System RAM
  9f700000-9f8dca7f : Hypervisor code and data
    9f899ca0-9f899e93 : Crash note
    9f899e94-9f89a027 : Crash note
    9f89a088-9f89a21b : Crash note
    9f89a27c-9f89a40f : Crash note

is this information  helpful to you ? 




On Wed, Sep 22, 2010 at 11:37 AM, Dave Anderson <anderson@redhat.com> wrote:

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

> Hey Dave and list,
>
>
> I am the guy who is try to open the 64 bit vmcore dump with 64 bit xen
> kernel and 32 bit dom0 kernel.
>
>
> Finally, I have received the dom0 kernel with symbols, and I tried to
> open the vmcore with crash (I patched with your "special patch").
>
>
> But I have a new problem, the crash utility exits with an error "could
> not read linux_banner string"
>
>
> <readmem: c034c000, KVADDR, "accessible check", 4, (ROE|Q), ffff82e4>
> addr: c034c000 paddr: 34c000 cnt: 4
> <readmem: c034c000, KVADDR, "readstring characters", 1499, (ROE|Q),
> ffff72d0>
> addr: c034c000 paddr: 34c000 cnt: 1499
> WARNING: cannot read linux_banner string
> linux_banner:
>
>
> crash32: boot/System.map-2.6.27.42-0.1.1.xs5.6.0.44.111158xen and
> vmcore-2010-09-15-19-29-03 do not match!
>
> Have you seen these error message before ? and Thanks for any help and
> suggestion.
>
>
> yours
> Kevin F LI
>
>
> ps.
> I attached the log file generated with "-d 31" option.

Looking at the attached log file, things are regressing even further
than what was shown in your original reports.  This time the vmcore
is not even being recognized as a Xen-generated core dump:

      ...
             page_size: 0
          switch_stack: 0
        xen_kdump_data: (unused)   <== this time
      num_prstatus_notes: 0
              vmcoreinfo: 0
         size_vmcoreinfo: 0
      nt_prstatus_percpu:
      ...

In your older post, it at least showed some xen_kdump_data:

       ...
             page_size: 0
          switch_stack: 0
        xen_kdump_data:
                   flags: 4 (KDUMP_MFN_LIST)
                 p2m_mfn: 0
                     cr3: 0
           last_mfn_read: ffffffff
           last_pmd_read: ffffffff
                    page: 0
                accesses: 0
              cache_hits: 0
              p2m_frames: 0
          xen_phys_start: 7db00000
       xen_major_version: 3
       xen_minor_version: 0
      p2m_mfn_frame_list: 0
      num_prstatus_notes: 4
              vmcoreinfo: 0
         size_vmcoreinfo: 0
      nt_prstatus_percpu:
       084c8e10 084c9004 084c9198 084c932c
      ...

That may be due to the use of a System.map file, which forces
the crash utility to take some short-cuts during initialization.
Or again, it could be a side issue of the lack of crash utility
support for 32-bit vmcores taken from 64-bit Xen hypervisors.

But since you've apparently got the debuginfo-full dom0 vmlinux
file, then there's not need to use the System.map file.   What
happens when you just run: "crash -d1 vmlinux vmcore"?

Dave


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility