[PATCH] crash utility: fix max_mapnr issue on system has over 44-bit addressing
by Jingbai Ma
The patch will add support for new compressed dumpfile header_version 6.
This bug was posted here:
http://lists.infradead.org/pipermail/kexec/2013-September/009587.html
This patch will add a new field in struct kdump_sub_header.
unsigned long max_mapnr;
And the old "unsigned int max_mapnr" in struct disk_dump_header will
not be used anymore. But still be there for compatibility purpose.
Signed-off-by: Jingbai Ma <jingbai.ma(a)hp.com>
---
diskdump.c | 36 +++++++++++++++++++++++++-----------
diskdump.h | 5 ++++-
2 files changed, 29 insertions(+), 12 deletions(-)
diff --git a/diskdump.c b/diskdump.c
index 0819a3f..8a2928b 100644
--- a/diskdump.c
+++ b/diskdump.c
@@ -199,22 +199,23 @@ get_bit(char *map, int byte, int bit)
}
static inline int
-page_is_ram(unsigned int nr)
+page_is_ram(unsigned long nr)
{
return get_bit(dd->bitmap, nr >> 3, nr & 7);
}
static inline int
-page_is_dumpable(unsigned int nr)
+page_is_dumpable(unsigned long nr)
{
return dd->dumpable_bitmap[nr>>3] & (1 << (nr & 7));
}
static inline int
-dump_is_partial(const struct disk_dump_header *header)
+dump_is_partial(const struct disk_dump_header *header,
+ const struct kdump_sub_header *sub_header)
{
return header->bitmap_blocks >=
- divideup(divideup(header->max_mapnr, 8), dd->block_size) * 2;
+ divideup(divideup(sub_header->max_mapnr, 8), dd->block_size) * 2;
}
static int
@@ -321,6 +322,7 @@ x86_process_elf_notes(void *note_ptr, unsigned long size_note)
* [40] unsigned long size_note; / header_version 4 and later /
* [44] off_t offset_eraseinfo; / header_version 5 and later /
* [52] unsigned long size_eraseinfo; / header_version 5 and later /
+ * [56] unsigned long max_mapnr; / header_version 6 and later /
* };
*
* But when compiled on an ARM processor, each 64-bit "off_t" would be pushed
@@ -338,6 +340,7 @@ x86_process_elf_notes(void *note_ptr, unsigned long size_note)
* [48] unsigned long size_note; / header_version 4 and later /
* [56] off_t offset_eraseinfo; / header_version 5 and later /
* [62] unsigned long size_eraseinfo; / header_version 5 and later /
+ * [66] unsigned long max_mapnr; / header_version 6 and later /
* };
*
*/
@@ -357,6 +360,7 @@ struct kdump_sub_header_ARM_target {
int pad3;
off_t offset_eraseinfo; /* header_version 5 and later */
unsigned long size_eraseinfo; /* header_version 5 and later */
+ unsigned long max_mapnr; /* header_version 6 and later */
};
static void
@@ -380,6 +384,8 @@ arm_kdump_header_adjust(int header_version)
kdsh->offset_eraseinfo = kdsh_ARM_target->offset_eraseinfo;
kdsh->size_eraseinfo = kdsh_ARM_target->size_eraseinfo;
}
+ if (header_version >= 6)
+ kdsh->max_mapnr = kdsh_ARM_target->map_mapnr;
}
#endif /* __i386__ && ARM */
@@ -578,7 +584,10 @@ restart:
}
}
- if (dump_is_partial(header))
+ if (header->header_version < 6)
+ sub_header_kdump->max_mapnr = header->max_mapnr;
+
+ if (dump_is_partial(header, sub_header_kdump))
memcpy(dd->dumpable_bitmap, dd->bitmap + bitmap_len/2,
bitmap_len/2);
else
@@ -679,7 +688,8 @@ restart:
}
if (!is_split) {
- max_sect_len = divideup(header->max_mapnr, BITMAP_SECT_LEN);
+ max_sect_len = divideup(sub_header_kdump->max_mapnr,
+ BITMAP_SECT_LEN);
pfn = 0;
dd->filename = file;
}
@@ -1058,14 +1068,14 @@ read_diskdump(int fd, void *bufptr, int cnt, ulong addr, physaddr_t paddr)
curpaddr = paddr & ~((physaddr_t)(dd->block_size-1));
page_offset = paddr & ((physaddr_t)(dd->block_size-1));
- if ((pfn >= dd->header->max_mapnr) || !page_is_ram(pfn)) {
+ if ((pfn >= dd->sub_header_kdump->max_mapnr) || !page_is_ram(pfn)) {
if (CRASHDEBUG(8)) {
fprintf(fp, "read_diskdump: SEEK_ERROR: "
"paddr/pfn: %llx/%lx ",
(ulonglong)paddr, pfn);
- if (pfn >= dd->header->max_mapnr)
- fprintf(fp, "max_mapnr: %x\n",
- dd->header->max_mapnr);
+ if (pfn >= dd->sub_header_kdump->max_mapnr)
+ fprintf(fp, "max_mapnr: %lx\n",
+ dd->sub_header_kdump->max_mapnr);
else
fprintf(fp, "!page_is_ram\n");
}
@@ -1517,7 +1527,11 @@ __diskdump_memory_dump(FILE *fp)
fprintf(fp, " block_size: %d\n", dh->block_size);
fprintf(fp, " sub_hdr_size: %d\n", dh->sub_hdr_size);
fprintf(fp, " bitmap_blocks: %u\n", dh->bitmap_blocks);
- fprintf(fp, " max_mapnr: %u\n", dh->max_mapnr);
+ if (dh->header_version >= 6)
+ fprintf(fp, " max_mapnr: %lu\n",
+ dd->sub_header_kdump->max_mapnr);
+ else
+ fprintf(fp, " max_mapnr: %u\n", dh->max_mapnr);
fprintf(fp, " total_ram_blocks: %u\n", dh->total_ram_blocks);
fprintf(fp, " device_blocks: %u\n", dh->device_blocks);
fprintf(fp, " written_blocks: %u\n", dh->written_blocks);
diff --git a/diskdump.h b/diskdump.h
index 9ab10b6..17642b6 100644
--- a/diskdump.h
+++ b/diskdump.h
@@ -42,7 +42,9 @@ struct disk_dump_header {
header in blocks */
unsigned int bitmap_blocks; /* Size of Memory bitmap in
block */
- unsigned int max_mapnr; /* = max_mapnr */
+ unsigned int max_mapnr; /* = max_mapnr, 32bit only,
+ full 64bit in sub header.
+ Do NOT use this anymore! */
unsigned int total_ram_blocks;/* Number of blocks should be
written */
unsigned int device_blocks; /* Number of total blocks in
@@ -69,6 +71,7 @@ struct kdump_sub_header {
unsigned long size_note; /* header_version 4 and later */
off_t offset_eraseinfo; /* header_version 5 and later */
unsigned long size_eraseinfo; /* header_version 5 and later */
+ unsigned long max_mapnr; /* header_version 6 and later */
};
/* page flags */
11 years, 2 months
[BUG] [compressed kdump / SADUMP] makedumpfile header truncation error
by Dave Anderson
Recent testing on very large memory systems dictates that an
update is required for the compressed kdump header generated
by makedumpfile.
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;
...
The 32-bit field has also been carried forward into the SADUMP header
as well, which has this in "sadump_mod.h":
struct sadump_header {
...
uint32_t max_mapnr; /* = max_mapnr */
...
And when these header structures change, the crash utility will need
to be changed accordingly.
Preferably for backwards-compatibility, a new header_version can be
created, with the new expanded field located in the kdump_sub_header
so that the original base structure can remain as-is. But I leave that
up to the maintainers.
Thanks,
Dave
11 years, 2 months
[PATCH] sadump: fix two GUID print bugs in help -D
by HATAYAMA Daisuke
Hello Dave,
These patches fix two bugs on sadump format in printing GUID during help -D.
Could you apply these patches?
These are based on crash-7.0.2.
--
Thanks.
HATAYAMA, Daisuke
11 years, 2 months
given a makedumpfile processed coredump, generate a symbolic backtrace containing the same info as a standard gdb backtrace
by Cody P Schafer
Hi all,
I've got a coredump file processed by makedumpfile (non-elf) and am
trying to get a backtrace with all the line numbers, argument values,
and argument types like a normal gdb backtrace with debug info (yes, I
have a vmlinux built with debuginfo).
gdb refuses to load the core dump (no big supprise there). crash loads
it but it's builtin backtrace doesn't appear to use debug info, and as a
result doesn't give me arguments + types. Doing "gdb bt" complains about
not having a stack.
Any advise? I see a few paths forward:
- somehow get crash's gdb to understand where the stack is
- hack gdb to load the non-elf coredump
- modify makedumpfile to allow it to convert the non-elf coredump back
to elf.
Thanks.
11 years, 2 months
Crash utility on Android
by Jordan Chen
Hi ,
I am going to using crash utility for kernel issue on my Android device
, It is a ARM cortex chip with Qualcomm platform , So I download crash
source code and built it as ARM target , but looks problem as below , I
also attach build log , thanks a lot for your kindly help ,
Br
Jordan
--------------Crash
Log-------------------------------------------------------------
crash 7.0.2
Copyright (C) 2002-2013 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu
--target=arm-linux-androideabi"...
WARNING: invalid note (n_type != NT_PRSTATUS)
WARNING: could not retrieve crash_notes
crash: invalid list entry: 90a0909
WARNING: UNWIND: failed to gather unwind_table listWARNING: UNWIND: failed
to initialize module unwind tables
please wait... (gathering task table data)
crash: cannot hash task_struct entries
11 years, 2 months
[ANNOUNCE] crash-7.0.2 is available
by Dave Anderson
Download from: http://people.redhat.com/anderson
Changelog:
- Added "bison" to the BuildRequires line of the crash.spec file.
Without the patch, the build of the embedded gdb-7.6 module will fail
unless either /usr/bin/bison or /usr/bin/yacc are available. The
failure will result in a stream of error messages from different
files that indicate:
multiple definition of 'main'
undefined reference to 'c_parse_escape'
undefined reference to 'ada_parse'
undefined reference to 'ada_error'
undefined reference to 'c_parse'
undefined reference to 'c_error'
undefined reference to 'cp_demangled_name_to_comp'
undefined reference to 'cp_demangled_name_parse_free'
undefined reference to 'cp_comp_to_string'
undefined reference to 'cp_new_demangle_parse_info'
and the build fails like so:
collect2: ld returned 1 exit status
make[4]: *** [gdb] Error 1
crash build failed
If building with rpmbuild, the new BuildRequires "bison" entry will
prevent the build from initiating unless the bison package has been
installed. If building with the tar.gz file, the build attempt will
proceed and fail unless either the bison or byacc (Berkeley Yacc)
package is installed.
(anderson(a)redhat.com)
- Fix the S390X initialization sequence on kernels that are configured
with CONFIG_STRICT_DEVMEM to automatically try /proc/kcore if:
(1) the /dev/crash driver is not available, and
(2) the initial /dev/mem access fails.
Without the patch, if /dev/mem is selected as the memory source and
it is restricted, the crash session will fail during initialization
with the error message "crash: read error: kernel virtual address:
<address> type: cpu_possible_mask".
(anderson(a)redhat.com)
- When checking whether a argument on the crash command line is a
dumpfile that may be in makedumpfile's "flattened" format, do not
bother checking character device files.
(anderson(a)redhat.com)
- Fix for the PPC64 virtual-to-physical virtual address translation
mechanism for vmalloc and user-space virtual addresses on Linux 3.10
and later kernels. Without the patch, the message "WARNING: cannot
access vmalloc'd module memory" is displayed during initialization,
and during the crash session, if a command attempts to translate or
read a vmalloc or user-space virtual address, it will fail.
(anderson(a)redhat.com)
- Clean up all files that emit "warning: format not a string literal
and no format arguments" when compiled with -Wformat-security warning
option. All instances of fprintf, sprintf and snprintf using the
format "fprintf(fp, buf)" are replaced with "fprintf(fp, "%s", buf)".
Also, the -Wformat-security warning option has been added to the
option list used when compiling with "make warn".
(stefan.bader(a)canonical.com, anderson(a)redhat.com)
- Fix a build failure when compiling with very old gcc-3.4.6 version
on a 2.6.9-based RHEL4 IA64 host. The bfd library in gdb-7.6 is
compiled with the -Werror option, and it fails with the message
"elflink.c:4733: warning: 'idx' might be used uninitialized in this
function".
(anderson(a)redhat.com)
- Fix a build failure when compiling with very old gcc-3.4.6 version
on a 2.6.9-based RHEL4 S390 or S390X hosts. The embedded gdb-7.6
fails to compile with the error message "s390-nat.c:364: error:
storage size of 'iov' isn't known".
(anderson(a)redhat.com)
- Fix to properly store two-digit kernel version numbers.
(timo.lindfors(a)iki.fi)
- Fix to provide hugepage address translation for the "vtop" command on
the PPC64 architecture.
(hbathini(a)linux.vnet.ibm.com)
- Fix for the "log" command to account for the kernel data structure
name change from "log" to "printk_log" in Linux 3.11-rc4 and later
kernels. Without the patch, the message "WARNING: log buf data
structure(s) have changed" will be displayed during initialization
and by the "log" command.
(anatol.pomozov(a)gmail.com)
- Fix to add a linefeed after the description of the "kmem -I" option
in the "help kmem" output, which was recently added in crash-7.0.0.
(anderson(a)redhat.com)
- Document the "-s" command line option in the "crash -h|--help" output
and in the crash.8 man page to also indicate that runtime command
scrolling is turned off by default.
(anderson(a)redhat.com)
- Fix for the "irq -d" option on 2.6.25 and later X86_64 kernels to
display the Intel interrupt descriptor table contents. Without the
patch, those kernel versions would display "irq: -d option not
supported or applicable on this architecture or kernel".
(anatol.pomozov(a)gmail.com)
- Fix for the "kmem -[sS]" options on Linux 3.11-rc1 and later kernels
that are configured with CONFIG_SLAB. Without the patch, the command
fails with the error message "kmem: invalid structure member offset:
kmem_cache_s_lists".
(anatol.pomozov(a)gmail.com)
- Fix for the "kmem <address>" and the "bt -F" options on Linux 3.8
and later kernels that are configured with CONFIG_SLUB. Without the
patch, the command would fail with the error message "kmem: invalid
structure member offset: page_slab".
(anderson(a)redhat.com)
- Fix misspellings in the "bt" and "search" help page output.
(anatol.pomozov(a)gmail.com)
- Fix for the determination of the base of the kernel's unity-mapped
virtual address region on recent ARM kernels whose "_stext" variable
address has changed from 0xc0008000 to 0xc0100000. Without the
patch, the crash session fails during invocation with the error
message "crash: vmlinux and vmcore do not match!".
(Jan.Karlsson(a)sonymobile.com)
- When printing data structures, prevent the embedded gdb from
symbolically translating pointers that are not kernel virtual
addresses. Kernel or module symbols that are not virtual addresses
can be mistaken for virtual addresses, leading to NULL pointers
being invalidly translated into a symbol name from the vmlinux or
module object file. For example, in X86_64 kernels, NULL pointers
are translated into the symbol "irq_stack_union", whose value is
not a virtual address, but rather a per-cpu offset value of 0.
(anderson(a)redhat.com)
- Fix for the "kmem -s <address>" or "kmem <address>" options on
Linux 3.11 and later kernels configured with CONFIG_SLAB. Without
the patch, both commands fail with the error message "kmem: cannot
resolve cache_cache".
(anderson(a)redhat.com)
- Fix to prevent the "bt" command from generating a segmentation
violation in a case where the per-cpu "current_task" variable and
the runqueue's "curr" variable did not agree, and the panic task
had overflowed its kernel stack. This led to the selection of the
a starting RSP address which belonged to the other task; without
the patch, the command generated a segmentation violation after
printing the first frame of the backtrace.
(anderson(a)redhat.com)
11 years, 2 months
