(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 <cpw at sgi.com> >>> >>> >>> 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
