On Thu, 2005-11-10 at 16:59 -0500, Dave Anderson wrote: Something is broken on the latest version of "crash". Thanks, Badari elm3b157:~/crash-4.0-2.11 # ./crash crash 4.0-2.11 Copyright (C) 2002, 2003, 2004, 2005 Red Hat, Inc. Copyright (C) 2004, 2005 IBM Corporation Copyright (C) 1999-2005 Hewlett-Packard Co Copyright (C) 2005 Fujitsu Limited Copyright (C) 2005 NEC Corporation Copyright (C) 1999, 2002 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 "powerpc64-unknown-linux-gnu"... crash: invalid structure member offset: kmem_cache_s_num FILE: memory.c LINE: 6197 FUNCTION: kmem_cache_init() [./crash] error trace: 1009b6f8 => 100b0040 => 100c2dcc => 10142d8c 10142d8c: .OFFSET_verify+140 100c2dcc: .kmem_cache_init+324 100b0040: .vm_init+8372 1009b6f8: .main_loop+228

Badari Pulavarty wrote: Hopefully it's just a name change (again...) without other changes that will require a new kmem "version" within crash. There are basically three kmem subsystem versions supported, the really old 2.2 and early 2.4-era version, and then two subsequent versions that handle structure name and design changes, most notably the percpu cache buckets attached to each kmem slab cache. So in the code, for example, after vm_init() digs out what's there, it does this: if (vt->flags & PERCPU_KMALLOC_V1) vt->dump_kmem_cache = dump_kmem_cache_percpu_v1; else if (vt->flags & PERCPU_KMALLOC_V2) vt->dump_kmem_cache = dump_kmem_cache_percpu_v2; else vt->dump_kmem_cache = dump_kmem_cache; and then, for any subsquent "kmem -[sS]" command entered, the proper handler will be used. I'm hoping that PERCPU_KMALLOC_V2 will still work, and the only thing needing changes are the MEMBER_OFFSET_INIT(), STRUCT_SIZE_INIT() and ARRAY_LENGTH_INIT() calls for all the kmem_cache data structure members required. So for example, this initialization quietly failed (loaded a -1) during vm_init(): MEMBER_OFFSET_INIT(kmem_cache_s_num, "kmem_cache_s", "num"); and when it was subsequently used in kmem_cache_init(), the fatal error occurred. Rather than creating new offset_table[], size_table[] and array_table[] entries for each kmem_cache_s member required, and therefore having to deal with each subsequent OFFSET(), SIZE() and ARRAY_LENGTH() macro using them, it's probably worth just re-using the current "kmem_cache_s_xxx" entries. So the initialization above could be re-done like this: MEMBER_OFFSET_INIT(kmem_cache_s_num, "kmem_cache_s", "num"); if (INVALID_MEMBER(kmem_cache_s_num)) MEMBER_OFFSET_INIT(kmem_cache_s_num, "kmem_cache", "num"); And the same would have to be done for all the other required kmem_cach_s members, as well as for the ARRAY_LENGTH_INIT() and STRUCT_SIZE_INIT(). If you enter "help -o" you'll see all the entries of the three tables. Those that are populated with -1 are not applicable to that kernel. If they are subsequently used, the error you saw above occurs. Because the one you see happens during crash initialization, it shuts down the session. However, in the case of kmem_cache initialization, since it's not absolutely required for the crash session to continue, you can add "--no_kmem_cache" on the crash command line, and it will continue to initialize. But any kmem_cache-related command will not be allowed. If you give an optional string pattern to "help -o", you will see just those entries that match, instead of all ~500 entries. So, taking a 2.6.9 kernel, here's what was initialized for the kmem_cache_s structure entries needed: crash> help -o kmem_cache offset_table: kmem_cache_s_c_nextp: -1 kmem_cache_s_c_name: -1 kmem_cache_s_c_num: -1 kmem_cache_s_c_org_size: -1 kmem_cache_s_c_flags: -1 kmem_cache_s_c_offset: -1 kmem_cache_s_c_firstp: -1 kmem_cache_s_c_gfporder: -1 kmem_cache_s_c_magic: -1 kmem_cache_s_c_align: -1 kmem_cache_s_num: 184 kmem_cache_s_next: 244 kmem_cache_s_name: 240 kmem_cache_s_objsize: 176 kmem_cache_s_flags: 180 kmem_cache_s_gfporder: 200 kmem_cache_s_slabs: -1 kmem_cache_s_slabs_full: -1 kmem_cache_s_slabs_partial: -1 kmem_cache_s_slabs_free: -1 kmem_cache_s_cpudata: -1 kmem_cache_s_colour_off: 212 kmem_cache_s_array: 0 kmem_cache_s_lists: 136 size_table: kmem_cache_s: 252 array_table: kmem_cache_s_name: 0 kmem_cache_s_c_name: 0 kmem_cache_s_array: 32 kmem_cache_s_cpudata: 0 crash> Again, the -1 entries are for older kernels and are irrelevant. It's just the initialization for the other 11 entries that are non-zero need to be addressed, hopefully by just using the bait-and-switch method shown above. Clear as mud? Dave

==> Regarding Re: [Crash-utility] crash version 4.0-2.11 is available; Dave Anderson <anderson(a)redhat.com&gt; adds: anderson> Hopefully it's just a name change (again...) without other anderson> changes that will require a new kmem "version" within crash. Here's the git log: Author: Pekka J Enberg <penberg(a)cs.Helsinki.FI&gt; Date: Mon Nov 7 00:58:01 2005 -0800 [PATCH] mm: rename kmem_cache_s to kmem_cache This patch renames struct kmem_cache_s to kmem_cache so we can start using it instead of kmem_cache_t typedef. Signed-off-by: Pekka Enberg <penberg(a)cs.helsinki.fi&gt; Signed-off-by: Andrew Morton <akpm(a)osdl.org&gt; Signed-off-by: Linus Torvalds <torvalds(a)osdl.org&gt; Sounds like just a name change to me. -Jeff