This is a backport of commit bcdba92 ("[PATCH v5] Support to filter dump
for kernels that use CONFIG_SPARSEMEM_VMEMMAP."):
commit bcdba92
Author: Hari Bathini <hbathini@linux.vnet.ibm.com>
Date: Mon Nov 25 17:20:55 2013 +0900
[PATCH v5] Support to filter dump for kernels that use CONFIG_SPARSEMEM_VMEMMAP.
Makedumpfile tool fails to filter dump for kernels that are build with
CONFIG_SPARSEMEM_VMEMMAP set, as it fails to do address translations
for vmemmap regions that are mapped out of zone normal. This patch
provides support in makedumpfile to do vmemmap to physical address
translations when they are mapped outside zone normal. Some kernel
symbols are needed in vmcoreinfo for this changes to be effective.
The kernel patch that adds the necessary symbols to vmcoreinfo has
been posted to linuxppc devel mailing list. This patch is influenced
by vmemmap to physical address translation support code in crash tool.
This patch has been tested successfully at all dump filtering levels
on kernels with CONFIG_SPARSEMEM_VMEMMAP set/unset. Also, tested dump
filtering on already filtered vmcores (re-filtering).
Changes from v4 to v5:
Trimmed patch description to be compact and readable.
Changes from v3 to v4:
Rebased to devel branch.
Signed-off-by: Onkar N Mahajan <onmahaja@in.ibm.com>
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
On PPC platform, filter facility is broken since we use
CONFIG_SPARSEMEM_VMEMMAP. This patch fixes this issue but also needs kernel
counterpart fix to get makedumpfile filter working.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Steve Best<sbest@redhat.com>
This is a backport of commit a01b663 ("[PATCH v2] dump-dmesg: Understand
>= v3.11-rc4 dmesg."):
commit a01b663
Author: Lubomir Rintel <lkundrak@v3.sk>
Date: Fri Sep 20 15:56:49 2013 +0900
[PATCH v2] dump-dmesg: Understand >= v3.11-rc4 dmesg.
Symbol name changed with the following commit:
62e32ac printk: rename struct log to struct printk_log
Changes for v2:
* Only back values for symbol names we did actually read;
* either "log" or "printk_log"
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
makedumpfile --dump-dmesg is broken since VMCOREINFO symbol "log" has
renamed to "printk_log". This patch fixes --dump-dmesg on 3.11 kernel.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
There's a kernel bug for mapping mem ranges which end with
an address not aligned to page boundry. It's still not resolved
in upstream, so let's disable mmap read for now as a workaround.
Once upstream got a right fix we can revert this patch.
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Description of Problem:
This is a REGRESSION issue.
At fedora makedumpfile has been updated toward v1.5.4. Unfortunately,
this version fails calculating phys_base on sadump format and then
fails converting vmcore.
x86_64 kernel is relocatable kernel and there can be a gap between
the physical address statically assigned to kernel data and texts
and the address that is really assigned to each object corresponding
to the kernel symbols. The gap is phys_base. makedump calculates the
phys_base in an ad-hoc way that comparing the addresses of some of
occurrences of "Linux kernel" strings in certain range of vmcore.
Resolution:
Fix patch has already been posted in upstream. so just back port.
The commit ID are:
commit e23dc0a1aa5fa7a4429f72ff1c2fe87a87291065
commit 92563d7a7a5175ef78c4a94ee269b1b455331b4c
Signed-off-by: arthur <zzou@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Boot with "crashkernel=128M,high", kernel now uses "Crash kernel" in
/proc/iomem for crash kernel memory reservations at both low and high:
commit 157752d
Author: Yinghai Lu <yinghai@kernel.org>
kexec: use Crash kernel for Crash kernel low
But kexec is still scanning for "Crash kernel low" in /proc/iomem, and
will fail immediately when load/unload crash kernel.
So let's pull the following commit from kexec upstream to make
it compatible with our kernel:
commit e25e6e7
Author: Yinghai Lu <yinghai@kernel.org>
kdump, x86: Process multiple Crash kernel in /proc/iomem
(This patch from upstream is untouched and can be applied cleanly)
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Description of Problem:
In cyclic mode, makedumpfile recalculates cyclic buffer size as the
largest multiple of the largest block size managed by buddy
allocator, i.e. 4MB, smaller than the cyclic buffer size in order to
enable to process each unit of blocks managed by buddy allocator in
each cycle.
However, makedumpfile does two wrong things in the recalculations:
1) While updating size of cyclic buffer, makedumpfile doesn't update
length of range of cycle in page frame numbers, due to which, if
cyclic buffer size is updated, because cyclic buffer size is always
reduced during udpate, some buffer overrun can happen on the cyclic
buffer. This can cause segmentation violation in the worst case.
2) roundup() is used to calculate bitmap size for maximum block size
managed by buddy allocator, here divideup() is correct, due to
which, although memory filtering is not affected, cyclic buffer size
get too much aligned and less efficient.
Fix patches has already been posted and merged in makedumpfile
development devel branch.
git://git.code.sf.net/p/makedumpfile/code
f8c8218856effc43ea01cd9394761cfb8aeaa8df
a785fa7dd7a7bd7dcbb017d0bea8848243b0924f
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: WANG Chao <chaowang@redhat.com>
The dumpfile header has this field, which was inherited from
the old "diskdump" facility:
struct disk_dump_header {
...
unsigned int max_mapnr; /* = max_mapnr */
...
and which, among other things, is used by the crash utility as a
delimiter to determine whether a physical address read request is
legitimate. And obviously the field cannot handle PFN values greater
than 32-bits.
The makedumpfile source code does have its own max_mapnr representation
in its DumpInfo structure in "makedumpfile.h":
struct DumpInfo {
...
unsigned long long max_mapnr; /* number of page descriptor */
...
But in its "diskdump_mod.h" file, it carries forward the old diskdump
header format, which has the 32-bit field:
struct disk_dump_header {
...
unsigned int max_mapnr; /* = max_mapnr */
...
And here in "makedumpfile.c", the inadvertent truncation occurs
when the PFN is greater than 32-bits:
int
write_kdump_header(void)
{
...
dh->max_mapnr = info->max_mapnr;
...
Now upstream has below commit to fix this, back port it:
commit 8e124174b62376b17ac909bc68622ef07bde6840
Author: Jingbai Ma <jingbai.ma@hp.com>
Date: Fri Oct 18 18:53:38 2013 +0900
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: WANG Chao <chaowang@redhat.com>
In 2.0.4, Cliff from HP posted 2 patches:
e35aa29 kexec: include reserved e820 sections in crash kernel
4932034 kexec: lengthen the kernel command line image
However, with both of them kdump kernel may fail to boot, and
are useless because of restriction in kernel side. In upstream,
they have been reverted. Now back port these 2 revert commits.
Also since the commit 1a4e90b has dependency, back port commit
dc607e4 which is depended on by commit 1a4e90b too.
1a4e90b Revert "kexec: include reserved e820 sections in crash kernel"
dc607e4 kexec: i386: Add cmdline_add_memmap_internal() to reduce the code duplication
8274916 Revert: "kexec: lengthen the kernel command line image"
Currently in the whole kdump framework, we have some common functions
used across not only mkdumprd context and dracut context, but also 1st
kernel and 2nd kernel. We defined these functions at each script, which
is obviously not decent.
So let's introduce kdump-lib.sh for the shared functions and put it
to /lib/kdump/kdump-lib.sh.
It starts small, as you can see, only 3 functions are extracted. But in
the future more and more common functions can be added.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Build on ppc/ppc64 failed after makedumpfile-1.5.4 is pulled, since the
variable vmap_area_list is not defined. Back port below commit from
upstream to add it.
commit 150b58eb299066c65ef7713a93effc35c00be03a
Author: Baoquan He <bhe@redhat.com>
Date: Mon Jul 15 20:37:14 2013 +0800
[PATCH] Add vmap_area_list definition for ppc/ppc64.
vmap_area_list is added to get vmalloc_start for ppc/ppc64, but its
definition is missing, now add them.
Signed-off-by: Baoquan He <bhe@redhat.com>
Percent signs in .spec files get expanded as macros. Currently in kexec-tools.spec,
'%{dist}' are appended to changelog item. This older changelog is not correctly for
rhel7 with this. Let's remove it to make it clearer.
Fedora 18 changes the way how to work with services in spec files.
It introduces new macros - %systemd_post, %systemd_preun and
%systemd_postun. These macros are functionally equivalent to the
manual scriptlets used in older versions of Fedora.
By using the new unified RPM macros the .spec file code is
simplified a lot.
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: WANG Chao <chaowang@redhat.com>
Currenty the kexec-tools package contains udev rules for kdump
that reload kdump in case of memory or CPU hotplug:
$ cat /etc/udev/rules.d/98-kexec.rules
SUBSYSTESUBSYSTEM=="cpu", ACTION=="online", PROGRAM="/bin/systemctl try-restart kdump.service"
SUBSYSTEM=="cpu", ACTION=="offline", PROGRAM="/bin/systemctl try-restart kdump.service"
SUBSYSTEM=="memory", ACTION=="add", PROGRAM="/bin/systemctl try-restart kdump.service"
SUBSYSTEM=="memory", ACTION=="remove", PROGRAM="/bin/systemctl try-restart kdump.service"
On other architectures the rules are necessary because the memory
and CPU layout stored in the kdump in-memory ELF header at kdump
load time. Therefore the kdump kernel has to be reloaded each
time when the CPU or memory configuration changes.
This has drawbacks:
1. During kdump reload the system can't be dumped.
2. On systems with many hotplug events (e.g. on s390 with cpuplugd)
this creates significant overhead
The reload is not necessary on s390 because there the ELF header is
created in the 2nd (kdump) kernel. Therefore, to improve things,
remove the rules for s390.
Log is from IBM, and patch has been tested by IBM and work well.
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
commit 97e107b "Add support for team devices" introduced ethtool to
get permanent address.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
cked-by: Dave Young <dyoung@redhat.com>
Below patches were applied to kexec-tools-2.0.3, the latest
kexec-tools-2.0.4 has included them. Delete them here.
kexec-tools-2.0.3-Load-bzImages-smaller-than-32-KiB.patch
kexec-tools-2.0.3-kdump-pass-acpi_rsdp-to-2nd-kernel-for-efi-booting.patch
kexec-tools-2.0.3-ppc-exec-stack-fix.patch
kexec-tools-2.0.3-ppc-ppc64-compile-purgatory-code-with-gcc-option-msoft-float.patch
kexec-tools-2.0.3-vmcore-dmesg-Do-not-write-beyond-end-of-buffer.patch
kexec-tools-2.0.3-vmcore-dmesg-vmcore-dmesg-Make-it-work-with-new-stru.patch
Because makedumpfile is not supported on ppc and s390, so it makes
no sense to create the eppic_makedumpfile sub-package if there is
no makedumpfile binary to run it with.
Remove eppic contents related to ppc and s390 in kexec-tools.spec. This
will not build and install eppic on ppc and s390.
There's one mistake in rules related to eppic in kexec-tools.spec,
that caused kexec-tools-eppic to fail installation of i386. In this
patch remove that line of rule.
Meanwhile update eppic_030413.tar.gz.
This feature enables us to specify rules to scrub data in a
dumpfile with eppic macro instead of the current configuration
file (makedumpfile.conf). Currently, this feature works only
for symbols in vmlinux while the current feature can work also
for module symbols.
This library is backported from upstream, integrated and tested by
Dave Anderson.
This reverts commit 05b67ee95c.
The old commit was merged for a emergent bug fixing on release 1.5.1
of makedumpfile. Now the upstream has been updated to v1.5.3, and this
patch has been included already.
For updating to makedumpfile v1.5.3, revert it.
This reverts commit 05b67ee95c.
The old commit was merged for a emergent bug fixing on release 1.5.1
of makedumpfile. Now the upstream has been updated to v1.5.2, and this
patch has been included already.
For updating to makedumpfile v1.5.2, revert it.
WANG Chao
Dave Young
arthur
Baoquan He