[PATCH 00/11] sadump: Incremental update patches
by HATAYAMA Daisuke
Hello Dave,
The following series fix minor bugs, clean up in sadump module, and
address the issue on kdump's first 640kB backup.
The last patch is a preparation for makedumpfile's support on
sadump-related formats, still work in progress, producing dumpfile in
kdump-compressed format from sadump-related formats.
This patch set is based on crash 5.1.9.
---
HATAYAMA Daisuke (11):
bt: Display register set in ELF note on kdump-compressed format generated from sadump format
sadump: Read kexec backup region instead of the first 640kB memory
Make data relevant to physical memory have 64 bits length
sadump: refer to eip and esp on x86_32 kernels
sadump: Allow disk set configuration with arbirary number of disks
sadump: debug messages at the beginning of open_disk() and add_disk()
sadump: don't exit if time stamps mismatch
sadump, bug: time stamp values displayed are same
sadump, bug: compare efi_time_t based on wrong type
sadump: cleanup is_sadump()
sadump, bug: fix cleanup sadump resources
defs.h | 2
main.c | 3
netdump.c | 17 +++
sadump.c | 385 +++++++++++++++++++++++++++++++++++++++++++++++--------------
sadump.h | 10 +-
x86.c | 2
x86_64.c | 6 +
7 files changed, 336 insertions(+), 89 deletions(-)
--
Thanks.
HATAYAMA, Daisuke
13 years, 2 months
[Patch 0/4] Slimdump framework using NT_NOCOREDUMP elf-note
by K.Prasad
Hi All,
Please find a set of patches that introduce a 'slimdump'
framework. Details as described below.
Problem
--------
A system configured with kdump, captures the kernel memory
for all types of crashes even when it doesn't make much sense to do so.
For instance, system crashes triggered due to hardware errors don't need
a complete dump of the memory for investigation.
In the case of crashes triggered by fatal machine check exceptions (MCE)
due to unrecoverable memory errors, it is even dangerous to read the
crashing kernel's memory. When the kexec kernel reads the crashing
kernel's memory, it 'consumes' the data from the faulty memory location,
potentially causing a recursion of faults.
This problem was previously discussed in the kernel community, with a
proposal to leave out kernel memory regions from /proc/vmcore (refer:
mail threads pertaining to
http://article.gmane.org/gmane.linux.kernel/1148266). However there were
suggestions against making this behaviour a kernel policy.
Solution
---------
Since capturing of crashing kernel's memory for hardware error induced
crashes isn't required or is dangerous, we introduce a mechanism to
generate 'slimdump'.
Basically, a new elf-note of type NT_NOCOREDUMP type is added by the
kernel to the vmcore, which is recognised by all tools in the kdump chain
to generate and save a 'slimdump' that contains only elf-headers and the
elf-note section. The elf-note section may be used to add description
about the cause of the error.
The enclosed set of patches make changes to kernel, kexec, makedumpfile
and crash tool to make them recognise the NT_NOCOREDUMP elf-note and
generate a 'slimdump'. Also, fatal MCEs in the kernel is turned into a
consumer of the slimdump mechanism to prevent collection of normal
kdump.
Alternatively, the user has an option (through suitable makedumpfile or
kdump configuration options) to collect the complete vmcore or to
extract the 'dmesg' from /proc/vmcore.
Screen logs
-------------
# mce-inject ~/mce/mce-test/cases/soft-inj/panic_ucr/data/srar_over
[ 4934.748416] [Hardware Error]: CPU 0: Machine Check Exception: 6 Bank
2: f580000000000000
[ 4934.749079] [Hardware Error]: RIP 73:<000000001eadbabe>
[ 4934.749079] [Hardware Error]: TSC ef029a23417 ADDR 1234
[ 4934.749079] [Hardware Error]: PROCESSOR 0:663 TIME 1317149322 SOCKET
0 APIC 0
[ 4934.749079] [Hardware Error]: Run the above through 'mcelog --ascii'
[ 4934.749079] [Hardware Error]: Machine check: Overflowed uncorrected
[ 4934.749079] Kernel panic - not syncing: Fatal machine check on
current CPU
[ 4934.749079] Pid: 1379, comm: mce-inject Tainted: G M
3.1.0-rc4.slimdump+ #34
[ 4934.749079] Call Trace:
[ 4934.749079] [<ffffffff81084922>] panic+0xbc/0x1cf
[ 4934.749079] [<ffffffff810858ff>] ? printk+0x6c/0x6e
[ 4934.749079] [<ffffffff8104c43b>] mce_panic+0x187/0x1a4
[ 4934.749079] [<ffffffff8104d525>] do_machine_check+0x5ec/0x6c3
[ 4934.749079] [<ffffffff8104e4e1>] raise_exception+0x5c/0x84
[ 4934.749079] [<ffffffff8104e5e9>] raise_local+0x5a/0xcc
[ 4934.749079] [<ffffffff8104e8ee>] mce_write+0x218/0x24e
[ 4934.749079] [<ffffffff8115abee>] vfs_write+0xb0/0x108
[ 4934.749079] [<ffffffff8115ad0a>] sys_write+0x4c/0x71
[ 4934.749079] [<ffffffff815bf12b>] system_call_fastpath+0x16/0x1b
[ 0.817861] kvm: no hardware support
..............
................
.................
# ls
vmcore
# ls -lh vmcore
-r-------- 1 root root 1.8G Sep 27 13:20 vmcore
# ~/makedumpfile.slimdump/makedumpfile vmcore vmcore.makedumpfile.review
The kernel version is not supported.
The created dumpfile may be incomplete.
Copying data : [100 %]
The dumpfile is saved to vmcore.makedumpfile.review.
makedumpfile Completed.
# ls -lh vmcore.makedumpfile.review
-rw------- 1 root root 3.9K Sep 28 01:40 vmcore.makedumpfile.review
# eu-readelf -n
vmcore.makedumpfile.review
Note segment of 3592 bytes at offset 0x158:
Owner Data size Type
CORE 336 PRSTATUS
info.si_signo: 0, info.si_code: 0, info.si_errno: 0, cursig: 0
sigpend: <>
..........
.............
.........
NUMBER(PG_private)=11
NUMBER(PG_swapcache)=16
SYMBOL(phys_base)=ffffffff81a0e010
SYMBOL(init_level4_pgt)=ffffffff81a06000
SYMBOL(node_data)=ffffffff81b70b80
LENGTH(node_data)=512
CRASHTIME=1317621133
PANIC_MCE 49 <unknown>: 21
# crash -S ~/linux-2.6.slimdump/System.map ~/linux-2.6.slimdump/vmlinux vmcore.makedumpfile.review
crash 5.1.8
Copyright (C) 2002-2011 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005 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.
crash: overriding /boot/System.map with
/home/prasadkr/linux-2.6.slimdump/System.map
"System crashed due to a hardware memory error. No coredump available."
Nocoredump Reason: PANIC_MCE
crash: Elf64_Phdr pointer: 1c46170 ELF header end: 1c46130
-------
Thanks,
K.Prasad
13 years, 2 months
[ANNOUNCE] crash version 5.1.9 is available
by Dave Anderson
Download from: http://people.redhat.com/anderson
Changelog:
- Fixed the compressed kdump panic task determination function to use
the kernel's "crashing_cpu" symbol if it exists. Without the patch,
the function returned 0 because it was using diskdump-specific header
variables that are always set to zero in compressed kdump dumpfiles;
the panic task was then found by searching the kernel stacks of all
of the active tasks.
(anderson(a)redhat.com)
- Fix for the potential of false-positive warning messages during the
initialization of s390x zdump dumpfiles that would indicate either
"WARNING: multiple active tasks have called die and/or panic" and/or
"WARNING: multiple active tasks have called die".
(holzheu(a)linux.vnet.ibm.com)
- Removal of superfluous code for gathering registers from the ELF
header in the ARM get_netdump_regs_arm() function.
(per.fransson.ml(a)gmail.com)
- Additional fixes for the ARM architecture gdb-7.0/bfd/elf32-arm.c and
gdb-7.0/bfd/cpu-arm.c files to handle gcc-4.6 compiler failures.
Without the patch, gcc-4.6 generates "error: variable ‘<variable>’
set but not used [-Werror=unused-but-set-variable]" fatal errors when
the (default) -Werror flag is used. Previous gcc versions considered
local variables were simply set to some value to be "used", but that
is no longer the case.
(anderson(a)redhat.com)
- Added new "dis -[xd]" options, which override the current default
output format with hexadecimal or decimal format for just the command
instance. Without the patch, it would require changing the default
output format with "hex" or "dec" prior to executing "dis".
(anderson(a)redhat.com)
- Added new "task -[xd]" options, which override the current default
output format with hexadecimal or decimal format for just the command
instance. Without the patch, it would require changing the default
output format with "hex" or "dec" prior to executing "task". The
new flags may be used with "foreach task" as well.
(anderson(a)redhat.com)
- Prevent the "struct -[xd]", "union -[xd]", and "p -[xd]" commands
from allowing both options being entered on the command line.
(anderson(a)redhat.com)
- Fixes to top-level crash source files filesys.c, memory.c, netdump.c,
sadump.c, symbols.c, x86.c and lkcd_x86_trace.c to allow them to be
compiled cleanly with gcc-4.6. Without the patch, gcc-4.6 generates
fatal errors indicating "error: variable ‘<variable>’ set but not
used [-Werror=unused-but-set-variable]" when building crash with
"make Warn", or generates similar warning messages when building with
"make warn". This has been tested only on x86, x86_64 and ARM; the
other architectures may still generate errors/warnings when compiling
their machine-specific files with gcc-4.6.
(anderson(a)redhat.com)
- Fix for the "irq" command on 2.6.39 and later kernels. Without the
patch, the command fails with the message "irq: invalid structure
member offset: irq_desc_t_status".
(anderson(a)redhat.com)
- Fix for the SIAL extension module that solves the problem of getting
access to integer variables.
(maxc(a)gmx.co.uk)
- Fix for compiler warnings when building the extensions/sial.so
extension module with recent versions of /usr/bin/ld. Without the
patch, two warning messages are displayed: "/usr/bin/ld: Warning:
alignment 4 of symbol 'sialppdebug' in /tmp/ccYSzE2s.o is smaller
than 16 in libsial/libsial.a(sialpp.tab.o)" and "/usr/bin/ld:
Warning: alignment 4 of symbol 'sialdebug' in /tmp/ccYSzE2s.o is
smaller than 16 in libsial/libsial.a(sial.tab.o)".
(maxc(a)gmx.co.uk)
- If the stack pointer found in the register set stored in the ELF
header of a compressed kdump dumpfile, a KVM dumpfile, or an SADUMP
dumpfile is either NULL or cannot be accessed, the register set will
be dumped after the error message. Without the patch, only the error
message was displayed.
(anderson(a)redhat.com)
- Preparation of the top-level crash sources for more efficient updates
of the embedded gdb version. The changes should be invisible other
than the fact that all top-level source files will now be compiled
with the -DGDB_xxx flag, because the gdb-defined TYPE_CODE_xxx values
that are exported in defs.h changed in more recent gdb versions.
(anderson(a)redhat.com)
- Fixes for potential segmentation violations during the panic task
search phase of session initialization from a version 4 or later
x86_64 compressed kdump, in which the number of ELF NT_PRSTATUS
notes in the dumpfile does not match the number of cpus running
when the system crashed.
(Joe.Lawrence(a)stratus.com, anderson(a)redhat.com)
- Created an exported set_tmpfile2() function that allows the caller
to pass in their own FILE pointer of an open file that only exists
during the execution of a command. It will afford the recursive-use
protection of open_tmpfile2() plus the automatic closure of the file
if the command fails prior to completion or if the user forgets to
close it with close_tmpfile2().
(anderson(a)redhat.com)
- Created a new "rd -r <outputfile>" option that copies raw data
from memory to an output file. It can be invoked either of two
possible manners:
crash> rd -r <outputfile> <address> <count>
crash> rd -r <outputfile> <address> -e <ending-address
The <count> value is always a byte count with this option.
(adrian.wenl(a)gmail.com, anderson(a)redhat.com)
- Fix for the ARM "bt" command to store the correct value of the fp
register of active tasks. Without the patch, in rare circumstances,
the output may show an empty backtrace.
(per.xx.fransson(a)stericsson.com)
- Fix to prevent a harmless warning message when /proc/kallsyms is used
as a mapfile argument. Without the patch, during initialization,
the message "crash: /proc/kallsyms: lseek: Invalid argument" is
displayed. If a regular file copy of /proc/kallsyms is used, the
message is not displayed.
(anderson(a)redhat.com)
- Fix for running against live x86 kernels that have been relocated
by the Intel Trusted Boot or "tboot" facility. Without the patch,
a live crash session fails during invocation with the error message
"crash: vmlinux and /dev/mem do not match!" (or "/dev/crash" if
applicable). As a work-around, "/proc/kallsyms" can be entered on
the command line, or the "--reloc=<size>" option can be used, but
this fix obviates that requirement for live systems.
(anderson(a)redhat.com)
- Fix for the unlikely event where makedumpfile-generated s390/s390x
compressed kdumps do not have a CPU count in the dumpfile header.
This can happen when older s390 dump tools are used to create a dump
that do not write the CPU information into the s390 dump header.
Without the patch, the warning message "crash: compressed kdump:
invalid nr_cpus: 0" is displayed, the dumpfile is not recognized
as a compressed kdump, and the session fails. Since s390/s390x have
a fallback function that gets the CPU register information out of
memory, the same warning message will be displayed, but the dumpfile
will still be recognized as a compressed kdump.
(holzheu(a)linux.vnet.ibm.com)
- Fix for the "net -s" command on 2.6.38 and later kernels. Without
the patch, the command fails with the error message "net: invalid
structure member offset: inet_opt_daddr".
(bob.montgomery(a)hp.com, anderson(a)redhat.com)
13 years, 2 months
PATCH: fix get_sock_info failure on 2.6.38
by Bob Montgomery
2.6.38 introduced another change in struct inet_sock that breaks net -s
like this:
crash-5.1.8> net -s 2494
net: invalid structure member offset: inet_opt_daddr
FILE: net.c LINE: 829 FUNCTION: get_sock_info()
[/home/bobm/bin/crash-5.1.8] error trace: 4cccca => 4cb773 => 4ca4c0 =>
4f766a
PID: 2494 TASK: ffff8801226de540 CPU: 1 COMMAND: "racoon"
FD SOCKET SOCK FAMILY:TYPE SOURCE-PORT
DESTINATION-PORT
4f766a: OFFSET_verify+202
4ca4c0: sym_socket_dump+1920
4cb773: dump_sockets_workhorse+1571
4cccca: cmd_net+3658
3 ffff8801229470c0 ffff88011f8dfc00 net: invalid structure member
offset: inet_opt_daddr
FILE: net.c LINE: 829 FUNCTION: get_sock_info()
This patch adds a new final clause to net_init to handle the case where
inet_sock no longer contains inet_daddr (the previous final clause):
struct inet_sock {
/* sk and pinet6 has to be the first two members of inet_sock */
struct sock sk;
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
struct ipv6_pinfo *pinet6;
#endif
/* Socket demultiplex comparisons on incoming packets. */
#define inet_daddr sk.__sk_common.skc_daddr <<<<<<<<<<<
#define inet_rcv_saddr sk.__sk_common.skc_rcv_saddr <<<<<<<<<<<<
The patch cheats by depending on inet_sock having struct sock as its
first element and struct sock having struct sock_common as its first
element without actually verifying that.
Bob Montgomery
13 years, 2 months
[PATCH] diskdump: Allow zero CPUs for s390
by Michael Holzheu
Hi Dave,
For s390 there are cases where makedumpfile generated dumps do not have CPU
information in the dump header. This happens when old s390 dump tools are
used to create a dump that do not write the CPU information into the s390
dump header. We can deal with this situation because we have a fallback that
gets the CPU register information out of memory (see s390x_get_lowcore).
So for s390 it would be better that we only get a warning, when crash
does not find CPU information in a makedumpfile generated dump.
Signed-off-by: Michael Holzheu <holzheu(a)linux.vnet.ibm.com>
---
diskdump.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/diskdump.c
+++ b/diskdump.c
@@ -369,7 +369,10 @@ restart:
error(INFO, "%s: invalid nr_cpus value: %d\n",
DISKDUMP_VALID() ? "diskdump" : "compressed kdump",
header->nr_cpus);
- goto err;
+#if !defined(S390) && !defined(S390X)
+ /* s390 can get register information also from memory */
+ goto err;
+#endif
}
/* read sub header */
13 years, 2 months
Changes to inet_sock break net -s post 2.6.32
by Bob Montgomery
Anyone working on this already?
Example from a 3.0 based kernel using crash 5.1.8:
crash-5.1.8> net -s 2641
net: invalid structure member offset: inet_opt_daddr
FILE: net.c LINE: 829 FUNCTION: get_sock_info()
[/home/bobm/bin/crash-5.1.8] error trace: 4cccca => 4cb773 => 4ca4c0 =>
4f766a
PID: 2641 TASK: ffff8801221724c0 CPU: 1 COMMAND: "sctpsprayd"
FD SOCKET SOCK FAMILY:TYPE SOURCE-PORT
DESTINATION-PORT
4f766a: OFFSET_verify+202
4ca4c0: sym_socket_dump+1920
4cb773: dump_sockets_workhorse+1571
4cccca: cmd_net+3658
3 ffff88011e87b080 ffff88011d61fb80 net: invalid structure member
offset: inet_opt_daddr
FILE: net.c LINE: 829 FUNCTION: get_sock_info()
These two post-2.6.32 patches to include/net/inet_sock.h both made
changes that would affect this:
2009-10-19 Eric Dumazet inet: rename some inet_sock fields
2010-12-10 Eric Dumazet net: optimize INET input path further
Thanks,
Bob Montgomery
13 years, 2 months
[crash] Analysing vmcore for a target with different endian-ness
by Suzuki Poulose
Hi Dave,
I am working on enabling Kdump/crash support for PPC440x based chipsets.
PPC44x is a family of embedded powerpc processors(BookE).
Now to analyse the vmcore generated on those boards, one would want to
run crash on his or her development machine, which is usually an x86 box.
I started with this, but ended up in a problem with the endian-ness of the
host and target. As of now this is not supported in crash.
I did start looking at the code, trying to understand how we read the data.
But before I jump in further I thought I would check if this is something
that has been tried in the past ? Or something that is not feasible ?
(We need to know the type of the data being read to convert the data)
Please let me know your thoughts / inputs.
Thanks
Suzuki
13 years, 2 months
[PATCH] ARM: fp when unwinding
by Per Fransson
Hi Dave, Mika, Jan and anyone else interested in the Crash ARM support,
The table based unwind code potentially unwinds the stack pointer to the
existing value of any other register except the PC:
} else if ((insn & 0xf0) == 0x90 &&
(insn & 0x0d) != 0x0d) {
/* 1001 nnnn: set vsp = r[nnnn] */
ctrl->vrs[SP] = ctrl->vrs[insn & 0x0f];
The 'struct stackframe' we use to keep unwind state when going from
one frame to the next (or should I say previous) only contains fp, sp,
lr and pc, which might be something we should consider changing. Even as
it stands however, frame.fp is assigned an incorrect value for active
tasks. Here's a patch to fix that.
diff --git a/unwind_arm.c b/unwind_arm.c
index fd6ac65..6554804 100644
--- a/unwind_arm.c
+++ b/unwind_arm.c
@@ -710,6 +710,7 @@ unwind_backtrace(struct bt_info *bt)
*/
if (bt->machdep) {
const struct arm_pt_regs *regs = bt->machdep;
+ frame.fp = regs->ARM_fp;
frame.lr = regs->ARM_lr;
}
And this time I did remember to run a 'make warn' =o)
Regards,
Per
13 years, 2 months
Re: [Crash-utility] [Patch 1/4][kernel][slimdump] Add new elf-note of type NT_NOCOREDUMP to capture slimdump
by K.Prasad
On Tue, Oct 04, 2011 at 11:04:17AM -0400, Nick Bowler wrote:
> On 2011-10-03 13:02 +0530, K.Prasad wrote:
> > diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
> > index 08363b0..483b2fc 100644
> > --- a/arch/x86/kernel/cpu/mcheck/mce.c
> > +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> > @@ -238,6 +238,34 @@ static atomic_t mce_paniced;
> > static int fake_panic;
> > static atomic_t mce_fake_paniced;
> >
> > +void arch_add_nocoredump_note(u32 *buf)
> > +{
> > + struct elf_note note;
> > + const char note_name[] = "PANIC_MCE";
>
> static const ...
>
> > + const char desc_msg[] = "Crash induced due to a fatal machine "
> > + "check error";
>
> likewise.
>
Not sure why you wanted them to be defined as static. These strings are
going to be copied into respective elf-note buffers just a few lines
below their definitions.
> Please don't break string literals onto multiple lines like this, since
> it prevents users from finding the string using "grep".
We could do so, hoping that checkpatch.pl doesn't complain if we crossed
the 80-column width :-)
Thanks,
K.Prasad
13 years, 2 months
add print raw data capability for rd
by Lei Wen
Hi,
I recent make a patch which give the rd command to dump the raw data. With this,
we could then do the dump the specified range of memory to the file
with console's
redirection feature like: rd -r 0x7000000 -e 0x8000000 > dump.img.
What about this idea? Could it be accepted?
Thanks,
Lei
>From f60eee5520993d823cf705ecea62b8d60166f3ae Mon Sep 17 00:00:00 2001
From: Lei Wen <leiwen(a)marvell.com>
Date: Thu, 29 Sep 2011 20:03:29 -0700
Subject: [PATCH] rd: add option to dump the raw format
Signed-off-by: Lei Wen <leiwen(a)marvell.com>
---
help.c | 3 ++-
memory.c | 13 ++++++++++++-
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/help.c b/help.c
index b8db00a..987bd95 100755
--- a/help.c
+++ b/help.c
@@ -1396,7 +1396,7 @@ NULL
char *help_rd[] = {
"rd",
"read memory",
-"[-adDsSupxmfN][-8|-16|-32|-64][-o offs][-e addr] [address|symbol] [count]",
+"[-adDsSupxrmfN][-8|-16|-32|-64][-o offs][-e addr] [address|symbol] [count]",
" This command displays the contents of memory, with the output formatted",
" in several different manners. The starting address may be entered either",
" symbolically or by address. The default output size is the size of a long",
@@ -1426,6 +1426,7 @@ char *help_rd[] = {
" non-printable character.",
" -N display output in network byte order (only valid for 16-
and 32-bit",
" values)",
+" -r dump the address as raw format",
" -o offs offset the starting address by offs.",
" -e addr display memory until reaching specified ending
hexadecimal address.",
" address starting hexadecimal address:",
diff --git a/memory.c b/memory.c
index 9575d8e..985e2ec 100755
--- a/memory.c
+++ b/memory.c
@@ -264,6 +264,7 @@ static void dump_page_flags(ulonglong);
#define SLAB_CACHE (0x1000)
#define DISPLAY_ASCII (0x2000)
#define NET_ENDIAN (0x4000)
+#define DISPLAY_RAW (0x8000)
#define DISPLAY_TYPES
(DISPLAY_ASCII|DISPLAY_8|DISPLAY_16|DISPLAY_32|DISPLAY_64)
#define ASCII_UNLIMITED ((ulong)(-1) >> 1)
@@ -973,9 +974,12 @@ cmd_rd(void)
memtype = KVADDR;
count = -1;
- while ((c = getopt(argcnt, args, "axme:pfudDusSNo:81:3:6:")) != EOF) {
+ while ((c = getopt(argcnt, args, "raxme:pfudDusSNo:81:3:6:")) != EOF) {
switch(c)
{
+ case 'r':
+ flag |= DISPLAY_RAW;
+ break;
case 'a':
flag &= ~DISPLAY_TYPES;
flag |= DISPLAY_ASCII;
@@ -1291,6 +1295,13 @@ display_memory(ulonglong addr, long count,
ulong flag, int memtype)
for (i = a = 0; i < count; i++) {
readmem(addr, memtype, location, typesz,
readtype, FAULT_ON_ERROR);
+ if (flag & DISPLAY_RAW) {
+ for (j = 0; j < typesz; j++)
+ fputc(*(char *)(location + j), fp);
+
+ addr += typesz;
+ continue;
+ }
if (!(flag & DISPLAY_ASCII) && ((i % per_line) == 0)) {
if (i) {
--
1.7.0.4
13 years, 2 months
