Age | Commit message (Collapse) | Author |
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
"mem=" is useful to indicate the memory region when capture kernel boot.
Otherwise, capture kernel will breakdown the memory of panic kernel.
Although it can be add by user, adding "mem" by software is a better way.
What's more, "mem" should contain elfcorehdr range. Elfcorehdr memory
should be managed by kernel.
Fixes: 7bd251654aad ("kexec-tools: mips: Remove commandline parameter "mem"")
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Jinyang He <hejinyang@loongson.cn>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In function dtb_set_property, when malloc new_node fails,
we need to free new_dtb before return.
Fixes: f56cbcf4c2766 ("kexec/dt-ops.c: Fix '/chosen' v/s 'chosen' node
being passed to fdt helper functions")
Signed-off-by: qiuguorui1 <qiuguorui1@huawei.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In function zlib_decompress_file, when gzdirect(fp) fails,
we should gzclose fp before return.
Fixes: d606837b56d46 ("Fix zlib/lzma decompression.")
Signed-off-by: qiuguorui1 <qiuguorui1@huawei.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Linux 5.10 moved to a new lockless ringbuffer. The new ringbuffer
is structured completely different to the previous iterations.
Add support for retrieving the ringbuffer using vmcoreinfo. The
new ringbuffer is detected based on the availability of the
"prb" symbol.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
fixed the same way as in 70cca82
"kexec: Fix snprintf related compilation warnings"
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
-mcmodel=large there
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add option to allow purgatory printing on arm64 hardware
by passing the console name which should be used.
Based on a patch by Geoff Levand.
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Acked-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch fixes the following snprintf related compilation warning
seen currently with gcc versions 7 and 8 when kexec is compiled with
-Wformat-truncation option:
kexec/fs2dt.c:673:34: warning: ‘stdout-path’ directive output may be truncated writing 11 bytes into a region of size between 1 and 1024 [-Wformat-truncation=]
snprintf(filename, MAXPATH, "%sstdout-path", pathname);
^~~~~~~~~~~
kexec/fs2dt.c:673:3: note: ‘snprintf’ output between 12 and 1035 bytes into a destination of size 1024
snprintf(filename, MAXPATH, "%sstdout-path", pathname);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kexec/fs2dt.c:676:35: warning: ‘linux,stdout-path’ directive output may be truncated writing 17 bytes into a region of size between 1 and 1024 [-Wformat-truncation=]
snprintf(filename, MAXPATH, "%slinux,stdout-path", pathname);
^~~~~~~~~~~~~~~~~
kexec/fs2dt.c:676:4: note: ‘snprintf’ output between 18 and 1041 bytes into a destination of size 1024
snprintf(filename, MAXPATH, "%slinux,stdout-path", pathname);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kexec/firmware_memmap.c:132:35: warning: ‘%s’ directive output may be truncated writing 5 bytes into a region of size between 0 and 4095 [-Wformat-truncation=]
snprintf(filename, PATH_MAX, "%s/%s", entry, "start");
^~ ~~~~~~~
kexec/firmware_memmap.c:132:2: note: ‘snprintf’ output between 7 and 4102 bytes into a destination of size 4096
snprintf(filename, PATH_MAX, "%s/%s", entry, "start");
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kexec/firmware_memmap.c:142:35: warning: ‘%s’ directive output may be truncated writing 3 bytes into a region of size between 0 and 4095 [-Wformat-truncation=]
snprintf(filename, PATH_MAX, "%s/%s", entry, "end");
^~ ~~~~~
kexec/firmware_memmap.c:142:2: note: ‘snprintf’ output between 5 and 4100 bytes into a destination of size 4096
snprintf(filename, PATH_MAX, "%s/%s", entry, "end");
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kexec/firmware_memmap.c:152:35: warning: ‘%s’ directive output may be truncated writing 4 bytes into a region of size between 0 and 4095 [-Wformat-truncation=]
snprintf(filename, PATH_MAX, "%s/%s", entry, "type");
^~ ~~~~~~
kexec/firmware_memmap.c:152:2: note: ‘snprintf’ output between 6 and 4101 bytes into a destination of size 4096
snprintf(filename, PATH_MAX, "%s/%s", entry, "type");
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Since the simplest method to address the gcc warnings and possible
truncation would be to check the return value provided from snprintf
(well there are other methods like using 'asnprintf' or using
'open_memstream' function to create the FILE object, but these are more
intrusive), so this patch does the same.
Cc: Simon Horman <horms@verge.net.au>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: kexec@lists.infradead.org
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The vmcore-dmesg utility has been in usage for several years,
and is pretty stable now.
So its useful now to modify its man page to indicate the same.
Also fix some minor formatting issues.
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add some missing free() calls.
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Where Y specifies how much memory to reserve for the dump-capture kernel
and X specifies the beginning of this reserved memory. So Y should be
placed before X.
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Reviewed-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
"mem=" indicating the memory region the new kernel can use to boot into.
And passed to the dump-capture kernel by kernel commandline parameter
"mem=". But in the dump-capture kernel, we don’t need to use this parameter
now, so remove "mem" and don't add "mem=" to new kernel commandline.
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add missing close() call.
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Reviewed-by: Khalid Aziz <khalid@gonehiking.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
New email address for Khalid Aziz.
Signed-off-by: Khalid Aziz <khalid@gonehiking.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Fix the following warnings:
kexec/arch/mips/kexec-elf-mips.c:161:41: warning: passing argument 3 of
‘dtb_set_initrd’ makes integer from pointer without a cast
dtb_set_initrd(&dtb_buf, &dtb_length, initrd_buf, initrd_buf + initrd_size);
^
In file included from kexec/arch/mips/kexec-elf-mips.c:33:0:
kexec/arch/mips/../../dt-ops.h:6:5: note: expected ‘off_t’ but argument is
of type ‘char *’
int dtb_set_initrd(char **dtb, off_t *dtb_size, off_t start, off_t end);
^
kexec/arch/mips/kexec-elf-mips.c:161:53: warning: passing argument 4 of
‘dtb_set_initrd’ makes integer from pointer without a cast
dtb_set_initrd(&dtb_buf, &dtb_length, initrd_buf, initrd_buf + initrd_size);
^
In file included from kexec/arch/mips/kexec-elf-mips.c:33:0:
kexec/arch/mips/../../dt-ops.h:6:5: note: expected ‘off_t’ but argument is
of type ‘char *’
int dtb_set_initrd(char **dtb, off_t *dtb_size, off_t start, off_t end);
^
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In the function elf_mips_load(), crash_cmdline was alloced memory.
But it seems to forget to free it when last used at line 131.
Signed-off-by: Jinyang He <hejinyang@loongson.cn>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In the function kexec_iomem_for_each_line(), it is better to
check the callback first, it can return directly if the callback
is NULL.
Signed-off-by: Jinyang He <hejinyang@loongson.cn>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Increase the size of the zImage after seeking for the tag to avoid
reading past the end of the supplied buffer should there be not tag
in the zImage.
Fixes: f57f0bf8975d24fe1e7c4936fdfb5c3b123ab75f
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
Cc: Russell King <rmk@armlinux.org.uk>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Fixes: 28d4ab532808 ("Add generic debug option")
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Redefine OPT_APPEND to avoid clash with OPT_KEXEC_SYSCALL_AUTO.
Redefine OPT_RAMDISK to avoid such problems in the future
Minor cleanup in HPPA too.
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The command line is duplicated on s390 if kexec_file_load(2) is not
implemented. That's because the corresponding variable is not reset
to an empty string before re-parsing the kexec command line.
Fixes: 9cf721279f6c ("Reset getopt before falling back to legacy syscall")
Signed-off-by: Petr Tesarik <ptesarik@suse.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This signals xen to do a KEXEC_TYPE_LIVE_UPDATE kexec operation.
Signed-off-by: Varad Gautam <vrd@amazon.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Support loading a live update image for xen from kexec userspace.
For a multiboot2 Elf on a xen setup, this will:
- load the Elf into KEXEC_RANGE_MA_XEN
- load purgatory and modules into KEXEC_RANGE_MA_LIVEUPDATE
- append the Elf cmdline with " liveupdate=<size>@<addr>
v2: define xen related symbols outside of HAVE_LIBXENCTRL
Signed-off-by: Varad Gautam <vrd@amazon.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
And convert all callers of xc_kexec_get_range to use this. Allows reusing
sanity checks for other KEXEC_RANGEs
v2: define xen_get_kexec_range outside of HAVE_LIBXENCTRL
Signed-off-by: Varad Gautam <vrd@amazon.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When building kexec-tools for Fedora 32, following error is observed:
/usr/bin/ld: kexec/arch/x86_64/kexec-bzImage64.o:(.bss+0x0): multiple definition of `bzImage_support_efi_boot';
kexec/arch/i386/kexec-bzImage.o:(.bss+0x0): first defined here
/builddir/build/BUILD/kexec-tools-2.0.20/kexec/arch/arm/../../fs2dt.h:33: multiple definition of `my_debug';
kexec/fs2dt.o:/builddir/build/BUILD/kexec-tools-2.0.20/kexec/fs2dt.h:33: first defined here
/builddir/build/BUILD/kexec-tools-2.0.20/kexec/arch/arm64/kexec-arm64.h:68: multiple definition of `arm64_mem';
kexec/fs2dt.o:/builddir/build/BUILD/kexec-tools-2.0.20/././kexec/arch/arm64/kexec-arm64.h:68: first defined here
/builddir/build/BUILD/kexec-tools-2.0.20/kexec/arch/arm64/kexec-arm64.h:54: multiple definition of `initrd_size';
kexec/fs2dt.o:/builddir/build/BUILD/kexec-tools-2.0.20/././kexec/arch/arm64/kexec-arm64.h:54: first defined here
/builddir/build/BUILD/kexec-tools-2.0.20/kexec/arch/arm64/kexec-arm64.h:53: multiple definition of `initrd_base';
kexec/fs2dt.o:/builddir/build/BUILD/kexec-tools-2.0.20/././kexec/arch/arm64/kexec-arm64.h:53: first defined here
And apparently, these variables are wrongly declared multiple times. So
remove duplicated declaration.
Signed-off-by: Kairui Song <kasong@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Hi,
Looking in the kexec-tools code I found these conditions that
seems will never be met. Not sure if that was intentional for explicitity,
if it was the case, please disconsider this patch.
xmalloc and xrealloc when fails calls die() that calls exit(1).
Checks for if(!memory) after they are called will never be met that
condition, since the process will be exited after an allocation fail.
Signed-off-by: Leonidas S. Barbosa <kirotawa@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
reserved region
When loading kernel and initramfs for kexec, kexec-tools could get the
e820 reserved region from "/proc/iomem" in order to rebuild the e820
ranges for kexec kernel, but there may be the string "Reserved" in the
"/proc/iomem", which caused the failure of parsing. For example:
#cat /proc/iomem|grep -i reserved
00000000-00000fff : Reserved
7f338000-7f34dfff : Reserved
7f3cd000-8fffffff : Reserved
f17f0000-f17f1fff : Reserved
fe000000-ffffffff : Reserved
Currently, kexec-tools can not handle the above case because the memcmp()
is case sensitive when comparing the string.
So, let's fix this corner and make sure that the string "reserved" and
"Reserved" in the "/proc/iomem" are both parsed appropriately.
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Acked-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The modules may need to parse the arguments again after
kexec_file_load(2) failed, but getopt is not reset.
This change fixes the --initrd option on s390x. Without this patch,
it will fail to load the initrd on kernels that do not implement
kexec_file_load(2).
Signed-off-by: Petr Tesarik <ptesarik@suse.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The handling of kexec_file_load() error conditions needs some
improvement.
First, on failure, the system call itself returns -1 and sets
errno. It is wrong to check the return value itself.
Second, do_kexec_file_load() mixes different types of error
codes (-1, return value of a load method, negative kernel error
number). Let it always return one of the reason codes defined in
kexec/kexec.h.
Third, the caller of do_kexec_file_load() cannot know what exactly
failed inside that function, so it should not check errno directly.
All it needs to know is whether it makes sense to fall back to the
other syscall. Add an error code for that purpose (EFALLBACK), and
let do_kexec_file_load() decide.
Fourth, do_kexec_file_load() should not print any error message if
it returns EFALLBACK, because the fallback syscall may succeed
later, and the user is confused whether the command failed, or not.
Move the error message towards the end of main().
Signed-off-by: Petr Tesarik <ptesarik@suse.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When reading the device-tree exported crashkernel-base and
crashkernel-size, their values should be converted from big-endian to the
CPU byte order.
These is the output of running kexec --print-ckr-size on a little-endian
ppc64 box.
$ kexec --print-ckr-size
137438953472
$ kexec --print-ckr-size
536870912
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This addresses the following compilation issues when building for i386.
kexec/arch/i386/kexec-x86.c:39:22: error: 'multiboot2_x86_probe' undeclared here (not in a function); did you mean 'multiboot_x86_probe'?
{ "multiboot2-x86", multiboot2_x86_probe, multiboot2_x86_load,
^~~~~~~~~~~~~~~~~~~~
multiboot_x86_probe
kexec/arch/i386/kexec-x86.c:39:44: error: 'multiboot2_x86_load' undeclared here (not in a function); did you mean 'multiboot_x86_load'?
{ "multiboot2-x86", multiboot2_x86_probe, multiboot2_x86_load,
^~~~~~~~~~~~~~~~~~~
multiboot_x86_load
kexec/arch/i386/kexec-x86.c:40:4: error: 'multiboot2_x86_usage' undeclared here (not in a function); did you mean 'multiboot_x86_usage'?
multiboot2_x86_usage },
^~~~~~~~~~~~~~~~~~~~
multiboot_x86_usage
make: *** [Makefile:114: kexec/arch/i386/kexec-x86.o] Error 1
make: *** Waiting for unfinished jobs....
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
We use a large initrd that maxes out our available RAM when loading
kexec. The problem can be mitigated by using slurp_file_mmap(), which
avoids creating a copy of the initrd. The initrd does not use free,
realloc, etc, so it should be safe to use.
Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
As described in the commit ("arm64: kexec: allocate memory space avoiding
reserved regions"), /proc/iomem now has a lot of "reserved" entries, and
it's not just enough to have a fixed size of memory range array.
With this patch, kdump is allowed to handle arbitrary number of memory
ranges, using mem_regions_alloc_and_xxx() functions.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
On UEFI/ACPI-only system, some memory regions, including but not limited
to UEFI memory map and ACPI tables, must be preserved across kexec'ing.
Otherwise, they can be corrupted and result in early failure in booting
a new kernel.
In recent kernels, /proc/iomem now has an extended file format like:
40000000-5871ffff : System RAM
41800000-426affff : Kernel code
426b0000-42aaffff : reserved
42ab0000-42c64fff : Kernel data
54400000-583fffff : Crash kernel
58590000-585effff : reserved
58700000-5871ffff : reserved
58720000-58b5ffff : reserved
58b60000-5be3ffff : System RAM
58b61000-58b61fff : reserved
where the "reserved" entries at the top level or under System RAM (and
its descendant resources) are ones of such kind and should not be regarded
as usable memory ranges where several free spaces for loading kexec data
will be allocated.
With this patch, get_memory_ranges() will handle this format of file
correctly. Note that, for safety, unknown regions, in addition to
"reserved" ones, will also be excluded.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
mem_regions_alloc_and_add() and mem_regions_alloc_and_exclude() are
functionally equivalent to, respectively, mem_regions_add() and
mem_regions_exclude() except the formers will re-allocate memory
dynamically when no more entries are available in 'ranges' array.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When compiling kexec-tools on a 32-bit platform, assigning an
(unsigned long long) value to an (unsigned long) variable creates
this warning:
elf_info.c: In function 'read_phys_offset_elf_kcore':
elf_info.c:805:14: warning: conversion from 'long long unsigned int' to
'long unsigned int' changes value from '18446744073709551615' to '4294967295'
805 | *phys_off = UINT64_MAX;
Fix it by using ULONG_MAX instead of UINT64_MAX.
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Fix a possible out-of-bounds access in function ifdown():
ifdown.c: In function 'ifdown':
ifdown.c:56:4: warning: 'strncpy' specified bound 16 equals destination size [-Wstringop-truncation]
56 | strncpy(ifr.ifr_name, ifp->if_name, IFNAMSIZ);
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch adds support for the parisc Architecture. kexec support
for parisc is included with linux-5.4.
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Tested-by: Helge Deller <deller@gmx.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In the kernel upstream commit 4ab65ba7a5cb
("ARM: add kexec_file_load system call number"),
__NR_kexec_file_load for arm has been defined to be 401.
This results that even if kexec_file_load isn't implemented
for arm but the function is_kexec_file_load_implemented()
will still return true. So undef __NR_kexec_file_load for
arm architecture.
Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch fixes the following compilation warning in
'i386/kexec-mb2-x86.c' regarding the variable 'result'
which is set but not used:
kexec/arch/i386/kexec-mb2-x86.c:402:6:
warning: variable ‘result’ set but not used [-Wunused-but-set-variable]
int result;
^~~~~~
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Running 'cppcheck' static code analyzer (see cppcheck(1))
on 'vmcore-dmesg/vmcore-dmesg.c' shows the following
shifting error:
$ cppcheck --enable=all vmcore-dmesg/vmcore-dmesg.c
Checking vmcore-dmesg/vmcore-dmesg.c ...
[vmcore-dmesg/vmcore-dmesg.c:17]: (error) Shifting signed 32-bit value by 31 bits is undefined behaviour
Fix the same via this patch.
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
With some corrupted vmcore files, the vmcore-dmesg.txt file may grow
forever till the kdump disk becomes full, and also probably causes
the disk error messages as follow:
...
sd 0:0:0:0: [sda] tag#6 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:0:0: [sda] tag#6 CDB: Read(10) 28 00 08 06 4c 98 00 00 08 00
blk_update_request: I/O error, dev sda, sector 134630552
sd 0:0:0:0: [sda] tag#7 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:0:0: [sda] tag#7 CDB: Read(10) 28 00 08 06 4c 98 00 00 08 00
blk_update_request: I/O error, dev sda, sector 134630552
...
If vmcore-dmesg.txt occupies the whole disk, the vmcore can not be
saved, this is also a problem.
Lets limit the size of vmcore-dmesg.txt to avoid such problems.
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Some code related to vmcore-dmesg.c is put into the util_lib, which
is not very reasonable, so lets move it back and tidy up those code.
In addition, that will also help to limit the size of vmcore-dmesg.txt
in vmcore-dmesg.c instead of elf_info.c.
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The variable 'fname' is mistakenly defined two twice, the first definition
is in the vmcore-dmesg.c, and the second definition is in the elf_info.c.
That is confused and incorrect although it's a static type, because the
value of variable 'fname' is not assigned(set) in elf_info.c. Anyway, its
value will be always 'null' when printing an error information.
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Here, no need to wrap the read_elf() again, lets invoke it directly.
So remove the read_elf_kcore() and clean up redundant code.
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|