[Crash-utility] crash version 4.0-2.11 is available
Dave Anderson
anderson at redhat.com
Fri Nov 11 14:22:59 UTC 2005
Badari Pulavarty wrote:
> On Thu, 2005-11-10 at 15:26 -0800, Badari Pulavarty wrote:
> > On Thu, 2005-11-10 at 16:59 -0500, Dave Anderson wrote:
> > >
> > > Adapted a number of proposed patches:
> > > - Badari Pulavarty of IBM's implentation of support for 2.6.14
> > > ppc64 kernel's use of 4-level page tables.
> > > - Added a new "extensions" sub-directory for collecting crash
> > > command extension libaries; initially populated with the sample
> > > "echo.c" from the extend help page, along with a device-mapper
> > > related "dminfo.c" module from NEC.
> > > - Castor Fu of 3PAR's implementation of support for LKCD version
> > > 10,
> > > as well the handling of single-bit errors in LKCD compressed
> > > pages by trying out all possible single-bit errors. Also his
> > > fixes for better recognizing -fomit-frame-pointer kernel builds,
> > > a stronger defense against potential bogus processor numbers
> > > associated with tasks in dumpfiles, and a fix to re-allow crash
> > > builds for gcc 2.x compilers.
> > > Fix for potential "vmcore: initialization failed" fatal error
> > > during
> > > initializaton when using more than just a vmlinux and vmcore
> > > command
> > > line arguments.
> > > Fix for diskdump.c compile failures using gcc 2.96.
> > > Update to the x86_64 pseudo-backtrace code to show as a frame the
> > > RSP, RIP and name of the function causing a kernel-mode exception
> > > frame.
> > > Fix for the x86_64 pseudo-backtrace code to not neglect to show
> > > the
> > > user-mode exception frame when that task subsequently took a
> > > kernel-mode exception.
> > > Exported the load_extension() and unload_extension() functions so
> > > that they can be called from an extension library.
> > >
> >
> > 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
>
> "kmem_cache_s" got renamed to "kmem_cache" in the latest git :(
> Time to update crash again .. :(
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20051111/2c1fca95/attachment.htm>
More information about the Crash-utility
mailing list