[PATCH] help: Introduce -i option to dump dmi_ident[] data
by Aaron Tomlin
This patch introduces a '-i' option to the 'help' command to allow the user
to conveniently display the DMI (Desktop Management Interface) table,
if available. For example:
crash> help -i
dmi_ident[1]: LENOVO
dmi_ident[2]: GIET75WW (2.25 )
dmi_ident[3]: 06/24/2014
dmi_ident[4]: LENOVO
dmi_ident[5]: 20AMS22U0C
dmi_ident[6]: ThinkPad X240
dmi_ident[7]: PC00CDZE
dmi_ident[8]: 01338439-0853-CB11-8EBB-CE1D1FC1CBC0
dmi_ident[9]: LENOVO
dmi_ident[10]: 20AMS22U0C
dmi_ident[11]: Not Defined
dmi_ident[12]: L1HF47E00T3
dmi_ident[13]: Not Available
dmi_ident[14]: LENOVO
dmi_ident[15]: 10
dmi_ident[16]: Not Available
dmi_ident[17]: PC00CDZE
dmi_ident[18]: No Asset Information
crash>
Suggested-by: Buland Singh <bsingh(a)redhat.com>
Signed-off-by: Aaron Tomlin <atomlin(a)redhat.com>
---
help.c | 35 ++++++++++++++++++++++++++++++++++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/help.c b/help.c
index 883ddd0..fb1d518 100644
--- a/help.c
+++ b/help.c
@@ -32,6 +32,7 @@ static char *output_info[];
static char *input_info[];
static char *README[];
static void dump_registers(void);
+static void dump_dmi_info(void);
#define GPLv2 2
#define GPLv3 3
@@ -523,7 +524,7 @@ cmd_help(void)
oflag = 0;
while ((c = getopt(argcnt, args,
- "efNDdmM:ngcaBbHhkKsvVoptTzLxOr")) != EOF) {
+ "efNDdmM:ngcaBbHhkKsvVoptTzLxOri")) != EOF) {
switch(c)
{
case 'e':
@@ -638,6 +639,7 @@ cmd_help(void)
fprintf(fp, " -f - filesys table\n");
fprintf(fp, " -h - hash_table data\n");
fprintf(fp, " -H - hash_table data (verbose)\n");
+ fprintf(fp, " -i - dump dmi_ident data\n");
fprintf(fp, " -k - kernel_table\n");
fprintf(fp, " -K - kernel_table (verbose)\n");
fprintf(fp, " -L - LKCD page cache environment\n");
@@ -663,6 +665,10 @@ cmd_help(void)
dump_registers();
return;
+ case 'i':
+ dump_dmi_info();
+ return;
+
default:
argerrs++;
break;
@@ -707,6 +713,32 @@ dump_registers(void)
ACTIVE() ? "a live system" : "this dumpfile type");
}
+static void
+dump_dmi_info(void)
+{
+ int i, len;
+ ulong dmi_ident_p, vaddr;
+ char buf[BUFSIZE];
+
+ if (!kernel_symbol_exists("dmi_ident")) {
+ error(INFO, "dmi_ident does not exist in this kernel\n");
+ }
+
+ dmi_ident_p = symbol_value("dmi_ident");
+ len = get_array_length("dmi_ident", NULL, 0);
+
+ for (i = 0; i < len; i++) {
+ readmem(dmi_ident_p + (sizeof(void *) * i),
+ KVADDR, &vaddr, sizeof(void *),
+ "dmi_ident", FAULT_ON_ERROR);
+
+ if (!vaddr)
+ continue;
+ read_string(vaddr, buf, BUFSIZE-1);
+ fprintf(fp, " dmi_ident[%d]: %s\n", i, buf);
+ }
+}
+
/*
* Format and display the help menu.
*/
@@ -991,6 +1023,7 @@ char *help_help[] = {
" -f - filesys table",
" -h - hash_table data",
" -H - hash_table data (verbose)",
+" -i - dump dmi_ident data",
" -k - kernel_table",
" -K - kernel_table (verbose)",
" -L - LKCD page cache environment",
--
2.4.3
9 years
- 1
- 0
Re: [Crash-utility] crash and upstream arm kernel
by Dave Anderson
----- Original Message -----
> On 11/29/15 at 10:52pm, Dave Young wrote:
> [snip]
>
> With the new build it fails at later point, but I noticed I enabled
> CONFIG_DEBUG_INFO_REDUCED=y
>
> A retest without CONFIG_DEBUG_INFO_REDUCED succeed with latest latest
> crash build, but there's some read errors. I'm not sure if they matters
> but "bt" works well in crash.
>
> [snip]
> 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 "armv7l-unknown-linux-gnueabihf"...
>
> please wait... (gathering kmem slab cache data)
> crash: read error: kernel virtual address: ff7fb414 type: "array cache
> limit"
>
> crash: kmem_cache: df1e34c0: invalid array_cache pointer: ff7fb410
>
> crash: read error: kernel virtual address: ff7fac08 type: "array cache
> limit"
>
> crash: kmem_cache: df1e3540: invalid array_cache pointer: ff7fac04
>
> crash: read error: kernel virtual address: ff7f7edc type: "array cache
> limit"
>
> crash: kmem_cache: df1e35c0: invalid array_cache pointer: ff7f7ed8
>
> crash: read error: kernel virtual address: ff7f7cec type: "array cache
> limit"
>
> crash: kmem_cache: df1e3640: invalid array_cache pointer: ff7f7ce8
>
> crash: read error: kernel virtual address: ff7f7c04 type: "array cache
> limit"
>
> crash: kmem_cache: df1e36c0: invalid array_cache pointer: ff7f7c00
>
> crash: read error: kernel virtual address: ff7f7894 type: "array cache
> limit"
>
> crash: kmem_cache: df1e3740: invalid array_cache pointer: ff7f7890
>
> crash: read error: kernel virtual address: ff7f77ac type: "array cache
> limit"
>
> crash: kmem_cache: df1e37c0: invalid array_cache pointer: ff7f77a8
>
> crash: read error: kernel virtual address: ff7f76c4 type: "array cache
> limit"
>
> crash: kmem_cache: df1e3840: invalid array_cache pointer: ff7f76c0
>
> crash: read error: kernel virtual address: ff7f74d4 type: "array cache
> limit"
>
> crash: kmem_cache: df1e38c0: invalid array_cache pointer: ff7f74d0
>
> crash: read error: kernel virtual address: ff7f73ec type: "array cache
> limit"
>
> crash: kmem_cache: df1e3940: invalid array_cache pointer: ff7f73e8
>
> crash: read error: kernel virtual address: ff7f7304 type: "array cache
> limit"
>
> crash: kmem_cache: df1e39c0: invalid array_cache pointer: ff7f7300
>
> crash: read error: kernel virtual address: ff7f707c type: "array cache
> limit"
>
> crash: kmem_cache: df1e3a40: invalid array_cache pointer: ff7f7078
>
> crash: read error: kernel virtual address: ff7f6e8c type: "array cache
> limit"
>
> crash: kmem_cache: df1e3ac0: invalid array_cache pointer: ff7f6e88
>
> crash: read error: kernel virtual address: ff7f6c9c type: "array cache
> limit"
>
> crash: kmem_cache: df1e3b40: invalid array_cache pointer: ff7f6c98
>
> crash: read error: kernel virtual address: ff7f6aac type: "array cache
> limit"
>
> crash: kmem_cache: df1e3bc0: invalid array_cache pointer: ff7f6aa8
>
> crash: read error: kernel virtual address: ff7f68bc type: "array cache
> limit"
>
> crash: kmem_cache: df1e3c40: invalid array_cache pointer: ff7f68b8
>
> crash: read error: kernel virtual address: ff7f67d4 type: "array cache
> limit"
>
> crash: kmem_cache: df1e3cc0: invalid array_cache pointer: ff7f67d0
>
> crash: read error: kernel virtual address: ff7f65e4 type: "array cache
> limit"
>
> crash: kmem_cache: df1e3d40: invalid array_cache pointer: ff7f65e0
>
> crash: read error: kernel virtual address: ff7f63f4 type: "array cache
> limit"
>
> crash: kmem_cache: df1e3dc0: invalid array_cache pointer: ff7f63f0
>
> crash: read error: kernel virtual address: ff7f6204 type: "array cache
> limit"
>
> crash: kmem_cache: df1e3e40: invalid array_cache pointer: ff7f6200
>
> crash: read error: kernel virtual address: ff7f6014 type: "array cache
> limit"
>
> crash: kmem_cache: df1e3ec0: invalid array_cache pointer: ff7f6010
>
> crash: read error: kernel virtual address: ff7f5e0c type: "array cache
> limit"
>
> crash: kmem_cache: df1e3f40: invalid array_cache pointer: ff7f5e08
>
> crash: read error: kernel virtual address: ff7f5b04 type: "array cache
> limit"
>
> crash: kmem_cache: df017040: invalid array_cache pointer: ff7f5b00
>
> crash: read error: kernel virtual address: ff7f57e0 type: "array cache
> limit"
>
> crash: kmem_cache: df0170c0: invalid array_cache pointer: ff7f57dc
>
> crash: read error: kernel virtual address: ff7f5300 type: "array cache
> limit"
>
> crash: kmem_cache: df017140: invalid array_cache pointer: ff7f52fc
>
> crash: read error: kernel virtual address: ff7f50ec type: "array cache
> limit"
>
> crash: kmem_cache: df0171c0: invalid array_cache pointer: ff7f50e8
>
> crash: read error: kernel virtual address: ff7f4004 type: "array cache
> limit"
>
> crash: kmem_cache: df017240: invalid array_cache pointer: ff7f4000
> WARNING: SLAB: cannot determine how compound pages are linked
>
> KERNEL: vmlinux
> DUMPFILE: /var/crash/127.0.0.1-2015-11-30-13:10:23/vmcore
> CPUS: 1
> DATE: Mon Nov 30 13:10:14 2015
> UPTIME: 00:00:38
> LOAD AVERAGE: 0.27, 0.08, 0.03
> TASKS: 157
> NODENAME: localhost
> RELEASE: 4.4.0-rc2+
> VERSION: #46 SMP Mon Nov 30 12:58:47 CST 2015
> MACHINE: armv7l (unknown Mhz)
> MEMORY: 510 MB
> PANIC: "sysrq: SysRq : Trigger a crash"
> PID: 1368
> COMMAND: "bash"
> TASK: ddbbeb40 [THREAD_INFO: ddbc4000]
> CPU: 0
> STATE: TASK_RUNNING (SYSRQ)
>
> crash> bt
> PID: 1368 TASK: ddbbeb40 CPU: 0 COMMAND: "bash"
> #0 [<c021e23c>] (sysrq_handle_crash) from [<c021e5a5>]
> #1 [<c021e5a5>] (__handle_sysrq) from [<c021e969>]
> #2 [<c021e969>] (write_sysrq_trigger) from [<c01067df>]
> #3 [<c01067df>] (proc_reg_write) from [<c00ca5db>]
> #4 [<c00ca5db>] (__vfs_write) from [<c00cac0f>]
> #5 [<c00cac0f>] (vfs_write) from [<c00cb24b>]
> #6 [<c00cb24b>] (sys_write) from [<c000ddc1>]
> crash>
>
> > Can you send me the location of the vmlinux and vmcore files offline? I can
> > try working with them tomorrow with on an x86_64 host with a crash utility
> > built with "make target=ARM".
>
> Will save the files somewhere and let you know..
>
> Thanks a lot
> Dave
>
Dave,
OK, so the problem is that in CONFIG_SLAB kernels, the array_cache
structure that is pointed to by each kmem_cache.cpu_cache can now
be a vmalloc'd memory location. That may be a new innovation for
32-bit kernels? I don't know, but in any case, all of these error
types:
crash: kmem_cache: df1e34c0: invalid array_cache pointer: ff7fb410
show array_cache pointers in the vmalloc region. The kmem_cache.cpu_cache
pointer is actually a per_cpu pointer, but on some of the kmem slab caches,
the translation of the per_cpu pointer result in a vmalloc() address instead
of a unity-mapped address. Perhaps there's a point at which the percpu
memory allocations switch from being unity-mapped structures to being
vmalloc()'d addresses?
In any case, at the point in time when the kmem caches are being
initialized (when the error messages get generated), the 32-bit ARM
arch has not yet set the base address of the vmalloc region in one
if its machine-dependent variables. And so the addresses are
mistakenly translated as if they are unity-mapped. The ARM arch
sets the internal vmalloc base address variable at a later point
in time, but it can be done earlier, before the kmem cache initialization
is started. So with this one-line patch, the dumpfile comes up cleanly:
--- arm.c.orig 2015-12-01 16:36:11.815775008 -0500
+++ arm.c 2015-12-01 16:25:44.580800293 -0500
@@ -1539,6 +1539,7 @@
static ulong
arm_vmalloc_start(void)
{
+ machdep->machspec->vmalloc_start_addr = vt->high_memory;
return vt->high_memory;
}
$ crash vmlinux vmcore-cp
crash 7.1.4rc21
Copyright (C) 2002-2014 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-elf-linux"...
KERNEL: vmlinux
DUMPFILE: vmcore-cp
CPUS: 1
DATE: Mon Nov 30 00:10:14 2015
UPTIME: 00:00:38
LOAD AVERAGE: 0.27, 0.08, 0.03
TASKS: 157
NODENAME: localhost
RELEASE: 4.4.0-rc2+
VERSION: #46 SMP Mon Nov 30 12:58:47 CST 2015
MACHINE: armv7l (unknown Mhz)
MEMORY: 510 MB
PANIC: "sysrq: SysRq : Trigger a crash"
PID: 1368
COMMAND: "bash"
TASK: ddbbeb40 [THREAD_INFO: ddbc4000]
CPU: 0
STATE: TASK_RUNNING (SYSRQ)
crash>
I can only test the ELF vmcore because I don't have the 32-bit lzo library
installed for my "make target=ARM" x86 binary. But it won't be any
different from the one above.
I'll queue the patch for crash-7.1.4.
Thanks for the report,
Dave
9 years
- 2
- 1