Ken'ichi Ohmichi wrote:
Hi Dave,
I found the problem that the crash utility fails during the initialization.
This problem happened on i386 linux-2.6.22 like the following:
$ crash vmlinux vmcore
crash 4.0-4.4
Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007 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.
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB 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.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
crash: invalid size request: 0 type: "__per_cpu_offset"
$
The cause is that the array number of the symbol "__per_cpu_offset"
cannot be taken. In linux-2.6.21, i386's "__per_cpu_offset" is defined
in include/asm-generic/percpu.h like the following:
extern unsigned long __per_cpu_offset[NR_CPUS];
But in linux-2.6.22, it is defined in include/asm-i386/percpu.h like
the following, and the array number is not described in the debugging
information.
extern unsigned long __per_cpu_offset[];
Here is the patch for solving the problem. If the array number is not
taken, the crash utility assumes that it is the defined value NR_CPUS.
Or, should get_array_length() be fixed to get the array number from
init/main.c ?
Ken'ichi -- thanks for tracking that down.
I don't see how get_array_length() can be "fixed" in this case -- if the
vmlinux file doesn't have the info, it doesn't have it. I'm not sure
what you mean by getting it from init/main.c?
Anyway, using NR_CPUS is probably safe, although it runs the remote
risk of reading into a non-existent section of memory or uncopied
section of dumpfile.
How about using Cliff Wickman's new get_cpus_possible() function
from his LKCD_KERNTYPES patch? Since get_cpus_possible() returns 0
on failure, your fix below should be left in place, but it might be
worth also trying get_cpus_possible() if get_array_length() returns 0?
Dave
Thanks
Ken'ichi Ohmichi
--- crash-4.0-4.4.org/kernel.c 2007-07-21 04:19:23.000000000 +0900
+++ crash-4.0-4.4/kernel.c 2007-07-24 19:51:55.000000000 +0900
@@ -170,7 +170,7 @@ kernel_init()
else
i = get_array_length("__per_cpu_offset", NULL, 0);
get_symbol_data("__per_cpu_offset",
- sizeof(long)*(i <= NR_CPUS ? i : NR_CPUS),
+ sizeof(long)*((i && (i <= NR_CPUS)) ? i : NR_CPUS),
&kt->__per_cpu_offset[0]);
kt->flags |= PER_CPU_OFF;
}
_
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
