(2013/09/04 3:48), Cliff Wickman wrote:
On Fri, Aug 30, 2013 at 10:11:09AM +0900, HATAYAMA Daisuke wrote:
(2013/08/29 7:08), Cliff Wickman wrote:
From: Cliff Wickman <[email protected]>
makedumpfile needs the debug info from either /proc/vmcore or in vmlinux
to know how to find free pages using the buddy method.
The distro procedures do not pass the vmlinux (with the -x option), so
add a search for a debug vmlinux in the usual locations.
It's not needed if the page info is in vmcore. But warn if it is found
in neither place.
makedumpfile is designed to get necessary debug information from VMCOREINFO note
available from /proc/vmcore. Why do you need vmlinux?
The vmcore doesn't always provide the page structure information.
Specifically, the offset of 'private' and '_mapcount' in the page
structure, which are needed for identification of user huge pages.
(I've seen this to be true on a sles11s2 and rhel65 (3.0.80 2.6.32-410))
I'm using the huge page patch from Petr Tesarik. The one that I think you
said Kumagai-san is reworking.
I don't know your situation in each distribution, but simply, you should post
patch to distribution sides, not upstream makedumpfile. Try to extend
VMCOREINFO in
kernels or add the workaround of this patch series in makedumpfile on each
distributions.
Also, I think automatic search is not absolutely necessary. It's enough to
specify vmlinux path manually in configuration file. Using vmlinux file itself
is
possible without any problem. This workaround doesn't need makedumpfile change.
If you still want automatic search, it's enough to prepare a script that does
that
and add it to initramfs by extra_bins directive and then specify it in
core_collector
directive. This is way on RHEL. I don't way on SLES, but it's SLES issue.
I did improve my patch, as provided below.
The below version does not try to replace the debuginfo from vmcore, but
only to extract the few bits of page structure information needed for
the Tesarik patch.
You may not see the need for the additional (page) info on current kernels.
So I understand that you may not be interested in this patch, as it may
not be needed for kernels that are current when the huge page
identification patch is ready.
-Cliff
kdump framework is designed carefully, primarily focusing on how to keep
reliability. Not assuming root device in the 2nd kernel is one of them.
Keeping reliability is more important. We should not break that by this kind of
workaround.
--
Thanks.
HATAYAMA, Daisuke
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
