[Crash-utility] dom0 analysis for IA64
Dave Anderson
anderson at redhat.com
Thu May 10 16:05:59 UTC 2007
Dave Anderson wrote:
> Dave Anderson wrote:
>
>> Itsuro ODA wrote:
>>
>> > Hi Dave,
>> >
>> > The attached patch enables to analyze dom0 linux from
>> > whole memory dump on IA64. (for crash-4.0-4.1)
>> > It is just quick hack.
>> > (I was asked from IA64 Xen developers and made it.)
>> >
>> > Each domain manages own machine memory by domain.arch.mm.pgd
>> > in IA64. It is 3-level page table.
>> > I thougnt the mfn of domain.arch.mm.pgd can be regarded as
>> > p2m_mfn.
>> >
>> > I intended to modify as less existent code as possible.
>> > But this patch is a bit tricky. And the memory usage is
>> > large if the machine memory layout is sparse.
>> > (maybe xen_kdump_p2m should be prepare for each arch ?)
>> >
>> > Would you consider to support dom0 analysis for IA64 ?
>> >
>> > I prepared two sample dumps. Please find from the following
>> > URLs.
>> >
>> > 1) http://people.valinux.co.jp/~oda/20070510-sample-dump-1.tar
>> > contents:
>> > - vmcore.gz
>> > This is taken by a hard assist dump. netdump style ELF vmcore.
>> > So XEN_ELFNOTE_CRASH_INFO does not exist.
>> > - vmcore.ka.gz
>> > It is coverted to kdump style and added XEN_ELFNOTE_CRASH_INFO
>> > manually.
>> > - vmlinux.debug.gz
>> > for dom0 analysis
>> > - xen-syms-2.6.18-8.el5.gz
>> > for xencrash
>> >
>> > To get p2m_mfn, xencrash's doms command is usefull.
>> > --------------------------------------------------------------------------
>> > # crash xen-syms-2.6.18-8.el5 vmcore
>> > ...
>> > crash> doms
>> > DID DOMAIN ST T MAXPAGE TOTPAGE VCPU SHARED_I P2M_MFN
>> > 32753 f000000007ac8080 RU O 0 0 0 0 ----
>> > 32754 f000000007acc080 RU X 0 0 0 0 ----
>> > > 32767 f000000007ff8080 RU I 0 0 4 0 ----
>> > 0 f000000007aa4080 RU 0 10000 fc28 1 f000000007a88000 1abb7
>> > >* 1 f000000007a78080 RU U 10603 10603 3 f000000007a5c000 1a909
>> > crash>
>> > ----------------------------------------------------------------------------
>> >
>> > Then normal crash session with --p2m_mfn option.
>> > ----------------------------------------------------------------------------
>> > # crash --p2m_mfn=1abb7 vmlinux.debug vmcore
>> >
>>
>> I'm still downloading the above, so I haven't been able
>> to test it yet...
>>
>> > ...
>> > ----------------------------------------------------------------------------
>> >
>> > vmcore.ka has XEN_ELFNOTE_CRASH_INFO. so --p2m_mfn option not need.
>> > ----------------------------------------------------------------------------
>> > # crash vmlinux.debug vmcore.ka
>> > ...
>> > ----------------------------------------------------------------------------
>> >
>> > --p2m_mfn option is effective only if a vmcore has XEN_ELFNOTE_CRASH_INFO
>> > now.
>> > I think specifying --p2m_mfn option is regarded as the vmcore is
>> > XEN_CORE_DUMPFILE(). The patch supports this.
>> > I think it is necessary for dumps which does not have
>> > XEN_ELFNOTE_CRASH_INFO such as above sample.
>> >
>> > 2) http://people.valinux.co.jp/~oda/20070510-sample-dump-2.tar
>> > contents:
>> > - vmcore.tiger.iomem_machine.gz
>> > taken by Xen kdump
>> > - vmlinux-xen-ia64.bz2
>> > - xen-syms-ia64.bz2
>> >
>> > I asked Xen kdump developper (simon at valinux) to add "p2m_mfn" to
>> > XEN_ELFNOTE_CRASH_INFO.
>> > So this change of Xen kdump is not open yet.
>> > If this is OK for crash, it will be commited.
>> >
>> > Thanks.
>> > --
>> > Itsuro ODA <oda at valinux.co.jp>
>> >
>>
>>
>> This all sounds good, and I agree that the p2m_mfn should
>> be added to the ia64 XEN_ELFNOTE_CRASH_INFO.
>>
>> However, there's something incorrect in your calculation of
>> "xkd->p2m_frames" in your ia64_xen_kdump_p2m_create() implementation.
>> It looks like it should be 32, but it's set to 524288. As a result
>> that wastes a lot of memory, and "help -n" is pretty much unusable
>> since wants to dump all ~512k entries:
>>
>> $ ./crash vmlinux-xen-ia64 vmcore.tiger.iomem_machine
>> ...
>> crash> help -n
>> ...
>> xen_kdump_data:
>> flags: 5 (KDUMP_P2M_INIT|KDUMP_MFN_LIST)
>> p2m_mfn: 1f62c
>> cr3: 0
>> last_mfn_read: 1fd09
>> page: 6000000000c96bd0
>> accesses: 1340
>> cache_hits: 1255 (95%)
>> p2m_frames: 524288
>> p2m_mfn_frame_list: 200000000539c010
>> 1efba 1f5cc 1fd09 1e185 1d984 1d183 1c982 1c181 1b980 1b17f 1a97e 1a17d 1997c 1917b 1897a 18179 17978 17177 16976
>> 16175 15974 15173 14972 14171 13970 1316f 1296e 1216d 1196c 1116b 1096a 10169 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0 0 0 0 0 0
>> 0 0 1efb8 1efb7 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 1efb6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0
>> 0 0 0 0 0 0 0
>>
>> If you enter "crash -d2", you'll also see all 512k, mostly useless,
>> entries...
>>
>
>
> Perhaps I am misunderstanding the reference you made with respect
> to the "machine memory layout is sparse"?
>
> In the other xen arches, the p2m_frame list reflects contiguous
> pseudo-physical memory, so I don't understand why, on your ia64
> sample dump which has 1GB of memory, that there would be more
> than 32 p2m frames?
>
> Each p2m frame would contain 2048 entries (given 16k pages).
> So with 32 p2m frames, that would account for 65536 pages,
> which equates to 1GB of pseudo-physical memory.
>
> Am I missing something?
>
> Dave
And finally...
I don't understand what check_netdump_xen() and check_kdump_xen()
are for. Both of them check whether "xen_kdump_data.p2m_mfn" has
been initialized, and if so, they to initialize several things
that should already have been initialized when xen_kdump_data.p2m_mfn
was originally set?
Are they ia64 only?
Or are they *only* necessary for the strange case where the
--p2m_mfn over-ride is used on that kludged-up netdump-to-kdump
vmcore? I still don't understand how that dumpfile was even
created -- should we even worry about that type of dumpfile
even existing?
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20070510/c6af7622/attachment.htm>
More information about the Crash-utility
mailing list