[ANNOUNCE] crash version 5.0.2 is available
by Dave Anderson
- Fix for the "mod -[sS]" command if the attempt to load a kernel
module fails due to an internal gdb error. Without the patch, the
"mod" command displays error messages of the sort:
*** glibc detected *** crash: double free or corruption (!prev): <address> ***
<segmentation violation in gdb>
mod: <module-name>
gdb add-symbol-file command failed
and then hangs. With the patch, a module-related error message is
displayed, the "mod" command fails, and the session continues.
(anderson(a)redhat.com)
- Fix for the "mod -[sS]" command options, which may display the error
message "mod: <module>: last symbol is not _MODULE_END_<module>?"
for one or more modules. That message indicates that the module's
symbol values have been incorrectly modified by the "mod" command,
and even if the error message is not displayed, it is still possible
that the symbol values of some modules may have been incorrectly
modified. With the fix, the "mod -[sS] command will not recalculate
and modify module symbol values from their CONFIG_KALLSYMS-generated
values.
(anderson(a)redhat.com)
- Fix for the reading of dumpfiles created with the "snap" extension
module when used on an x86 machine with a single PT_LOAD segment that
starts at a non-zero address. Without the patch, a crash session
with such an x86 snapshot dumpfile fails during initialization with
the error message "crash: vmlinux and <snapshot> do not match!"
(anderson(a)redhat.com)
- Fixes for several bugs in the s390 and s390x stack backtrace code:
(1) Add panic stack as second interrupt stack
(2) Fix printing of access registers (4 bytes instead of 8 bytes)
(3) Use u64 for s390x register 14
(4) Fix interrupt stack handling for s390x (use 160 byte overhead
instead of 96)
(holzheu(a)linux.vnet.ibm.com)
- Fix for the "mach -m" command option on x86 or x86_64 systems whose
BIOS-provided e820 map contains EFI-related memory type value that
has not been mapped to an E820 type (pre-2.6.27), or if the type is
E820_UNUSABLE (2.6.28 and later). Without the patch, the "mach -m"
command would result in a segmentation violation. With the fix,
an EFI type will be displayed as "type <number>" on pre-2.6.27
kernels, and the mapped E820 type on 2.6.27 and later kernels.
(anderson(a)redhat.com)
- Fix for SIAL extension module if a script uses structures that
contain members of type "bool". Without the patch, running such
a script fails with the error message "File <filename>, line 279,
Error: Oops drilldowntype".
(holzheu(a)linux.vnet.ibm.com)
- Fix to prevent a stream of harmless but annoying error messages when
running "crash -d4" (or any larger -d debug value) on x86 machines.
Without the patch, after the "crash: get_cpus_online: online: <cpus>"
debug message, there are a stream of "crash: input string too large:"
and "crash: invalid input:" messages prior to the next legitimate debug
message.
(anderson(a)redhat.com)
- Fix for the "kmem -s list" command option on non-CONFIG_SLUB kernels
that contain a "cache_chain" list_head symbol instead of having a
"#define cache_chain (cache_cache.next)" construct. Without the
patch, the command would incorrectly presume that the "cache_chain"
address was that of a kmem_cache structure, may display a warning
message "kmem: WARNING: cannot read kmem_cache_s.name string at
<address>", and then show the "cache_chain" symbol address followed
either by a name of "(unknown)" or by a string of gibberish.
(anderson(a)redhat.com)
- Fix for the x86_64 "bt" command to recognize, and take advantage of,
kernels that were built with CONFIG_FRAME_POINTER. In that case, the
frame pointer values pushed onto the kernel stack are now used to
calculate stack frame sizes, resulting in more accurate backtraces.
(anderson(a)redhat.com)
- Change the ppc64 cpu count displayed by the initial system banner
and by the "sys" and "mach" commands to be the number of cpus online.
(lnx1138(a)linux.vnet.ibm.com)
- Fix for the x86_64 "bt" command's stack frame size calculator on
kernels that were built without CONFIG_FRAME_POINTER. Without the
patch, in the relatively rare case where a function does a "retq"
prior to the targeted text return address, the frame size calculation
could be too small, which in turn could result in an intervening,
stale, frame entry.
(anderson(a)redhat.com)
- Fix to prevent a crash session that is run over a network connection
that is killed/removed from going into 100% cpu-time loop. Without
the patch, the behavior of the built-in readline() library call in
gdb-7.0 has changed such that the function returns when the EOF is
encountered on /dev/tty, and the crash session goes into an endless
loop; whereas in gdb-6.1, the readline() call never returns because
the crash session gets killed while running in the library code.
(anderson(a)redhat.com)
- Change the output of "ps -t" to display the task_struct's utime and
stime values unmodified on kernels using a cputime_t (unsigned long)
to store those values.
(anderson(a)redhat.com)
- Fix for the x86 "bt" command if the kdump-generated NMI interrupts
a process in kernel space at a pointer before the full user-mode
exception frame (pt_regs) gets written on the kernel stack. Without
the patch, the backtrace attempt would display "bt: cannot resolve
stack trace", dump the text symbols on the kernel stack, and would
not find/display a "USER-MODE" exception frame; the fix simply shows
the interrupted entry-point function name and stack pointer.
(anderson(a)redhat.com)
- Fix for the "bt -e" command on 2.6.30 or later x86 kernels if the
x86.c file was built with D_FORTIFY_SOURCE. Without the patch, the
command would cause the crash session to abort with the error message
"*** buffer overflow detected ***: crash terminated".
(anderson(a)redhat.com)
- Fix for initialization-time failure on 2.6.34 and later kernels that
were configured with CONFIG_NO_BOOTMEM. Without the patch, the crash
session fails with the error message "crash: invalid structure member
offset: pglist_data_bdata".
(anderson(a)redhat.com)
- Fix for the processor speed value displayed on ppc and ppc64 machines
at session invocation, and by the "sys" and "mach" commands. Without
the patch, Power6 machines indicate "(unknown Mhz)".
(pavan(a)linux.vnet.ibm.com)
- Implemented support to recognize an IBM-proposed kernel patch for
ppc64 CONFIG_SPARSEMEM_VMEMMAP kernels that will store vmemmap page
mapping information. Currently on 2.6.26 and later ppc64 kernels
configured with CONFIG_SPARSEMEM_VMEMMAP, there is an initialization
time warning message indicating "WARNING: cannot translate vmemmap
kernel virtual addresses: commands requiring page structure contents
will fail", alerting the user that vmemmap'd page structures cannot
be accessed. When the kernel patch is eventually applied, this patch
will recognize it and be able to translate vmemmap'd kernel virtual
addresses.
(anderson(a)redhat.com)
- Fix for "kmem -[sS]" command options on live CONFIG_SLAB systems to
prevent the redundant reading of the shared array_cache object list
from the per-node kmem_list3 data structures. Without the patch, it
is possible that there could be a series of error messages indicating
"kmem: <cache-name> cache: total shared array_cache.avail <number>
greater than total limit <number>", followed by "*** glibc detected
*** crash: double free or corruption (!prev): <address> ***", a
backtrace, and the abort of the crash session.
(anderson(a)redhat.com)
Download from: http://people.redhat.com/anderson
14 years, 10 months
Re: [Crash-utility] [PATCH] Fix display processor speed on ppc/ppc64
by Dave Anderson
----- "Pavan Naregundi" <pavan(a)linux.vnet.ibm.com> wrote:
>
> On Thu, 2010-03-25 at 09:03 -0400, Dave Anderson wrote:
>
> >
> > Thanks for checking that.
> >
> > Can you resend this patch as an attachment instead of inlining it?
> > You can see below that it has wrapped in several locations, but even
> > if I try to resurrect it, I'm still having trouble getting it to
> > apply.
>
> Attaching the patch.. Patch is generated against crash-5.0.1..
Got it -- looks good. Queued for the next release.
Thanks,
Dave
14 years, 10 months
Re: [Crash-utility] [PATCH] Fix display processor speed on ppc/ppc64
by Dave Anderson
----- "Dave Anderson" <anderson(a)redhat.com> wrote:
>
> Thanks for checking that.
>
> Can you resend this patch as an attachment instead of inlining it?
> You can see below that it has wrapped in several locations, but even
> if I try to resurrect it, I'm still having trouble getting it to
> apply.
>
> Thanks again,
> Dave
In other words, if I fix the 18 line wraps in the ppc64.c section,
I still end up with this on the last chunk:
# patch -p1 --dry-run < /home/boston/anderson/Desktop/processor.patch
patching file ppc64.c
Hunk #3 FAILED at 827.
1 out of 3 hunks FAILED -- saving rejects to file ppc64.c.rej
patching file ppc.c
#
14 years, 10 months
Re: [Crash-utility] [PATCH] Fix display processor speed on ppc/ppc64
by Dave Anderson
----- "Pavan Naregundi" <pavan(a)linux.vnet.ibm.com> wrote:
> On Wed, 2010-03-24 at 09:31 -0400, Dave Anderson wrote:
>
> >
> > This patch doesn't seem like it would be backwards-compatible for older
> > systems which do *not* have the "have_of" symbol. Can you confirm
> > that this patch will still work for them?
> >
> > Thanks,
> > Dave
>
> Hi Dave,
>
> I think systems you are referring are, systems which do not have OF. I
> don't have a system of that type here to test.. Just to be safe I have
> prepared a new patch..
>
> Changes are, patch assumes that system is having the OF and tries to
> find the processor speed.. If the speed was not found, then if would go
> will the code of finding the processor speed in system without OF. I
> think this will makes sure of backwards-compatibility in older
> system.
>
> Thanks
> Pavan
Thanks for checking that.
Can you resend this patch as an attachment instead of inlining it?
You can see below that it has wrapped in several locations, but even
if I try to resurrect it, I'm still having trouble getting it to apply.
Thanks again,
Dave
>
> ---
> diff -Naur a/ppc64.c b/ppc64.c
> --- a/ppc64.c 2010-03-25 10:47:54.000000000 +0530
> +++ b/ppc64.c 2010-03-25 10:48:15.000000000 +0530
> @@ -742,7 +742,7 @@
> ppc64_processor_speed(void)
> {
> ulong res, value, ppc_md, md_setup_res;
> - ulong we_have_of, prep_setup_res;
> + ulong prep_setup_res;
> ulong node, type, name, properties;
> char str_buf[32];
> uint len;
> @@ -751,22 +751,7 @@
> if (machdep->mhz)
> return(machdep->mhz);
>
> - /* first, check if the have_of variable a) exists, and b) is
> TRUE */
> - if(symbol_exists("have_of")) {
> - get_symbol_data("have_of", sizeof(void *),
> &we_have_of);
> - } else {
> - we_have_of = 0;
> - }
> -
> - if(we_have_of) {
> - /* we have a machine with open firmware, so search
> the
> OF nodes
> - * for cpu nodes.
> - * Too bad we can't call kernel helper functions
> here :)
> - */
> -
> - if(!symbol_exists("allnodes"))
> - return (machdep->mhz = 0);
> -
> + if(symbol_exists("allnodes")) {
> get_symbol_data("allnodes", sizeof(void *), &node);
> while(node) {
> readmem(node+OFFSET(device_node_type),
> @@ -842,54 +827,54 @@
> }
> if(!properties) {
> /* didn't find the cpu speed for
> some
> reason */
> - mhz = 0;
> + return (machdep->mhz = 0);
> }
> }
> - } else {
> - /* for machines w/o OF */
> - /* untested, but in theory this should work on prep
> machines */
> + }
>
> - if (symbol_exists("res")) {
> - get_symbol_data("res", sizeof(void *),
> &res);
> + /* for machines w/o OF */
> + /* untested, but in theory this should work on prep machines
> */
>
> - if (symbol_exists("prep_setup_residual")) {
> -
> get_symbol_data("prep_setup_residual",
> - sizeof(void *),
> &prep_setup_res);
> - get_symbol_data("ppc_md",
> sizeof(void
> *),
> - &ppc_md);
> - readmem(ppc_md +
> -
> OFFSET(machdep_calls_setup_residual),
> - KVADDR, &md_setup_res,
> - sizeof(ulong), "ppc_md
> setup_residual",
> - FAULT_ON_ERROR);
> -
> - if(prep_setup_res == md_setup_res) {
> - /* PREP machine */
> - readmem(res+
> -
> OFFSET(RESIDUAL_VitalProductData)+
> - OFFSET(VPD_ProcessorHz),
> - KVADDR, &mhz,
> sizeof(ulong),
> - "res VitalProductData",
> - FAULT_ON_ERROR);
> + if (symbol_exists("res") && !mhz) {
> + get_symbol_data("res", sizeof(void *), &res);
>
> - mhz = (mhz > 1024) ? mhz >>
> 20 : mhz;
> - }
> - }
> + if (symbol_exists("prep_setup_residual")) {
> + get_symbol_data("prep_setup_residual",
> + sizeof(void *), &prep_setup_res);
> + get_symbol_data("ppc_md", sizeof(void *),
> + &ppc_md);
> + readmem(ppc_md +
> + OFFSET(machdep_calls_setup_residual),
> + KVADDR, &md_setup_res,
> + sizeof(ulong), "ppc_md
> setup_residual",
> + FAULT_ON_ERROR);
>
> - if(!mhz) {
> - /* everything else seems to do this the
> same
> way... */
> - readmem(res +
> - OFFSET(bd_info_bi_intfreq),
> - KVADDR, &mhz, sizeof(ulong),
> - "bd_info bi_intfreq",
> FAULT_ON_ERROR);
> + if(prep_setup_res == md_setup_res) {
> + /* PREP machine */
> + readmem(res+
> + OFFSET(RESIDUAL_VitalProductData)+
> + OFFSET(VPD_ProcessorHz),
> + KVADDR, &mhz, sizeof(ulong),
> + "res VitalProductData",
> + FAULT_ON_ERROR);
>
> - mhz /= 1000000;
> - }
> - }
> - /* else...well, we don't have OF, or a residual
> structure, so
> - * just print unknown MHz
> - */
> - }
> + mhz = (mhz > 1024) ? mhz >> 20 : mhz;
> + }
> + }
> +
> + if(!mhz) {
> + /* everything else seems to do this the same
> way... */
> + readmem(res +
> + OFFSET(bd_info_bi_intfreq),
> + KVADDR, &mhz, sizeof(ulong),
> + "bd_info bi_intfreq",
> FAULT_ON_ERROR);
> +
> + mhz /= 1000000;
> + }
> + }
> + /* else...well, we don't have OF, or a residual structure,
> so
> + * just print unknown MHz
> + */
>
> return (machdep->mhz = (ulong)mhz);
> }
> diff -Naur a/ppc.c b/ppc.c
> --- a/ppc.c 2010-03-25 10:47:54.000000000 +0530
> +++ b/ppc.c 2010-03-25 10:48:15.000000000 +0530
> @@ -461,7 +461,7 @@
> ppc_processor_speed(void)
> {
> ulong res, value, ppc_md, md_setup_res;
> - ulong we_have_of, prep_setup_res;
> + ulong prep_setup_res;
> ulong node, type, name, properties;
> char str_buf[16];
> ulong len, mhz = 0;
> @@ -469,22 +469,7 @@
> if (machdep->mhz)
> return(machdep->mhz);
>
> - /* first, check if the have_of variable a) exists, and b) is TRUE
> */
> - if(symbol_exists("have_of")) {
> - get_symbol_data("have_of", sizeof(void *), &we_have_of);
> - } else {
> - we_have_of = 0;
> - }
> -
> - if(we_have_of) {
> - /* we have a machine with open firmware, so search the OF nodes
> - * for cpu nodes.
> - * Too bad we can't call kernel helper functions here :)
> - */
> -
> - if(!symbol_exists("allnodes"))
> - return (machdep->mhz = 0);
> -
> + if(symbol_exists("allnodes")) {
> get_symbol_data("allnodes", sizeof(void *), &node);
> while(node) {
> readmem(node+OFFSET(device_node_type),
> @@ -545,54 +530,53 @@
> }
> if(!properties) {
> /* didn't find the cpu speed for some reason */
> - mhz = 0;
> + return (machdep->mhz = 0);
> }
> }
> - } else {
> - /* for machines w/o OF */
> - /* untested, but in theory this should work on prep machines */
> + }
> + /* for machines w/o OF */
> + /* untested, but in theory this should work on prep machines */
>
> - if (symbol_exists("res")) {
> - get_symbol_data("res", sizeof(void *), &res);
> + if (symbol_exists("res") && !mhz) {
> + get_symbol_data("res", sizeof(void *), &res);
>
> - if (symbol_exists("prep_setup_residual")) {
> - get_symbol_data("prep_setup_residual",
> - sizeof(void *), &prep_setup_res);
> - get_symbol_data("ppc_md", sizeof(void *),
> - &ppc_md);
> - readmem(ppc_md +
> - OFFSET(machdep_calls_setup_residual),
> - KVADDR, &md_setup_res,
> - sizeof(ulong), "ppc_md setup_residual",
> - FAULT_ON_ERROR);
> + if (symbol_exists("prep_setup_residual")) {
> + get_symbol_data("prep_setup_residual",
> + sizeof(void *), &prep_setup_res);
> + get_symbol_data("ppc_md", sizeof(void *),
> + &ppc_md);
> + readmem(ppc_md +
> + OFFSET(machdep_calls_setup_residual),
> + KVADDR, &md_setup_res,
> + sizeof(ulong), "ppc_md setup_residual",
> + FAULT_ON_ERROR);
>
> - if(prep_setup_res == md_setup_res) {
> - /* PREP machine */
> - readmem(res+
> - OFFSET(RESIDUAL_VitalProductData)+
> - OFFSET(VPD_ProcessorHz),
> - KVADDR, &mhz, sizeof(ulong),
> - "res VitalProductData",
> - FAULT_ON_ERROR);
> + if(prep_setup_res == md_setup_res) {
> + /* PREP machine */
> + readmem(res+
> + OFFSET(RESIDUAL_VitalProductData)+
> + OFFSET(VPD_ProcessorHz),
> + KVADDR, &mhz, sizeof(ulong),
> + "res VitalProductData",
> + FAULT_ON_ERROR);
>
> - mhz = (mhz > 1024) ? mhz >> 20 : mhz;
> - }
> + mhz = (mhz > 1024) ? mhz >> 20 : mhz;
> }
> + }
>
> - if(!mhz) {
> - /* everything else seems to do this the same way... */
> - readmem(res +
> - OFFSET(bd_info_bi_intfreq),
> - KVADDR, &mhz, sizeof(ulong),
> - "bd_info bi_intfreq", FAULT_ON_ERROR);
> + if(!mhz) {
> + /* everything else seems to do this the same way... */
> + readmem(res +
> + OFFSET(bd_info_bi_intfreq),
> + KVADDR, &mhz, sizeof(ulong),
> + "bd_info bi_intfreq", FAULT_ON_ERROR);
>
> - mhz /= 1000000;
> - }
> + mhz /= 1000000;
> }
> - /* else...well, we don't have OF, or a residual structure, so
> - * just print unknown MHz
> - */
> }
> + /* else...well, we don't have OF, or a residual structure, so
> + * just print unknown MHz
> + */
>
> return (machdep->mhz = mhz);
> }
14 years, 10 months
Re: [Crash-utility] [PATCH] Fix display processor speed on ppc/ppc64
by Dave Anderson
----- "Pavan Naregundi" <pavan(a)linux.vnet.ibm.com> wrote:
> Hi Everyone,
>
> On Power6 crash displays "MACHINE: ppc64 (unknown Mhz)" for processor
> speed upon initialization and by the "sys" sub-command.
>
> # crash
>
> crash 5.0.1
> Copyright (C) 2002-2010 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 (GDB) 7.0
> Copyright (C) 2009 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 "powerpc64-unknown-linux-gnu"...
>
> KERNEL: /boot/vmlinux-2.6.32.9-0.5-ppc64
> DUMPFILE: /dev/mem
> CPUS: 5
> DATE: Thu Mar 18 03:13:59 2010
> UPTIME: 04:11:31
> LOAD AVERAGE: 0.34, 0.15, 0.05
> TASKS: 319
> NODENAME: brucelp3
> RELEASE: 2.6.32.9-0.5-ppc64
> VERSION: #1 SMP 2010-03-15 12:22:00 +0100
> MACHINE: ppc64 (unknown Mhz) ======> display unknown Mhz
> MEMORY: 1 GB
> PID: 17788
> COMMAND: "crash"
> TASK: c00000003ae58b80 [THREAD_INFO: c00000003df68000]
> CPU: 6
> STATE: TASK_RUNNING (ACTIVE)
> =====================
>
> When investigated this issue was absence of 'have_of' symbol in current
> kernels. Below is the commit which removed the support of 'have_of'.
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit...
>
>
> This patch overcomes the use of 'have_of' variable.. Please review this
> patch..
>
> Regards,
> Pavan
> IBM Linux Technology Center
This patch doesn't seem like it would be backwards-compatible for older
systems which do *not* have the "have_of" symbol. Can you confirm
that this patch will still work for them?
Thanks,
Dave
>
> ---
> diff -Naur a/ppc64.c b/ppc64.c
> --- a/ppc64.c 2010-03-24 10:14:33.000000000 +0530
> +++ b/ppc64.c 2010-03-24 10:14:51.000000000 +0530
> @@ -742,7 +742,7 @@
> ppc64_processor_speed(void)
> {
> ulong res, value, ppc_md, md_setup_res;
> - ulong we_have_of, prep_setup_res;
> + ulong prep_setup_res;
> ulong node, type, name, properties;
> char str_buf[32];
> uint len;
> @@ -751,22 +751,12 @@
> if (machdep->mhz)
> return(machdep->mhz);
>
> - /* first, check if the have_of variable a) exists, and b) is TRUE */
> - if(symbol_exists("have_of")) {
> - get_symbol_data("have_of", sizeof(void *), &we_have_of);
> - } else {
> - we_have_of = 0;
> - }
> -
> - if(we_have_of) {
> + if(symbol_exists("allnodes")) {
> /* we have a machine with open firmware, so search the OF nodes
> * for cpu nodes.
> * Too bad we can't call kernel helper functions here :)
> */
>
> - if(!symbol_exists("allnodes"))
> - return (machdep->mhz = 0);
> -
> get_symbol_data("allnodes", sizeof(void *), &node);
> while(node) {
> readmem(node+OFFSET(device_node_type),
> diff -Naur a/ppc.c b/ppc.c
> --- a/ppc.c 2010-03-24 10:14:33.000000000 +0530
> +++ b/ppc.c 2010-03-24 10:14:51.000000000 +0530
> @@ -461,7 +461,7 @@
> ppc_processor_speed(void)
> {
> ulong res, value, ppc_md, md_setup_res;
> - ulong we_have_of, prep_setup_res;
> + ulong prep_setup_res;
> ulong node, type, name, properties;
> char str_buf[16];
> ulong len, mhz = 0;
> @@ -469,22 +469,12 @@
> if (machdep->mhz)
> return(machdep->mhz);
>
> - /* first, check if the have_of variable a) exists, and b) is TRUE */
> - if(symbol_exists("have_of")) {
> - get_symbol_data("have_of", sizeof(void *), &we_have_of);
> - } else {
> - we_have_of = 0;
> - }
> -
> - if(we_have_of) {
> + if(symbol_exists("allnodes")) {
> /* we have a machine with open firmware, so search the OF nodes
> * for cpu nodes.
> * Too bad we can't call kernel helper functions here :)
> */
>
> - if(!symbol_exists("allnodes"))
> - return (machdep->mhz = 0);
> -
> get_symbol_data("allnodes", sizeof(void *), &node);
> while(node) {
> readmem(node+OFFSET(device_node_type),
>
>
14 years, 10 months
Re: [Crash-utility] crash utility on x86_64 non redhat machine ?
by Dave Anderson
----- "Mithun R N Iyer" <mithun_rn(a)yahoo.co.in> wrote:
> Hi,
>
> My machine is not redhat linux, will I be able to use it on any linux machine ?
> Where can I find the crash utility binary for x86-64 ? I am finding
> hard time building it from the sources.
>
> Appreciate any help!
> - mithun
It should run on non-Red Hat kernels, provided that the kernel doesn't
have some fundamental kernel difference/patch that causes it to fail.
The various kernel distributors (SUSE, Ubuntu, Debian, etc.) have their
own versions of this crash utility, which may have their own patches,
but the base upstream version is not tied to Red Hat kernels.
As far as binaries are concerned, it's likely that a version built on
one distribution won't run on another distribution, although I've never
tried that.
If you can't build it from the sources, then I guess you would have
to get a binary version of crash from the distribution that you are
running on. What is your system missing that causes the build to fail?
Dave
14 years, 10 months
[PATCH] Fix display processor speed on ppc/ppc64
by Pavan Naregundi
Hi Everyone,
On Power6 crash displays "MACHINE: ppc64 (unknown Mhz)" for processor
speed upon initialization and by the "sys" sub-command.
# crash
crash 5.0.1
Copyright (C) 2002-2010 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 (GDB) 7.0
Copyright (C) 2009 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 "powerpc64-unknown-linux-gnu"...
KERNEL: /boot/vmlinux-2.6.32.9-0.5-ppc64
DUMPFILE: /dev/mem
CPUS: 5
DATE: Thu Mar 18 03:13:59 2010
UPTIME: 04:11:31
LOAD AVERAGE: 0.34, 0.15, 0.05
TASKS: 319
NODENAME: brucelp3
RELEASE: 2.6.32.9-0.5-ppc64
VERSION: #1 SMP 2010-03-15 12:22:00 +0100
MACHINE: ppc64 (unknown Mhz) ======> display unknown Mhz
MEMORY: 1 GB
PID: 17788
COMMAND: "crash"
TASK: c00000003ae58b80 [THREAD_INFO: c00000003df68000]
CPU: 6
STATE: TASK_RUNNING (ACTIVE)
=====================
When investigated this issue was absence of 'have_of' symbol in current
kernels. Below is the commit which removed the support of 'have_of'.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit...
This patch overcomes the use of 'have_of' variable.. Please review this
patch..
Regards,
Pavan
IBM Linux Technology Center
---
diff -Naur a/ppc64.c b/ppc64.c
--- a/ppc64.c 2010-03-24 10:14:33.000000000 +0530
+++ b/ppc64.c 2010-03-24 10:14:51.000000000 +0530
@@ -742,7 +742,7 @@
ppc64_processor_speed(void)
{
ulong res, value, ppc_md, md_setup_res;
- ulong we_have_of, prep_setup_res;
+ ulong prep_setup_res;
ulong node, type, name, properties;
char str_buf[32];
uint len;
@@ -751,22 +751,12 @@
if (machdep->mhz)
return(machdep->mhz);
- /* first, check if the have_of variable a) exists, and b) is
TRUE */
- if(symbol_exists("have_of")) {
- get_symbol_data("have_of", sizeof(void *),
&we_have_of);
- } else {
- we_have_of = 0;
- }
-
- if(we_have_of) {
+ if(symbol_exists("allnodes")) {
/* we have a machine with open firmware, so search the
OF nodes
* for cpu nodes.
* Too bad we can't call kernel helper functions
here :)
*/
- if(!symbol_exists("allnodes"))
- return (machdep->mhz = 0);
-
get_symbol_data("allnodes", sizeof(void *), &node);
while(node) {
readmem(node+OFFSET(device_node_type),
diff -Naur a/ppc.c b/ppc.c
--- a/ppc.c 2010-03-24 10:14:33.000000000 +0530
+++ b/ppc.c 2010-03-24 10:14:51.000000000 +0530
@@ -461,7 +461,7 @@
ppc_processor_speed(void)
{
ulong res, value, ppc_md, md_setup_res;
- ulong we_have_of, prep_setup_res;
+ ulong prep_setup_res;
ulong node, type, name, properties;
char str_buf[16];
ulong len, mhz = 0;
@@ -469,22 +469,12 @@
if (machdep->mhz)
return(machdep->mhz);
- /* first, check if the have_of variable a) exists, and b) is TRUE */
- if(symbol_exists("have_of")) {
- get_symbol_data("have_of", sizeof(void *), &we_have_of);
- } else {
- we_have_of = 0;
- }
-
- if(we_have_of) {
+ if(symbol_exists("allnodes")) {
/* we have a machine with open firmware, so search the OF nodes
* for cpu nodes.
* Too bad we can't call kernel helper functions here :)
*/
- if(!symbol_exists("allnodes"))
- return (machdep->mhz = 0);
-
get_symbol_data("allnodes", sizeof(void *), &node);
while(node) {
readmem(node+OFFSET(device_node_type),
14 years, 10 months
crash utility on x86_64 non redhat machine ?
by Mithun R N Iyer
Hi,
My machine is not redhat linux, will I be able to use it on any linux machine ?
Where can I find the crash utility binary for x86-64 ? I am finding hard time building it from the sources.
Appreciate any help!
- mithun
The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/
14 years, 10 months
crashdc is now available in beta
by Louis Bouchard
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello everyone,
A while ago, I posted to this list information about crashdc, a tool
that I develop which make use of the crash utility to extract a text
file out of a vmcore automatically.
It is now available in beta for public consumption here :
http://sourceforge.net/projects/crashdc/files/
All functionalities have been tested on RHEL5, SLES10 and SLES11 for the
x86 and x86_64 architectures.
For a brief outline of the project, here is a copy of the included
README file. More details can be found on the project page.
Kind Regards,
...Louis
> crashdc : an automated collection tool
> ======================================
>
> crashdc is an automated collection tool . It is intended to be run whenever
> a new vmcore file is generated in order to collect basic crash dump data for
> offline analysis. It can also be executed interactively on existing dump files.
>
> 0. Preliminary warning
> ======================
> This is the beta release of crashdc. Please report any issue you find or
> comments you may have. We definitively want to hear from any
> issue/comment/rant/praise you would like to submit. If you want to, you can
> submit these at crashdc-devel(a)lists.sourceforge.net
>
> 1. Introduction
> ===============
> Crash dump files (i.e. vmcore) are becoming larger and larger. It is not
> uncommon to encounter files larger than 16 Gb. It is becoming difficult to have
> those files transfered to vendor's facilities for analysis. And sometimes, only
> a few standard crash commands are necessary to have a good idea of what caused
> the crash.
>
> crashdc is meant to run automatically after creation of the vmcore file. It will
> gather the main crash data elements an transfer them into a text file. Normally,
> this is only done on the most recent vmcore generated.
>
> But when invoked manually using the init.d script with the 'generate' keyword,
> it is possible to generate specific reports, using specific modes supplied on
> the command line.
>
> 2. crashdc operation
> ====================
> Crashdc main usage is to automate the collection of basic data elements presents
> in a vmcore file. Automation of its execution can be done using on of these two
> methods :
>
> * kdump post-save trigger
> * init script
>
> While the kdump method is better integrated in the dump procedure, it can appear
> as limitative, especially since it runs within the kexec reserved space. For
> instance, it may be necessary to reserve up to 256 Mb of kexec space (SLES11) in
> order for crashdc to run properly. This might prove to be impossible on some
> system with limited amount of memory.
>
> If this happens, then the init script method will prove to be a better choice as
> it happens during the normal course of a reboot, late in the boot process and
> doesn't require an increase in kexec memory reservation. It may also be the only
> possible method on environments where kexec/kdump is not available at all (i.e.
> RHEL4).
>
> But automatic execution of crashdc is not required. It is possible to use the
> init script manually to create crash-data-{date}.txt reports. It is also
> possible to use this method to override the default mode (as defined in
> /etc/sysconfig/crashdc) or to provide custom-made crash commands through a file.
>
> Finally, the crashdc tool itself can be used as a command line tool, in
> situations where the debuginfo RPM cannot be installed, specific kernel
> locations are used or non standard environments are a necessity.
>
> For further details on each one of the commands refer to :
>
> * crashdc(8) : The crashdc command
> * crashdc(7) : The init script
> * crashdc(5) : The configuration file
>
> 3. crashdc testing context
> ==========================
> crashdc is currently tested in a limited environment which consist of standard
> installs of RHEL5, SLES10 and SLES11 in VM. No specific configuration is done
> except for what is described here.
>
> 4. crashdc known limitation
> ===========================
>
> 4.1 Local storage only
> ----------------------
> So far, crashdc has been tested on local storage only. This means that it might
> not work at all using NFS network storage (or CIFS on SLES). It will not work at
> all with ftp/scp as the vmcore file is sent away to another host. If you want to
> use crashdc in this fashion, you will have to install it on the remote server
> where the vmcore file is stored and will not be able to use the automated
> method.
>
> You still can use the manual method to generate the crash-data-{date}.txt file.
>
> 4.2 Same kernel type
> --------------------
> When the /etc/init.d/crashdc script is invoked manually to generate the
> crash-data-{date}.txt file, it supposes that the booted kernel is the same than
> the one that generated the vmcore file. If both are different, an error will be
> displayed and the command will fail.
- --
Louis Bouchard, Linux Support Engineer
Team lead, EMEA Linux Competency Center,
Linux Ambassador, HP
HP Services 1 Ave du Canada
HP France Z.A. de Courtaboeuf
louis.bouchard(a)hp.com 91 947 Les Ulis
http://www.hp.com/go/linux France
http://www.hp.com/fr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkunJHoACgkQDvqokHrhnCzeQwCfUaGsjlkrX6nbQn0pfjcgVUf0
1eUAnAsFHUUxq5IAyubtDbivdtA6/Vug
=7k4M
-----END PGP SIGNATURE-----
14 years, 10 months
