This is a backport of the following upstream commit:
commit 158d763
Author: WANG Chao <chaowang@redhat.com>
Date: Tue Jan 7 01:37:34 2014 +0800
vmcore-dmesg: struct_val_u64() not casting u64 to u32
It seems gcc doesn't check return type from inline function.
struct_val_u64() should return u64 otherwise upper 32bit is lost.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
timestamp in vmcore-dmesg is u64 type but it's truncated to u32, which
results in wrong time stamp. So let's backport this patch to fix this
issue.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
This is a backport of the following upstream commit:
commit 7c770ed
Author: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
Date: Thu Dec 12 16:40:31 2013 +0900
[PATCH] Fall back to read() when mmap() fails.
This is a fall back path for mmap().
This patch disables mmap() when facing the issues related to mmap(),
and read() will be used to read vmcore instead.
Signed-off-by: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
mmap() file operation on vmcore is working properly when the page being
accessed has different attributes on different part (ie. two different type
of memory ranges are overlapping).
A fall back mechanism is introduced in this patch, in case mmap() fails,
switch to read() afterwards.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
This is a backport of the following upstream commit:
commit a895dc8
Author: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
Date: Thu Dec 12 16:40:12 2013 +0900
[PATCH] Add --non-mmap option to disable mmap() manually.
When --non-mmap option is specified, makedumpfile doesn't use
mmap() even if /proc/vmcore supports mmap().
Signed-off-by: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
Having this patch, user can switch between mmap() and read() when
accessing vmcore. Whenever user feels necessary to use readmem on vmcore
(buggy code in mmap path, debug purpose, etc.), --non-mmap can do this
favor.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
This is a backport of the following upstream commit:
commit eb708ce
Author: Baoquan He <bhe@redhat.com>
Date: Tue Jul 2 11:11:07 2013 +0900
[PATCH 2/2] Add help and man message for '--help'.
Conventionally '-h' and '--help' are all provided. Currently makedumpfile
lacks help and man message for '--help'. Here add it.
Signed-off-by: Baoquan He <bhe@redhat.com>
It's needed for applying commit 414d3ed ("Add --non-mmap option to
disable mmap() manually").
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
This is a backport of the following upstream commit:
commit bd67c1d
Author: Baoquan He <bhe@redhat.com>
Date: Tue Jul 2 11:09:20 2013 +0900
[PATCH 1/2] Assign non-printable value as short options.
Characters for short options is limited, and now makedumpfile has
considerably many options. As times go on, no enough reasonable
letters can be assigned to each functionality with short options.
E.g non-cyclic vs Y, cyclic-buffer vs Z, eppic vs S.
Now assign non-printable value to these kind of short optins, meanwhile
define them as indicative MACRO which can make code more readable.
Signed-off-by: Baoquan He <bhe@redhat.com>
It's needed for applying commit 414d3ed ("Add --non-mmap option to
disable mmap() manually").
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
This reverts commit 2dc9600ad1:
commit 2dc9600
Author: Dave Young <dyoung@redhat.com>
Date: Thu Nov 14 10:51:47 2013 +0800
makedumpfile: disable mmap
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>
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
makedumpfile can filter out kernel data from vmcore[1]. A how-to of feature
is well explained in makedumpfile.conf, which upstream is already
shipping but we're not.
Now add makedumpfile.conf and its man page to our package the upstream
way:
makedumpfile.conf --> /etc/makedumpfile.conf.sample
makedumpfile.conf.5.gz --> /usr/share/man/man5/makedumpfile.conf.5.gz
[1]. http://lists.infradead.org/pipermail/kexec/2011-September/005466.html
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
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.
