10:54 a.m.
When kernel panic happens and kdump crash kernel is loaded, device
drivers enabled in the kdump crash kernel collect device specific
snapshot of the hardware/firmware state of their underlying devices.
These snapshots are exported as ELF notes with note type NT_VMCOREDD
(i.e., 0x700) in vmcore [1].
This series of patches enhance crash utility to analyze and
extract these hardware specific device dumps from vmcore using
a new "devdump" command.
Patches 1 and 2 enhance help -D to parse NT_VMCOREDD ELF notes
in ELF vmcore and KDUMP vmcore, respectively.
Patches 3 and 4 implement devdump command to analyze and extract
hardware specific device dumps from ELF vmcore and KDUMP vmcore,
respectively.
Suggestions and feedback will be much appreciated.
Thanks,
Surendra
[1] https://lkml.org/lkml/2018/5/2/190
Surendra Mobiya (4):
parse NT_VMCOREDD ELF notes in ELF vmcore
parse NT_VMCOREDD ELF notes in KDUMP vmcore
add devdump command to extract NT_VMCOREDD from ELF vmcore
enhance devdump command to extract NT_VMCOREDD from KDUMP vmcore
Makefile | 4 +--
defs.h | 16 +++++++++
devdump.c | 114 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
diskdump.c | 71 +++++++++++++++++++++++++++++++++++-
global_data.c | 1 +
help.c | 23 ++++++++++++
memory.c | 7 ++++
netdump.c | 89 +++++++++++++++++++++++++++++++++++++++++++--
netdump.h | 3 ++
vmcore.h | 36 +++++++++++++++++++
10 files changed, 359 insertions(+), 5 deletions(-)
create mode 100644 devdump.c
create mode 100644 vmcore.h
--
1.8.3.1
10:54 a.m.
New subject: [RFC 1/4] parse NT_VMCOREDD ELF notes in ELF vmcore
Enhance help -D to parse NT_VMCOREDD ELF notes present in ELF vmcore.
Example:
crash> help -D
[...]
Elf64_Nhdr:
n_namesz: 8 ("LINUX")
n_descsz: 33558508
n_type: 700 (NT_VMCOREDD)
name: "cxgb4_0000:02:00.4"
size: 33558464
Elf64_Nhdr:
n_namesz: 8 ("LINUX")
n_descsz: 33558508
n_type: 700 (NT_VMCOREDD)
name: "cxgb4_0000:03:00.4"
size: 33558464
[...]
Signed-off-by: Surendra Mobiya <surendra(a)chelsio.com>
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy(a)chelsio.com>
---
defs.h | 3 +++
netdump.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++--
netdump.h | 3 +++
vmcore.h | 36 ++++++++++++++++++++++++++++++++++++
4 files changed, 89 insertions(+), 2 deletions(-)
create mode 100644 vmcore.h
diff --git a/defs.h b/defs.h
index 2466681..0925a46 100644
--- a/defs.h
+++ b/defs.h
@@ -148,6 +148,8 @@
#define NR_CPUS (4096)
#endif
+#define NR_DEVICE_DUMPS (64)
+
/* Some architectures require memory accesses to be aligned. */
#if defined(SPARC64)
#define NEED_ALIGNED_MEM_ACCESS
@@ -6396,6 +6398,7 @@ void display_regs_from_elf_notes(int, FILE *);
void display_ELF_note(int, int, void *, FILE *);
void *netdump_get_prstatus_percpu(int);
int kdump_kaslr_check(void);
+void display_vmcoredd_note(void *ptr, FILE *ofp);
QEMUCPUState *kdump_get_qemucpustate(int);
#define PRSTATUS_NOTE (1)
#define QEMU_NOTE (2)
diff --git a/netdump.c b/netdump.c
index 96d1e86..c4e9b3e 100644
--- a/netdump.c
+++ b/netdump.c
@@ -1898,6 +1898,21 @@ vmcoreinfo_read_integer(const char *key, long default_value)
return retval;
}
+void
+display_vmcoredd_note(void *ptr, FILE *ofp)
+{
+ int sp;
+ unsigned int dump_size;
+ struct vmcoredd_header *vh;
+
+ sp = VMCORE_VALID() ? 25 : 22;
+ vh = (struct vmcoredd_header *)ptr;
+
+ dump_size = vh->n_descsz - VMCOREDD_MAX_NAME_BYTES;
+ fprintf(ofp, "%sname: \"%s\"\n", space(sp), vh->dump_name);
+ fprintf(ofp, "%ssize: %u\n", space(sp), dump_size);
+}
+
/*
* Dump a note section header -- the actual data is defined by netdump
*/
@@ -2002,6 +2017,18 @@ dump_Elf32_Nhdr(Elf32_Off offset, int store)
}
break;
#endif
+ case NT_VMCOREDD:
+ netdump_print("(NT_VMCOREDD)\n");
+ if (store) {
+ for (i = 0; i < NR_DEVICE_DUMPS; i++) {
+ if (!nd->nt_vmcoredd_array[i]) {
+ nd->nt_vmcoredd_array[i] = (void *)note;
+ nd->num_vmcoredd_notes++;
+ break;
+ }
+ }
+ }
+ break;
default:
xen_core = STRNEQ(buf, "XEN CORE") || STRNEQ(buf, "Xen");
if (STRNEQ(buf, "VMCOREINFO_XEN"))
@@ -2092,6 +2119,9 @@ dump_Elf32_Nhdr(Elf32_Off offset, int store)
netdump_print(" ");
}
lf = 0;
+ } else if (note->n_type == NT_VMCOREDD) {
+ if (nd->ofp)
+ display_vmcoredd_note(note, nd->ofp);
} else {
if (nd->ofp && !XEN_CORE_DUMPFILE() && !(pc->flags2 &
LIVE_DUMP)) {
if (machine_type("X86")) {
@@ -2126,7 +2156,7 @@ dump_Elf32_Nhdr(Elf32_Off offset, int store)
static size_t
dump_Elf64_Nhdr(Elf64_Off offset, int store)
{
- int i, lf;
+ int i = 0, lf = 0;
Elf64_Nhdr *note;
size_t len;
char buf[BUFSIZE];
@@ -2271,6 +2301,18 @@ dump_Elf64_Nhdr(Elf64_Off offset, int store)
}
break;
#endif
+ case NT_VMCOREDD:
+ netdump_print("(NT_VMCOREDD)\n");
+ if (store) {
+ for (i = 0; i < NR_DEVICE_DUMPS; i++) {
+ if (!nd->nt_vmcoredd_array[i]) {
+ nd->nt_vmcoredd_array[i] = (void *)note;
+ nd->num_vmcoredd_notes++;
+ break;
+ }
+ }
+ }
+ break;
default:
xen_core = STRNEQ(buf, "XEN CORE") || STRNEQ(buf, "Xen");
if (STRNEQ(buf, "VMCOREINFO_XEN"))
@@ -2364,7 +2406,10 @@ dump_Elf64_Nhdr(Elf64_Off offset, int store)
}
}
- if (BITS32() && (xen_core || (note->n_type == NT_PRSTATUS) || qemuinfo)) {
+ if (note->n_type == NT_VMCOREDD) {
+ if (nd->ofp)
+ display_vmcoredd_note(note, nd->ofp);
+ } else if (BITS32() && (xen_core || (note->n_type == NT_PRSTATUS) ||
qemuinfo)) {
if (nd->ofp && !XEN_CORE_DUMPFILE() && !(pc->flags2 &
LIVE_DUMP)) {
if (machine_type("X86")) {
if (note->n_type == NT_PRSTATUS)
diff --git a/netdump.h b/netdump.h
index 1aeeaae..5f49c02 100644
--- a/netdump.h
+++ b/netdump.h
@@ -17,6 +17,7 @@
*/
#include <elf.h>
+#include "vmcore.h"
#define MIN_NETDUMP_ELF32_HEADER_SIZE \
sizeof(Elf32_Ehdr)+sizeof(Elf32_Phdr)+sizeof(Elf32_Phdr)
@@ -74,6 +75,8 @@ struct vmcore_data {
#define KEXEC_BACKUP_SRC_END 0x0009ffff
uint num_qemu_notes;
void *nt_qemu_percpu[NR_CPUS];
+ void *nt_vmcoredd_array[NR_DEVICE_DUMPS];
+ uint num_vmcoredd_notes;
ulonglong backup_src_start;
ulong backup_src_size;
ulonglong backup_offset;
diff --git a/vmcore.h b/vmcore.h
new file mode 100644
index 0000000..69b2cae
--- /dev/null
+++ b/vmcore.h
@@ -0,0 +1,36 @@
+/*
+ * vmcore.h
+ *
+ * Copyright (C) 2019 Chelsio Communications. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#ifndef _VMCORE_H
+#define _VMCORE_H
+
+#include <linux/types.h>
+
+#ifndef NT_VMCOREDD
+#define NT_VMCOREDD 0x700
+#endif
+
+#define VMCOREDD_NOTE_NAME "LINUX"
+#define VMCOREDD_MAX_NAME_BYTES 44
+
+struct vmcoredd_header {
+ __u32 n_namesz; /* Name size */
+ __u32 n_descsz; /* Content size */
+ __u32 n_type; /* NT_VMCOREDD */
+ __u8 name[8]; /* LINUX\0\0\0 */
+ __u8 dump_name[VMCOREDD_MAX_NAME_BYTES]; /* Device dump's name */
+};
+
+#endif /* _VMCORE_H */
--
1.8.3.1
10:54 a.m.
New subject: [RFC 2/4] parse NT_VMCOREDD ELF notes in KDUMP vmcore
Enhance help -D to parse NT_VMCOREDD ELF notes present in KDUMP vmcore.
Example:
crash> help -D
[...]
num_vmcoredd_notes: 2
notes[0]: 7ff9a578d010 (NT_VMCOREDD)
name: "cxgb4_0000:02:00.4"
size: 33558464
notes[1]: 7ff9a778e010 (NT_VMCOREDD)
name: "cxgb4_0000:03:00.4"
size: 33558464
[...]
Signed-off-by: Surendra Mobiya <surendra(a)chelsio.com>
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy(a)chelsio.com>
---
diskdump.c | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/diskdump.c b/diskdump.c
index 8085712..6b7a91b 100644
--- a/diskdump.c
+++ b/diskdump.c
@@ -26,6 +26,7 @@
#include "defs.h"
#include "diskdump.h"
#include "xen_dom0.h"
+#include "vmcore.h"
#define BITMAP_SECT_LEN 4096
@@ -58,6 +59,8 @@ struct diskdump_data {
void **nt_qemu_percpu;
void **nt_qemucs_percpu;
uint num_qemu_notes;
+ void **nt_vmcoredd_array;
+ uint num_vmcoredd_notes;
/* page cache */
struct page_cache_hdr { /* header for each cached page */
@@ -279,6 +282,7 @@ process_elf32_notes(void *note_buf, unsigned long size_note)
Elf32_Nhdr *nt;
size_t index, len = 0;
int num = 0;
+ int vmcoredd_num = 0;
int qemu_num = 0;
for (index = 0; index < size_note; index += len) {
@@ -304,6 +308,12 @@ process_elf32_notes(void *note_buf, unsigned long size_note)
process_xen_note(nt->n_type, data, nt->n_descsz);
}
+ if (nt->n_type == NT_VMCOREDD &&
+ vmcoredd_num < NR_DEVICE_DUMPS) {
+ dd->nt_vmcoredd_array[vmcoredd_num] = nt;
+ vmcoredd_num++;
+ }
+
len = roundup(len + nt->n_namesz, 4);
len = roundup(len + nt->n_descsz, 4);
}
@@ -317,6 +327,9 @@ process_elf32_notes(void *note_buf, unsigned long size_note)
pc->flags2 |= QEMU_MEM_DUMP_COMPRESSED;
dd->num_qemu_notes = qemu_num;
}
+ if (vmcoredd_num > 0)
+ dd->num_vmcoredd_notes = vmcoredd_num;
+
return;
}
@@ -326,6 +339,7 @@ process_elf64_notes(void *note_buf, unsigned long size_note)
Elf64_Nhdr *nt;
size_t index, len = 0;
int num = 0;
+ int vmcoredd_num = 0;
int qemu_num = 0;
for (index = 0; index < size_note; index += len) {
@@ -357,6 +371,12 @@ process_elf64_notes(void *note_buf, unsigned long size_note)
process_xen_note(nt->n_type, data, nt->n_descsz);
}
+ if (nt->n_type == NT_VMCOREDD &&
+ vmcoredd_num < NR_DEVICE_DUMPS) {
+ dd->nt_vmcoredd_array[vmcoredd_num] = nt;
+ vmcoredd_num++;
+ }
+
len = roundup(len + nt->n_namesz, 4);
len = roundup(len + nt->n_descsz, 4);
}
@@ -370,6 +390,9 @@ process_elf64_notes(void *note_buf, unsigned long size_note)
pc->flags2 |= QEMU_MEM_DUMP_COMPRESSED;
dd->num_qemu_notes = qemu_num;
}
+ if (vmcoredd_num > 0)
+ dd->num_vmcoredd_notes = vmcoredd_num;
+
return;
}
@@ -778,6 +801,10 @@ restart:
error(FATAL, "qemu mem dump compressed: cannot malloc pointer"
" to QEMUCS notes\n");
+ if ((dd->nt_vmcoredd_array = malloc(NR_DEVICE_DUMPS * sizeof(void *))) == NULL)
+ error(FATAL, "compressed kdump: cannot malloc array for "
+ "vmcore device dump notes\n");
+
if (FLAT_FORMAT()) {
if (!read_flattened_format(dd->dfd, offset, dd->notes_buf, size)) {
error(INFO, "compressed kdump: cannot read notes data"
@@ -875,6 +902,8 @@ err:
free(dd->nt_qemu_percpu);
if (dd->nt_qemucs_percpu)
free(dd->nt_qemucs_percpu);
+ if (dd->nt_vmcoredd_array)
+ free(dd->nt_vmcoredd_array);
dd->flags &= ~(DISKDUMP_LOCAL|KDUMP_CMPRS_LOCAL);
pc->flags2 &= ~ELF_NOTES;
@@ -1948,6 +1977,15 @@ __diskdump_memory_dump(FILE *fp)
dd->sub_header_kdump->size_note);
fprintf(fp, " notes_buf: %lx\n",
(ulong)dd->notes_buf);
+ fprintf(fp, " num_vmcoredd_notes: %d\n",
+ dd->num_vmcoredd_notes);
+ for (i = 0; i < dd->num_vmcoredd_notes; i++) {
+ fprintf(fp, " notes[%d]: %lx %s\n",
+ i, (ulong)dd->nt_vmcoredd_array[i],
+ dd->nt_vmcoredd_array[i] ? "(NT_VMCOREDD)" : "");
+ display_vmcoredd_note(dd->nt_vmcoredd_array[i], fp);
+ }
+
fprintf(fp, " num_prstatus_notes: %d\n",
dd->num_prstatus_notes);
for (i = 0; i < dd->num_prstatus_notes; i++) {
--
1.8.3.1
10:54 a.m.
New subject: [RFC 3/4] add devdump command to extract NT_VMCOREDD from ELF vmcore
Add new devdump command to analyze and extract hardware specific
device dumps in ELF vmcore
SYNOPSIS
devdump [-l][-i index][-r file]
EXAMPLES
Display the available device dumps
crash> devdump -l
0) name: "cxgb4_0000:02:00.4", file_offset: 0x278 , size:
33558464
1) name: "cxgb4_0000:03:00.4", file_offset: 0x2001278 , size:
33558464
Extract device dump at specified index
crash> devdump -i 0 -r device_dump_0.bin
0) name: "cxgb4_0000:02:00.4", file_offset: 0x278 , size:
33558464
33558464 bytes copied from 0x278 to device_dump_0.bin
Signed-off-by: Surendra Mobiya <surendra(a)chelsio.com>
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy(a)chelsio.com>
---
Makefile | 4 +--
defs.h | 11 ++++++
devdump.c | 110 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
global_data.c | 1 +
help.c | 23 ++++++++++++
memory.c | 7 ++++
netdump.c | 40 +++++++++++++++++++++
7 files changed, 194 insertions(+), 2 deletions(-)
create mode 100644 devdump.c
diff --git a/Makefile b/Makefile
index f78da15..db72b40 100644
--- a/Makefile
+++ b/Makefile
@@ -71,7 +71,7 @@ CFILES=main.c tools.c global_data.c memory.c filesys.c help.c task.c \
xen_hyper.c xen_hyper_command.c xen_hyper_global_data.c \
xen_hyper_dump_tables.c kvmdump.c qemu.c qemu-load.c sadump.c ipcs.c \
ramdump.c vmware_vmss.c \
- xen_dom0.c kaslr_helper.c
+ xen_dom0.c kaslr_helper.c devdump.c
SOURCE_FILES=${CFILES} ${GENERIC_HFILES} ${MCORE_HFILES} \
${REDHAT_CFILES} ${REDHAT_HFILES} ${UNWIND_HFILES} \
@@ -90,7 +90,7 @@ OBJECT_FILES=main.o tools.o global_data.o memory.o filesys.o help.o
task.o \
xen_hyper.o xen_hyper_command.o xen_hyper_global_data.o \
xen_hyper_dump_tables.o kvmdump.o qemu.o qemu-load.o sadump.o ipcs.o \
ramdump.o vmware_vmss.o \
- xen_dom0.o kaslr_helper.o
+ xen_dom0.o kaslr_helper.o devdump.o
MEMORY_DRIVER_FILES=memory_driver/Makefile memory_driver/crash.c memory_driver/README
diff --git a/defs.h b/defs.h
index 0925a46..41ce61f 100644
--- a/defs.h
+++ b/defs.h
@@ -4870,6 +4870,7 @@ void cmd_s390dbf(void);
#endif
void cmd_map(void); /* kvmdump.c */
void cmd_ipcs(void); /* ipcs.c */
+void cmd_devdump(void); /* devdump.c */
/*
* main.c
@@ -5277,6 +5278,7 @@ char *format_stack_entry(struct bt_info *bt, char *, ulong, ulong);
int in_user_stack(ulong, ulong);
int dump_inode_page(ulong);
ulong valid_section_nr(ulong);
+void display_memory_from_file_offset(ulonglong addr, long count, void *opt);
/*
@@ -5444,6 +5446,7 @@ extern char *help_vtop[];
extern char *help_waitq[];
extern char *help_whatis[];
extern char *help_wr[];
+extern char *help_devdump[];
#if defined(S390) || defined(S390X)
extern char *help_s390dbf[];
#endif
@@ -6400,6 +6403,8 @@ void *netdump_get_prstatus_percpu(int);
int kdump_kaslr_check(void);
void display_vmcoredd_note(void *ptr, FILE *ofp);
QEMUCPUState *kdump_get_qemucpustate(int);
+void kdump_device_dump_info(FILE *logfp);
+void kdump_device_dump(int index, char *outfile, FILE *ofp);
#define PRSTATUS_NOTE (1)
#define QEMU_NOTE (2)
@@ -6447,6 +6452,12 @@ int diskdump_kaslr_check(void);
QEMUCPUState *diskdump_get_qemucpustate(int);
/*
+ * devdump.c
+ */
+void devdump_extract(void *note, ulonglong offset, char *dump_file,
+ FILE *ofp);
+
+/*
* makedumpfile.c
*/
void check_flattened_format(char *file);
diff --git a/devdump.c b/devdump.c
new file mode 100644
index 0000000..2b9cbe8
--- /dev/null
+++ b/devdump.c
@@ -0,0 +1,110 @@
+/*
+ * devdump.c - device dump analysis suite
+ *
+ * Copyright (c) 2019 Chelsio Communications. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Author: Surendra Mobiya <surendra(a)chelsio.com>
+ */
+
+#include <string.h>
+#include <stdlib.h>
+#include <elf.h>
+#include "defs.h"
+#include "vmcore.h"
+
+void cmd_devdump(void)
+{
+ int opt, index = -1;
+ char *outputfile;
+ int list = 0;
+
+ outputfile = NULL;
+
+ if (argcnt == 1) {
+ error(INFO, "No arg provided");
+ return;
+ }
+
+ while ((opt = getopt(argcnt, args, "r:i:l")) != EOF) {
+ switch (opt) {
+ case 'r':
+ outputfile = optarg;
+ break;
+ case 'i':
+ index = atoi(optarg);
+ break;
+ case 'l':
+ list = 1;
+ break;
+ default:
+ argerrs++;
+ break;
+ }
+ }
+
+ if (argerrs)
+ cmd_usage(pc->curcmd, SYNOPSIS);
+
+ if (list) {
+ if (KDUMP_DUMPFILE())
+ kdump_device_dump_info(fp);
+ else
+ error(WARNING, "KDUMP flag not found");
+ } else {
+ if (index == -1) {
+ error(INFO, "Index not provided");
+ return;
+ }
+
+ if (!outputfile) {
+ error(INFO, "Output file not provided");
+ return;
+ }
+
+ if (KDUMP_DUMPFILE())
+ kdump_device_dump(index, outputfile, fp);
+ else
+ error(WARNING, "KDUMP flag not found");
+ }
+}
+
+void
+devdump_extract(void *_note, ulonglong offset, char *dump_file, FILE *ofp)
+{
+ struct vmcoredd_header *vh = (struct vmcoredd_header *)_note;
+ ulong dump_size;
+ FILE *tmpfp;
+
+ if (vh->n_type != NT_VMCOREDD) {
+ error(WARNING, "Unsupported note type 0x%x", vh->n_type);
+ return;
+ }
+
+ dump_size = vh->n_descsz - VMCOREDD_MAX_NAME_BYTES;
+ fprintf(ofp, " name: \"%s\", ", vh->dump_name);
+ fprintf(ofp, " file_offset: 0x%-10llx,",
+ offset + sizeof(struct vmcoredd_header));
+ fprintf(ofp, " size: %lu\n", dump_size);
+ if (dump_file) {
+ tmpfp = fopen(dump_file, "w");
+ if (!tmpfp) {
+ error(FATAL, "cannot open output file: %s\n",
+ dump_file);
+ return;
+ }
+ set_tmpfile2(tmpfp);
+ display_memory_from_file_offset(offset +
+ sizeof(struct vmcoredd_header),
+ dump_size, dump_file);
+ }
+}
diff --git a/global_data.c b/global_data.c
index cbacc42..6c42209 100644
--- a/global_data.c
+++ b/global_data.c
@@ -124,6 +124,7 @@ struct command_table_entry linux_command_table[] = {
#if defined(S390) || defined(S390X)
{"s390dbf", cmd_s390dbf, help_s390dbf, 0},
#endif
+ {"devdump", cmd_devdump, help_devdump, 0},
{(char *)NULL}
};
diff --git a/help.c b/help.c
index 47058ed..fa5818c 100644
--- a/help.c
+++ b/help.c
@@ -7753,6 +7753,29 @@ char *help_files[] = {
NULL
};
+char *help_devdump[] = {
+"devdump",
+"list/extract device dump",
+"[-l][-i index][-r file]",
+" This command is used to analyze the hardware device dumps collected\n"
+" in crash kernel.\n",
+" -l list all device dumps present in vmcore",
+" -i index Index of the device dump. Use -l command to list the device dump
indices",
+" -r file output file name ",
+"\nEXAMPLES",
+" Display the available device dumps",
+" crash> devdump -l",
+" 0) name: \"cxgb4_0000:02:00.4\", file_offset: 0x278 ,
size: 33558464",
+" 1) name: \"cxgb4_0000:03:00.4\", file_offset: 0x2001278 ,
size: 33558464",
+"",
+" Extract device dump at specified index",
+" crash> devdump -i 0 -r device_dump_0.bin",
+" 0) name: \"cxgb4_0000:02:00.4\", file_offset: 0x278 ,
size: 33558464",
+" 33558464 bytes copied from 0x278 to device_dump_0.bin",
+" ",
+NULL
+};
+
char *help_fuser[] = {
"fuser",
"file users",
diff --git a/memory.c b/memory.c
index ab561b3..34b7136 100644
--- a/memory.c
+++ b/memory.c
@@ -1793,6 +1793,13 @@ display_memory(ulonglong addr, long count, ulong flag, int memtype,
void *opt)
fprintf(fp,"\n");
}
+void
+display_memory_from_file_offset(ulonglong addr, long count, void *opt)
+{
+ display_memory(addr, count, DISPLAY_RAW | ASCII_ENDLINE | HEXADECIMAL,
+ FILEADDR, opt);
+}
+
/*
* cmd_wr() is the sister routine of cmd_rd(), used to modify the contents
* of memory. Like the "rd" command, the starting address may be entered
diff --git a/netdump.c b/netdump.c
index c4e9b3e..12e4dfc 100644
--- a/netdump.c
+++ b/netdump.c
@@ -5082,3 +5082,43 @@ kdump_get_qemucpustate(int cpu)
return (QEMUCPUState *)nd->nt_qemu_percpu[cpu];
}
#endif
+
+/*
+ * extract hardware specific device dumps from coredump.
+ */
+void
+kdump_device_dump(int index, char *outfile, FILE *ofp)
+{
+ ulonglong offset;
+ void *elf_base;
+
+ if (index >= nd->num_vmcoredd_notes) {
+ error(WARNING, "No device dump found at index: %d", index);
+ return;
+ }
+
+ if (DUMPFILE_FORMAT(nd->flags) == KDUMP_ELF64) {
+ elf_base = (void *)nd->elf64;
+ } else if (DUMPFILE_FORMAT(nd->flags) == KDUMP_ELF32) {
+ elf_base = (void *)nd->elf32;
+ } else {
+ error(WARNING, "Unsupported Dumpfile Format: 0x%x",
+ DUMPFILE_FORMAT(nd->flags));
+ return;
+ }
+
+ fprintf(ofp, "%d) ", index);
+ offset = nd->nt_vmcoredd_array[index] - elf_base;
+ devdump_extract(nd->nt_vmcoredd_array[index], offset, outfile, ofp);
+}
+
+/*
+ * list all hardware specific device dumps present in coredump.
+ */
+void kdump_device_dump_info(FILE *ofp)
+{
+ int i;
+
+ for (i = 0; i < nd->num_vmcoredd_notes; i++)
+ kdump_device_dump(i, NULL, ofp);
+}
--
1.8.3.1
10:54 a.m.
New subject: [RFC 4/4] enhance devdump command to extract NT_VMCOREDD from KDUMP vmcore
Enhance devdump command to analyze and extract hardware specific
device dumps in KDUMP vmcore.
Signed-off-by: Surendra Mobiya <surendra(a)chelsio.com>
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy(a)chelsio.com>
---
defs.h | 2 ++
devdump.c | 8 ++++++--
diskdump.c | 33 ++++++++++++++++++++++++++++++++-
3 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/defs.h b/defs.h
index 41ce61f..4dcb6db 100644
--- a/defs.h
+++ b/defs.h
@@ -6450,6 +6450,8 @@ void process_elf64_notes(void *, ulong);
void dump_registers_for_compressed_kdump(void);
int diskdump_kaslr_check(void);
QEMUCPUState *diskdump_get_qemucpustate(int);
+void diskdump_device_dump_info(FILE *ofp);
+void diskdump_device_dump(int index, char *outfile, FILE *ofp);
/*
* devdump.c
diff --git a/devdump.c b/devdump.c
index 2b9cbe8..cda56ce 100644
--- a/devdump.c
+++ b/devdump.c
@@ -58,8 +58,10 @@ void cmd_devdump(void)
if (list) {
if (KDUMP_DUMPFILE())
kdump_device_dump_info(fp);
+ else if (DISKDUMP_DUMPFILE())
+ diskdump_device_dump_info(fp);
else
- error(WARNING, "KDUMP flag not found");
+ error(WARNING, "KDUMP/DISKDUMP flag not found");
} else {
if (index == -1) {
error(INFO, "Index not provided");
@@ -73,8 +75,10 @@ void cmd_devdump(void)
if (KDUMP_DUMPFILE())
kdump_device_dump(index, outputfile, fp);
+ else if (DISKDUMP_DUMPFILE())
+ diskdump_device_dump(index, outputfile, fp);
else
- error(WARNING, "KDUMP flag not found");
+ error(WARNING, "KDUMP/DISKDUMP flag not found");
}
}
diff --git a/diskdump.c b/diskdump.c
index 6b7a91b..f0230e7 100644
--- a/diskdump.c
+++ b/diskdump.c
@@ -2099,7 +2099,6 @@ diskdump_memory_dump(FILE *fp)
return 0;
}
-
/*
* Get the switch_stack address of the passed-in task.
*/
@@ -2538,3 +2537,35 @@ diskdump_get_qemucpustate(int cpu)
return (QEMUCPUState *)dd->nt_qemucs_percpu[cpu];
}
#endif
+
+/*
+ * extract hardware specific device dumps from coredump.
+ */
+void
+diskdump_device_dump(int index, char *outfile, FILE *ofp)
+{
+ ulonglong offset;
+
+ if (index >= dd->num_vmcoredd_notes) {
+ error(WARNING, "No device dump found at index: %d", index);
+ return;
+ }
+
+ fprintf(ofp, "%d) ", index);
+ offset = dd->sub_header_kdump->offset_note +
+ ((unsigned char *)dd->nt_vmcoredd_array[index] - dd->notes_buf);
+
+ devdump_extract(dd->nt_vmcoredd_array[index], offset, outfile, ofp);
+}
+
+/*
+ * list all hardware specific device dumps present in coredump.
+ */
+void
+diskdump_device_dump_info(FILE *ofp)
+{
+ int i;
+
+ for (i = 0; i < dd->num_vmcoredd_notes; i++)
+ diskdump_device_dump(i, NULL, ofp);
+}
--
1.8.3.1
2:09 p.m.
Hi Surenda,
Great -- I've been looking forward for this patch set to arrive.
A couple things...
First, I'm going to need two sample vmcores (one ELF, one compressed kdump)
along with the associated vmlinux. You can contact me off-list with details
on how we can arrange a transfer.
Second, I do not want to add a new command. I rarely do so -- in fact,
the only times since the original crash utility was released was in 2012,
when the "ipcs" and "tree" commands were added in crash-6.0.7 and
crash-6.0.8.
New functionality is typically added as an option to an existing command.
And in this case, the natural location to put it is in the existing "dev"
command, and the devdump_extract() function can be moved into dev.c.
(FWIW, you can add your Chelsio copyright at the top of that file)
Third, there are some aesthetic changes that should be made in order
to have the display use a more traditional output format like those
used by other commands, e.g., with a single header with NAME, OFFSET and
SIZE columns.
Other than that, this looks good on paper!
Thanks,
Dave
----- Original Message -----
When kernel panic happens and kdump crash kernel is loaded, device
drivers enabled in the kdump crash kernel collect device specific
snapshot of the hardware/firmware state of their underlying devices.
These snapshots are exported as ELF notes with note type NT_VMCOREDD
(i.e., 0x700) in vmcore [1].
This series of patches enhance crash utility to analyze and
extract these hardware specific device dumps from vmcore using
a new "devdump" command.
Patches 1 and 2 enhance help -D to parse NT_VMCOREDD ELF notes
in ELF vmcore and KDUMP vmcore, respectively.
Patches 3 and 4 implement devdump command to analyze and extract
hardware specific device dumps from ELF vmcore and KDUMP vmcore,
respectively.
Suggestions and feedback will be much appreciated.
Thanks,
Surendra
[1] https://lkml.org/lkml/2018/5/2/190
Surendra Mobiya (4):
parse NT_VMCOREDD ELF notes in ELF vmcore
parse NT_VMCOREDD ELF notes in KDUMP vmcore
add devdump command to extract NT_VMCOREDD from ELF vmcore
enhance devdump command to extract NT_VMCOREDD from KDUMP vmcore
Makefile | 4 +--
defs.h | 16 +++++++++
devdump.c | 114
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
diskdump.c | 71 +++++++++++++++++++++++++++++++++++-
global_data.c | 1 +
help.c | 23 ++++++++++++
memory.c | 7 ++++
netdump.c | 89 +++++++++++++++++++++++++++++++++++++++++++--
netdump.h | 3 ++
vmcore.h | 36 +++++++++++++++++++
10 files changed, 359 insertions(+), 5 deletions(-)
create mode 100644 devdump.c
create mode 100644 vmcore.h
--
1.8.3.1
9:26 a.m.
Hi Dave,
On Saturday, April 04/13/19, 2019 at 00:39:09 +0530, Dave Anderson wrote:
Hi Surenda,
Great -- I've been looking forward for this patch set to arrive.
A couple things...
First, I'm going to need two sample vmcores (one ELF, one compressed kdump)
along with the associated vmlinux. You can contact me off-list with details
on how we can arrange a transfer.
Second, I do not want to add a new command. I rarely do so -- in fact,
the only times since the original crash utility was released was in 2012,
when the "ipcs" and "tree" commands were added in crash-6.0.7 and
crash-6.0.8.
New functionality is typically added as an option to an existing command.
And in this case, the natural location to put it is in the existing "dev"
command, and the devdump_extract() function can be moved into dev.c.
(FWIW, you can add your Chelsio copyright at the top of that file)
Ok, thanks for the suggestion. We will move the logic to dev command,
instead.
We're thinking along the lines of following sample commands:
Display the available device dumps
crash> dev -v
INDEX NAME OFFSET SIZE
0 cxgb4_0000:02:00.4 0x278 33558464
1 cxgb4_0000:03:00.4 0x2001278 33558464
Extract device dump at specified index
crash> devdump -v 0 -f device_dump_0.bin
33558464 bytes copied from 0x278 to device_dump_0.bin
Let us know your thoughts.
Third, there are some aesthetic changes that should be made in order
to have the display use a more traditional output format like those
used by other commands, e.g., with a single header with NAME, OFFSET and
SIZE columns.
Ok, We will fix this in next version.
Other than that, this looks good on paper!
Thanks,
Dave
Thanks
Surendra
----- Original Message -----
> When kernel panic happens and kdump crash kernel is loaded, device
> drivers enabled in the kdump crash kernel collect device specific
> snapshot of the hardware/firmware state of their underlying devices.
> These snapshots are exported as ELF notes with note type NT_VMCOREDD
> (i.e., 0x700) in vmcore [1].
>
> This series of patches enhance crash utility to analyze and
> extract these hardware specific device dumps from vmcore using
> a new "devdump" command.
>
> Patches 1 and 2 enhance help -D to parse NT_VMCOREDD ELF notes
> in ELF vmcore and KDUMP vmcore, respectively.
>
> Patches 3 and 4 implement devdump command to analyze and extract
> hardware specific device dumps from ELF vmcore and KDUMP vmcore,
> respectively.
>
> Suggestions and feedback will be much appreciated.
>
> Thanks,
> Surendra
>
> [1] https://lkml.org/lkml/2018/5/2/190
>
> Surendra Mobiya (4):
> parse NT_VMCOREDD ELF notes in ELF vmcore
> parse NT_VMCOREDD ELF notes in KDUMP vmcore
> add devdump command to extract NT_VMCOREDD from ELF vmcore
> enhance devdump command to extract NT_VMCOREDD from KDUMP vmcore
>
> Makefile | 4 +--
> defs.h | 16 +++++++++
> devdump.c | 114
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> diskdump.c | 71 +++++++++++++++++++++++++++++++++++-
> global_data.c | 1 +
> help.c | 23 ++++++++++++
> memory.c | 7 ++++
> netdump.c | 89 +++++++++++++++++++++++++++++++++++++++++++--
> netdump.h | 3 ++
> vmcore.h | 36 +++++++++++++++++++
> 10 files changed, 359 insertions(+), 5 deletions(-)
> create mode 100644 devdump.c
> create mode 100644 vmcore.h
>
> --
> 1.8.3.1
>
>
10:46 a.m.
----- Original Message -----
Hi Dave,
On Saturday, April 04/13/19, 2019 at 00:39:09 +0530, Dave Anderson wrote:
>
> Hi Surenda,
>
> Great -- I've been looking forward for this patch set to arrive.
>
> A couple things...
>
> First, I'm going to need two sample vmcores (one ELF, one compressed kdump)
> along with the associated vmlinux. You can contact me off-list with
> details
> on how we can arrange a transfer.
>
> Second, I do not want to add a new command. I rarely do so -- in fact,
> the only times since the original crash utility was released was in 2012,
> when the "ipcs" and "tree" commands were added in crash-6.0.7
and
> crash-6.0.8.
> New functionality is typically added as an option to an existing command.
> And in this case, the natural location to put it is in the existing "dev"
> command, and the devdump_extract() function can be moved into dev.c.
> (FWIW, you can add your Chelsio copyright at the top of that file)
>
Ok, thanks for the suggestion. We will move the logic to dev command,
instead.
We're thinking along the lines of following sample commands:
Display the available device dumps
crash> dev -v
INDEX NAME OFFSET SIZE
0 cxgb4_0000:02:00.4 0x278 33558464
1 cxgb4_0000:03:00.4 0x2001278 33558464
Extract device dump at specified index
crash> devdump -v 0 -f device_dump_0.bin
33558464 bytes copied from 0x278 to device_dump_0.bin
Let us know your thoughts.
Hi Surenda,
I've got your sample files -- thanks for them, I really appreciate it.
Here are my thoughts...
You probably want to make "-V" display the list of available device dumps in
the
vmcore, and make "-v <index>" select a singular device for dumping.
I also have a question re: the note contents. Is it up to the individual device
as to what format the dump contents are made up of? Are they always binary
dumps, or could a device dump ASCII log data or something to that effect?
I ask because I see that you are calling display_memory() using these arguments:
void
display_memory_from_file_offset(ulonglong addr, long count, void *opt)
{
display_memory(addr, count, DISPLAY_RAW | ASCII_ENDLINE | HEXADECIMAL,
FILEADDR, opt);
}
Since you are using DISPLAY_RAW, display_memory() will simply copy the
note data unmodified directly to the file, and the ASCII_ENDLINE and
HEXADECIMAL arguments are ignored. So it's not clear why you added them?
But since you did, I'm now wondering whether it would be useful for
a user to optionally dump a human-readable HEXADECIMAL/ASCII_ENDLINE
formatted display of the data to the screen? If so, then perhaps if
the "-v index" option is used alone *without* a file specified,
why not just do a translated device dump to the screen?
So to summarize, my suggestions would be:
dev -V dump the list of device dumps
dev -v <index> [ -r file ] select and display one device dump, either in
human-readable format to the screen by default,
or optionally copy it raw to a file
Thanks,
Dave
> Third, there are some aesthetic changes that should be made in order
> to have the display use a more traditional output format like those
> used by other commands, e.g., with a single header with NAME, OFFSET and
> SIZE columns.
>
Ok, We will fix this in next version.
> Other than that, this looks good on paper!
>
> Thanks,
> Dave
>
Thanks
Surendra
>
> ----- Original Message -----
> > When kernel panic happens and kdump crash kernel is loaded, device
> > drivers enabled in the kdump crash kernel collect device specific
> > snapshot of the hardware/firmware state of their underlying devices.
> > These snapshots are exported as ELF notes with note type NT_VMCOREDD
> > (i.e., 0x700) in vmcore [1].
> >
> > This series of patches enhance crash utility to analyze and
> > extract these hardware specific device dumps from vmcore using
> > a new "devdump" command.
> >
> > Patches 1 and 2 enhance help -D to parse NT_VMCOREDD ELF notes
> > in ELF vmcore and KDUMP vmcore, respectively.
> >
> > Patches 3 and 4 implement devdump command to analyze and extract
> > hardware specific device dumps from ELF vmcore and KDUMP vmcore,
> > respectively.
> >
> > Suggestions and feedback will be much appreciated.
> >
> > Thanks,
> > Surendra
> >
> > [1] https://lkml.org/lkml/2018/5/2/190
> >
> > Surendra Mobiya (4):
> > parse NT_VMCOREDD ELF notes in ELF vmcore
> > parse NT_VMCOREDD ELF notes in KDUMP vmcore
> > add devdump command to extract NT_VMCOREDD from ELF vmcore
> > enhance devdump command to extract NT_VMCOREDD from KDUMP vmcore
> >
> > Makefile | 4 +--
> > defs.h | 16 +++++++++
> > devdump.c | 114
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > diskdump.c | 71 +++++++++++++++++++++++++++++++++++-
> > global_data.c | 1 +
> > help.c | 23 ++++++++++++
> > memory.c | 7 ++++
> > netdump.c | 89 +++++++++++++++++++++++++++++++++++++++++++--
> > netdump.h | 3 ++
> > vmcore.h | 36 +++++++++++++++++++
> > 10 files changed, 359 insertions(+), 5 deletions(-)
> > create mode 100644 devdump.c
> > create mode 100644 vmcore.h
> >
> > --
> > 1.8.3.1
> >
> >
5:13 a.m.
On Monday, April 04/15/19, 2019 at 21:16:49 +0530, Dave Anderson wrote:
----- Original Message -----
> Hi Dave,
>
> On Saturday, April 04/13/19, 2019 at 00:39:09 +0530, Dave Anderson wrote:
> >
> > Hi Surenda,
> >
> > Great -- I've been looking forward for this patch set to arrive.
> >
> > A couple things...
> >
> > First, I'm going to need two sample vmcores (one ELF, one compressed
kdump)
> > along with the associated vmlinux. You can contact me off-list with
> > details
> > on how we can arrange a transfer.
> >
> > Second, I do not want to add a new command. I rarely do so -- in fact,
> > the only times since the original crash utility was released was in 2012,
> > when the "ipcs" and "tree" commands were added in
crash-6.0.7 and
> > crash-6.0.8.
> > New functionality is typically added as an option to an existing command.
> > And in this case, the natural location to put it is in the existing
"dev"
> > command, and the devdump_extract() function can be moved into dev.c.
> > (FWIW, you can add your Chelsio copyright at the top of that file)
> >
>
> Ok, thanks for the suggestion. We will move the logic to dev command,
> instead.
>
> We're thinking along the lines of following sample commands:
>
> Display the available device dumps
> crash> dev -v
> INDEX NAME OFFSET SIZE
> 0 cxgb4_0000:02:00.4 0x278 33558464
> 1 cxgb4_0000:03:00.4 0x2001278 33558464
>
> Extract device dump at specified index
> crash> devdump -v 0 -f device_dump_0.bin
> 33558464 bytes copied from 0x278 to device_dump_0.bin
>
> Let us know your thoughts.
Hi Surenda,
I've got your sample files -- thanks for them, I really appreciate it.
Here are my thoughts...
You probably want to make "-V" display the list of available device dumps in
the
vmcore, and make "-v <index>" select a singular device for dumping.
Thanks for the suggestion. We will follow this approach.
I also have a question re: the note contents. Is it up to the
individual device
as to what format the dump contents are made up of? Are they always binary
dumps, or could a device dump ASCII log data or something to that effect?
They are generally binary in nature. However, it is really up to
the individual device to decide the format on how to save its
dump contents.
I ask because I see that you are calling display_memory() using these
arguments:
void
display_memory_from_file_offset(ulonglong addr, long count, void *opt)
{
display_memory(addr, count, DISPLAY_RAW | ASCII_ENDLINE | HEXADECIMAL,
FILEADDR, opt);
}
Since you are using DISPLAY_RAW, display_memory() will simply copy the
note data unmodified directly to the file, and the ASCII_ENDLINE and
HEXADECIMAL arguments are ignored. So it's not clear why you added them?
You are correct. It should have been only DISPLAY_RAW. We will fix in
next version.
But since you did, I'm now wondering whether it would be useful
for
a user to optionally dump a human-readable HEXADECIMAL/ASCII_ENDLINE
formatted display of the data to the screen? If so, then perhaps if
the "-v index" option is used alone *without* a file specified,
why not just do a translated device dump to the screen?
We notice that rd command can manipulate the output using below
options:
rd [-adDxN][-8|-16|-32|-64]
Let us know if it is recommended to duplicate above options from rd to
dev command for manipulating screen output.
We are thinking, dev -v should only be used for doing "full" raw dump
to file. Since dev -V already shows offset and size of dump, rd -f
can be used for more control over manipulating the dump output to
screen or file.
What do you think?
So to summarize, my suggestions would be:
dev -V dump the list of device dumps
dev -v <index> [ -r file ] select and display one device dump, either in
human-readable format to the screen by default,
or optionally copy it raw to a file
Thanks,
Dave
Thanks,
Surendra
>
> > Third, there are some aesthetic changes that should be made in order
> > to have the display use a more traditional output format like those
> > used by other commands, e.g., with a single header with NAME, OFFSET and
> > SIZE columns.
> >
>
> Ok, We will fix this in next version.
>
> > Other than that, this looks good on paper!
> >
> > Thanks,
> > Dave
> >
>
> Thanks
> Surendra
>
>
> >
> > ----- Original Message -----
> > > When kernel panic happens and kdump crash kernel is loaded, device
> > > drivers enabled in the kdump crash kernel collect device specific
> > > snapshot of the hardware/firmware state of their underlying devices.
> > > These snapshots are exported as ELF notes with note type NT_VMCOREDD
> > > (i.e., 0x700) in vmcore [1].
> > >
> > > This series of patches enhance crash utility to analyze and
> > > extract these hardware specific device dumps from vmcore using
> > > a new "devdump" command.
> > >
> > > Patches 1 and 2 enhance help -D to parse NT_VMCOREDD ELF notes
> > > in ELF vmcore and KDUMP vmcore, respectively.
> > >
> > > Patches 3 and 4 implement devdump command to analyze and extract
> > > hardware specific device dumps from ELF vmcore and KDUMP vmcore,
> > > respectively.
> > >
> > > Suggestions and feedback will be much appreciated.
> > >
> > > Thanks,
> > > Surendra
> > >
> > > [1] https://lkml.org/lkml/2018/5/2/190
> > >
> > > Surendra Mobiya (4):
> > > parse NT_VMCOREDD ELF notes in ELF vmcore
> > > parse NT_VMCOREDD ELF notes in KDUMP vmcore
> > > add devdump command to extract NT_VMCOREDD from ELF vmcore
> > > enhance devdump command to extract NT_VMCOREDD from KDUMP vmcore
> > >
> > > Makefile | 4 +--
> > > defs.h | 16 +++++++++
> > > devdump.c | 114
> > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > diskdump.c | 71 +++++++++++++++++++++++++++++++++++-
> > > global_data.c | 1 +
> > > help.c | 23 ++++++++++++
> > > memory.c | 7 ++++
> > > netdump.c | 89 +++++++++++++++++++++++++++++++++++++++++++--
> > > netdump.h | 3 ++
> > > vmcore.h | 36 +++++++++++++++++++
> > > 10 files changed, 359 insertions(+), 5 deletions(-)
> > > create mode 100644 devdump.c
> > > create mode 100644 vmcore.h
> > >
> > > --
> > > 1.8.3.1
> > >
> > >
>
9:53 a.m.
----- Original Message -----
On Monday, April 04/15/19, 2019 at 21:16:49 +0530, Dave Anderson wrote:
>
>
> ----- Original Message -----
> > Hi Dave,
> >
> > On Saturday, April 04/13/19, 2019 at 00:39:09 +0530, Dave Anderson wrote:
> > >
> > > Hi Surenda,
> > >
> > > Great -- I've been looking forward for this patch set to arrive.
> > >
> > > A couple things...
> > >
> > > First, I'm going to need two sample vmcores (one ELF, one compressed
kdump)
> > > along with the associated vmlinux. You can contact me off-list with
details
> > > on how we can arrange a transfer.
> > >
> > > Second, I do not want to add a new command. I rarely do so -- in fact,
> > > the only times since the original crash utility was released was in 2012,
> > > when the "ipcs" and "tree" commands were added in
crash-6.0.7 and
> > > crash-6.0.8.
> > > New functionality is typically added as an option to an existing command.
> > > And in this case, the natural location to put it is in the existing
"dev"
> > > command, and the devdump_extract() function can be moved into dev.c.
> > > (FWIW, you can add your Chelsio copyright at the top of that file)
> > >
> >
> > Ok, thanks for the suggestion. We will move the logic to dev command,
> > instead.
> >
> > We're thinking along the lines of following sample commands:
> >
> > Display the available device dumps
> > crash> dev -v
> > INDEX NAME OFFSET SIZE
> > 0 cxgb4_0000:02:00.4 0x278 33558464
> > 1 cxgb4_0000:03:00.4 0x2001278 33558464
> >
> > Extract device dump at specified index
> > crash> devdump -v 0 -f device_dump_0.bin
> > 33558464 bytes copied from 0x278 to device_dump_0.bin
> >
> > Let us know your thoughts.
>
> Hi Surenda,
>
> I've got your sample files -- thanks for them, I really appreciate it.
>
> Here are my thoughts...
>
> You probably want to make "-V" display the list of available device dumps
in the
> vmcore, and make "-v <index>" select a singular device for dumping.
>
Thanks for the suggestion. We will follow this approach.
> I also have a question re: the note contents. Is it up to the individual device
> as to what format the dump contents are made up of? Are they always binary
> dumps, or could a device dump ASCII log data or something to that effect?
>
They are generally binary in nature. However, it is really up to
the individual device to decide the format on how to save its
dump contents.
> I ask because I see that you are calling display_memory() using these arguments:
>
> void
> display_memory_from_file_offset(ulonglong addr, long count, void *opt)
> {
> display_memory(addr, count, DISPLAY_RAW | ASCII_ENDLINE | HEXADECIMAL,
> FILEADDR, opt);
> }
>
> Since you are using DISPLAY_RAW, display_memory() will simply copy the
> note data unmodified directly to the file, and the ASCII_ENDLINE and
> HEXADECIMAL arguments are ignored. So it's not clear why you added them?
You are correct. It should have been only DISPLAY_RAW. We will fix in
next version.
> But since you did, I'm now wondering whether it would be useful for
> a user to optionally dump a human-readable HEXADECIMAL/ASCII_ENDLINE
> formatted display of the data to the screen? If so, then perhaps if
> the "-v index" option is used alone *without* a file specified,
> why not just do a translated device dump to the screen?
We notice that rd command can manipulate the output using below options:
rd [-adDxN][-8|-16|-32|-64]
Let us know if it is recommended to duplicate above options from rd to
dev command for manipulating screen output.
We are thinking, dev -v should only be used for doing "full" raw dump
to file. Since dev -V already shows offset and size of dump, rd -f
can be used for more control over manipulating the dump output to
screen or file.
That's exactly right. Duplicating the "[-adDxN][-8|-16|-32|-64]"
functionality
to the dev command would be overkill. Although, we should probably refer the user
to "rd -f" in the dev help page description of the -V option.
What do you think?
I was just guessing what a typical user would actually do with the device data file?
And so I thought that maybe the typical/default HEXADECIMAL/ASCII_ENDLINE
display might be useful as a simple quick-and-dirty option. I'll leave that
up to you.
Thanks,
Dave
10:22 a.m.
On Tuesday, April 04/16/19, 2019 at 20:23:51 +0530, Dave Anderson wrote:
----- Original Message -----
>
> On Monday, April 04/15/19, 2019 at 21:16:49 +0530, Dave Anderson wrote:
> >
> >
> > ----- Original Message -----
> > > Hi Dave,
> > >
> > > On Saturday, April 04/13/19, 2019 at 00:39:09 +0530, Dave Anderson wrote:
> > > >
> > > > Hi Surenda,
> > > >
> > > > Great -- I've been looking forward for this patch set to arrive.
> > > >
> > > > A couple things...
> > > >
> > > > First, I'm going to need two sample vmcores (one ELF, one
compressed kdump)
> > > > along with the associated vmlinux. You can contact me off-list with
details
> > > > on how we can arrange a transfer.
> > > >
> > > > Second, I do not want to add a new command. I rarely do so -- in
fact,
> > > > the only times since the original crash utility was released was in
2012,
> > > > when the "ipcs" and "tree" commands were added in
crash-6.0.7 and
> > > > crash-6.0.8.
> > > > New functionality is typically added as an option to an existing
command.
> > > > And in this case, the natural location to put it is in the existing
"dev"
> > > > command, and the devdump_extract() function can be moved into dev.c.
> > > > (FWIW, you can add your Chelsio copyright at the top of that file)
> > > >
> > >
> > > Ok, thanks for the suggestion. We will move the logic to dev command,
> > > instead.
> > >
> > > We're thinking along the lines of following sample commands:
> > >
> > > Display the available device dumps
> > > crash> dev -v
> > > INDEX NAME OFFSET SIZE
> > > 0 cxgb4_0000:02:00.4 0x278
33558464
> > > 1 cxgb4_0000:03:00.4 0x2001278
33558464
> > >
> > > Extract device dump at specified index
> > > crash> devdump -v 0 -f device_dump_0.bin
> > > 33558464 bytes copied from 0x278 to device_dump_0.bin
> > >
> > > Let us know your thoughts.
> >
> > Hi Surenda,
> >
> > I've got your sample files -- thanks for them, I really appreciate it.
> >
> > Here are my thoughts...
> >
> > You probably want to make "-V" display the list of available device
dumps in the
> > vmcore, and make "-v <index>" select a singular device for
dumping.
> >
>
> Thanks for the suggestion. We will follow this approach.
>
> > I also have a question re: the note contents. Is it up to the individual
device
> > as to what format the dump contents are made up of? Are they always binary
> > dumps, or could a device dump ASCII log data or something to that effect?
> >
>
> They are generally binary in nature. However, it is really up to
> the individual device to decide the format on how to save its
> dump contents.
>
> > I ask because I see that you are calling display_memory() using these
arguments:
> >
> > void
> > display_memory_from_file_offset(ulonglong addr, long count, void *opt)
> > {
> > display_memory(addr, count, DISPLAY_RAW | ASCII_ENDLINE |
HEXADECIMAL,
> > FILEADDR, opt);
> > }
> >
> > Since you are using DISPLAY_RAW, display_memory() will simply copy the
> > note data unmodified directly to the file, and the ASCII_ENDLINE and
> > HEXADECIMAL arguments are ignored. So it's not clear why you added them?
>
> You are correct. It should have been only DISPLAY_RAW. We will fix in
> next version.
>
> > But since you did, I'm now wondering whether it would be useful for
> > a user to optionally dump a human-readable HEXADECIMAL/ASCII_ENDLINE
> > formatted display of the data to the screen? If so, then perhaps if
> > the "-v index" option is used alone *without* a file specified,
> > why not just do a translated device dump to the screen?
>
> We notice that rd command can manipulate the output using below options:
> rd [-adDxN][-8|-16|-32|-64]
>
> Let us know if it is recommended to duplicate above options from rd to
> dev command for manipulating screen output.
>
> We are thinking, dev -v should only be used for doing "full" raw dump
> to file. Since dev -V already shows offset and size of dump, rd -f
> can be used for more control over manipulating the dump output to
> screen or file.
That's exactly right. Duplicating the "[-adDxN][-8|-16|-32|-64]"
functionality
to the dev command would be overkill. Although, we should probably refer the user
to "rd -f" in the dev help page description of the -V option.
Agreed.
> What do you think?
I was just guessing what a typical user would actually do with the device data file?
And so I thought that maybe the typical/default HEXADECIMAL/ASCII_ENDLINE
display might be useful as a simple quick-and-dirty option. I'll leave that
up to you.
Agreed.
By default, if file is not provided, then "full" dump will be output to
screen with DISPLAY_64 | HEXADECIMAL | ASCII_ENDLINE flags.
Otherwise, "full" dump will be written to file with DISPLAY_RAW flag.
Thanks,
Surendra
1903
days inactive
1907
days old
devel@lists.crash-utility.osci.io
10 comments
2 participants
participants (2)
-
Dave Anderson -
Surendra Mobiya