Hi Dave,OK, I finally got these all downloaded. However, the xen-symsThe 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 xencrashTo 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
...
----------------------------------------------------------------------------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.
binary in the "sample-1" directory has no debug data:
# file xen-syms-2.6.18-8.el5
xen-syms-2.6.18-8.el5: ELF 64-bit LSB executable, IA-64, version
1 (SYSV), statically linked, stripped
#
And I see that check_netdump_xen() is only called if the
netdump (?) vmcore is used, since it needs the --p2m_mfn
argument. I have no idea where check_kdump_xen() would
apply?
In any case, I really prefer not to support whatever that
first "hard assist dump. netdump style ELF" vmcore file.
(What is that???)
I don't see why the support for dom0 ia64 kdumps should
be any different than for x86 and x86_64, both of which
have XEN_ELFNOTE_CRASH_INFO notes containing the p2m mfn
value.
Therefore, the check_netdump_xen() and check_kdump_xen()
can be thrown out, and all that is really required is the
implementation of ia64_xen_kdump_p2m_create() for the vmlinux
side. But it will still need a fix to deal with that
over-sized (?) 512k p2m_frame list. Can you look into fixing
that?
Also, I don't quite understand the changes to xen_kdump_p2m().
The first (generic) part is probably a safe thing to do:
+ if (mfn_idx >= xkd->p2m_frames)
+
return P2M_FAILURE;
But if the above code is put into place, how would it
be possible for the resultant mfn_frame to be 0?
+ #ifdef IA64
+ if (mfn_frame
== 0)
+
return P2M_FAILURE;
+ #endif
And I don't understand this part at all:
+ #ifdef IA64
+ if (!(*mfnptr
& 0x1))
+
return P2M_FAILURE;
+ paddr = *mfnptr
& _PFN_MASK;
+ #else
+ paddr = (physaddr_t)PTOB((ulonglong)(*mfnptr));
+ #endif
Although, after putting in a debug printf of what the mfns
actually look like on an ia64, I guess I see why it's
necessary.
On x86 and x86_64, the mfnptr points to a simple mfn value.
But on the ia64, I see mfns that look like 81000007bf3c761,
where the "1-bit" is always set. And you don't shift the
mfn value like x86/x86_64 do. Can you help me understand
the format of the ia64 mfns? In other words, what part of
a
value such as 81000007bf3c761 is the actual mfn? Are there
page flags or something in the lower bits of the number?
Thanks,
Dave
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.bz2I asked Xen kdump developper (simon@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@xxxxxxxxxxxxx>------------------------------------------------------------------------------------------------------------------------
Name: diff-20070510
diff-20070510 Type: unspecified type (application/octet-stream)
Encoding: base64------------------------------------------------------------------------------------------------------------------------
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
-- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
