FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Crash Utility

 
 
LinkBack Thread Tools
 
Old 08-08-2012, 06:29 PM
paawan oza
 
Default using crash for ARM

Hi Dave,
please find my comments below.
Dave: If a breakpoint were set, it would
generate an interrupt in the kernel, control would be passed
to an interrupt handler, and any "work" would have to be done
there (within the context of the interrupt handler) since the
crash utility code could not run in user-space.
Oza: yes, but not necessarily it has to be done in interrupt context, but signal could be sent to crash may be SIGTRAP or something.the whole kernel preemption could be disabled the moment the signal is delivered and whole kernel freezes and control always stay with crash utility. where you could inspect kernel datastructures at break-pointed kernel.
I
could be easily missing many things over here, as it is also just a thought from my side without detailed thinking.of course on SMP; things become even more complex
and I even do not know the cost vs benefit ratio here.

Dave: The crash utility has never done such a thing since its inception
in early UNIX.* And yes, kgdb, kdb, kprobes, ftrace, or systemtap
would be more in line with what you're looking for.
Oza:
kgdb doesnt seem to be inline anymore with kernel versions.kdb, you need recompilation of kernel, and I am not sure it supports ARM and symbols
, it seems to be working with raw addresses.ftrace is again tracing mechanism, I am not sure it supports breakpoints and watchpoint, of course you can debug the kernel but in a different way.systemtap is again having tracing
capabilities.
I could be easily wrong in thinking that crash could suport breakpoints and watchpoints, and I could be easily underestimating the capabilities of the tools you have mentioned;
but I thought technically it might be feasible to in corporate breakpoint support in crash.

Regards,Oza.

From: Dave Anderson <anderson@redhat.com>
To: paawan oza <paawan1982@yahoo.com>
Cc: "Discussion list for crash utility usage, maintenance and development"
<crash-utility@redhat.com>
Sent: Wednesday, 8 August 2012 6:16 PM
Subject: Re: [Crash-utility] using crash for ARM



----- Original Message -----
>
>
> how about if crash utility supports breakpoints/watchpoints
> specifically hw level.
> of course need a kernel module to modify kernel memory as you
> suggested.
>
> was there any specific reason, you did not support this, thinking
> already kgdb and kdb types of utility available ?
> If we support breakpoint./watchpoints in crash, will the crash be
> able to offer much better than any other kernel debug tools ?
>
> what do you think?
>

I really don't understand how you expect the crash utility to
accomplish such a feat.* If a breakpoint were set, it
would
generate an interrupt in the kernel, control would be passed
to an interrupt handler, and any "work" would have to be done
there (within the context of the interrupt handler) since the
crash utility code could not run in user-space.

The crash utility has never done such a thing since its inception
in early UNIX.* And yes, kgdb, kdb, kprobes, ftrace, or systemtap
would be more in line with what you're looking for.

Dave



--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 08-08-2012, 06:31 PM
paawan oza
 
Default using crash for ARM

crash: cannot open secondary temporary file
above is the last error statement and crash exits.
Regards,Oza.

From: Dave Anderson <anderson@redhat.com>
To: paawan oza <paawan1982@yahoo.com>
Cc: "Discussion list for crash utility usage, maintenance and development" <crash-utility@redhat.com>
Sent: Wednesday,
8 August 2012 7:28 PM
Subject: Re: [Crash-utility] using crash for ARM



----- Original Message -----
>
>
> Hi,
> I got the crash up on the target but I get following error.

Well, that's impressive...

> WARNING: kernels compiled by different gcc versions:
> ./vmlinux: (unknown)
> live system kernel: 4.4.3

That's a harmless warning, but what do these commands show:

$ strings vmlinux | grep "Linux version"

and

$ cat /proc/version

The gcc-related data in those two strings are being compared.

> crash: cannot open secondary temporary file

When do you see that message?

>
> I have taken System.map and vmlinux from the same build path.

The System.map file is not necessary if the vmlinux is the kernel
that the live system is
running.

Dave


>
> Regards,
> Oza.
>
>
>
>
>
> From: Dave Anderson <anderson@redhat.com>
> To: paawan oza <paawan1982@yahoo.com>; "Discussion list for crash
> utility usage, maintenance and development"
> <crash-utility@redhat.com>
> Sent: Monday, 6 August 2012 8:58 PM
> Subject: Re: [Crash-utility] using crash for ARM
>
>
>
> ----- Original Message -----
> >
> >
> >
> > Hi,
> >
> >
> > I would like to use crash utility on ARM.
> > what I understand is there might be two ways to go about
it.
> >
> > 1) cross compile whole crash for arm itself, which doesnt seem to
> > be
> > good option because on arm target we will need lots of depedent
> > packages.
> >
> > 2) run crash on x86 and have gdbserver/remoter server compiled on
> > target. and have serial connection and so on..
> >
> > please suggest instructions or any pointers regarding the same.
> >
> > Regards,
> > Oza.
>
> If you are talking about running crash on a live ARM system, then
> option #1 is the only possibility. Option #2 does not exist for
> the crash utility; live system access requires either /dev/mem,
> /proc/kcore, or the /dev/crash misc driver.
>
> Dave
>
>
>
>


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 08-08-2012, 06:38 PM
Dave Anderson
 
Default using crash for ARM

----- Original Message -----
>
>
> Hi Dave,
>
>
> please find my comments below.
>
> Dave: If a breakpoint were set, it would
> generate an interrupt in the kernel, control would be passed
> to an interrupt handler, and any "work" would have to be done
> there (within the context of the interrupt handler) since the
> crash utility code could not run in user-space.
>
> Oza: yes, but not necessarily it has to be done in interrupt context,
> but signal could be sent to crash may be SIGTRAP or something.
> the whole kernel preemption could be disabled the moment the signal
> is delivered and whole kernel freezes and control always stay with
> crash utility. where you could inspect kernel datastructures at
> break-pointed kernel.
>
> I could be easily missing many things over here, as it is also just a
> thought from my side without detailed thinking.
> of course on SMP; things become even more complex
>
> and I even do not know the cost vs benefit ratio here.
>
> Dave: The crash utility has never done such a thing since its inception
> in early UNIX. And yes, kgdb, kdb, kprobes, ftrace, or systemtap
> would be more in line with what you're looking for.
>
> Oza:
>
> kgdb doesnt seem to be inline anymore with kernel versions.
> kdb, you need recompilation of kernel, and I am not sure it supports
> ARM and symbols, it seems to be working with raw addresses.
> ftrace is again tracing mechanism, I am not sure it supports
> breakpoints and watchpoint, of course you can debug the kernel but
> in a different way. systemtap is again having tracing capabilities.

I'm not sure what you mean by that -- systemtap is far more
than a tracer. You can write very involved handlers to run
when the breakpoint is hit.

> I could be easily wrong in thinking that crash could suport
> breakpoints and watchpoints, and I could be easily underestimating
> the capabilities of the tools you have mentioned;
>
> but I thought technically it might be feasible to incorporate
> breakpoint support in crash.

You're on your own...

Dave


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 08-08-2012, 06:41 PM
Dave Anderson
 
Default using crash for ARM

----- Original Message -----
>
>
> > > crash: cannot open secondary temporary file
> >
> > When do you see that message?
>
> above is the last error statement and crash exits.
>
> Regards,
> Oza.

Attach the output of "crash -d8".

Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 08-09-2012, 07:06 AM
paawan oza
 
Default using crash for ARM

shell@android:/system # ./crash -d8

crash 6.0.8
Copyright (C) 2002-2012* 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.


find_booted_kernel: search for [Linux version 3.0.15+ (oza@lc-blr-292) (gcc version 4.4.3 (GCC) ) #2 PREEMPT Wed Aug 8 13:39:53 IST 2012]
searchdirs[7]: /usr/lib/debug/lib/modules/3.0.15+/
searchdirs[0]: /usr/src/linux/
searchdirs[1]: /boot/
searchdirs[2]: /boot/efi/redhat
searchdirs[3]: /boot/efi/EFI/redhat
searchdirs[4]: /
searchdirs[5]: /usr/src/redhat/BUILD/kernel-3.0.15/linux/
searchdirs[6]: /usr/src/redhat/BUILD/kernel-3.0.15/linux-3.0.15/
mount_points[0]: / (cafcb0)
mount_points[1]: /dev (cafcc0)
mount_points[2]: /dev/pts (cafcd0)
mount_points[3]: /proc (cafce8)
mount_points[4]: /sys (cafcf8)
mount_points[5]: /acct (cafd08)
mount_points[6]: /mnt/asec (cafd18)
mount_points[7]: /mnt/obb (cafd30)
mount_points[8]: /dev/cpuctl (cafd48)
mount_points[9]: /system (cafd68)
mount_points[10]: /data (cafd80)
mount_points[11]: /cache (cafd90)
mount_points[12]: /sys/kernel/debug
(cafda0)
find_booted_kernel: check: /init
crash: cannot find booted kernel -- please enter namelist argument


Usage:

* crash [OPTION]... NAMELIST MEMORY-IMAGE* (dumpfile form)
* crash [OPTION]... [NAMELIST]************ (live system form)

Enter "crash -h" for details.
PS: I also get a warning message from system: our own message crash used greatest stack depth: 5016 bytes left

apart from that If I run crash
./crash ./vmlinuxcrash 6.0.8
Copyright (C) 2002-2012* 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.

get_live_memory_source: /dev/mem
WARNING: ./vmlinux and /proc/version do not match!

WARNING: /proc/version indicates kernel version: 3.0.15+

crash: please use the vmlinux file for that kernel version, or try using
****** the System.map for that kernel version as an additional argument.

If I include system.mapit exits with'can not open secondary temp[orary file"void

open_tmpfile2(void)
{
******* if (pc->tmpfile2)
*************** error(FATAL, "recursive secondary temporary file usage
");
***************
******* if ((pc->tmpfile2 = tmpfile()) == NULL)
*************** error(FATAL, "cannot open secondary temporary file
");
*******
******* rewind(pc->tmpfile2);
}

Regards,Oza.




From: Dave Anderson <anderson@redhat.com>
To: paawan oza <paawan1982@yahoo.com>
Cc: "Discussion list for crash utility usage, maintenance and development" <crash-utility@redhat.com>
Sent: Thursday, 9 August 2012 12:11 AM
Subject: Re: [Crash-utility] using crash for ARM



----- Original Message -----
>
>
> > > crash: cannot open secondary temporary file
> >
> > When do you see that message?
>
> above is the last error statement and crash exits.
>
> Regards,
> Oza.

Attach the output of
"crash -d8".

Dave


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 08-09-2012, 07:14 AM
paawan oza
 
Default using crash for ARM

Hi Dave,
I am sorry, If I over-enthusiastically thought crash could support kernel breakpoints while originally it was not meant to do that.I think I better look at other utilities and evaluate their capability.but I guess from your side, you do not seem to be keen on idea of breakpoints, specially when there are other plenty of utilities available.
Regards,Oza.
From: Dave Anderson <anderson@redhat.com>
To: paawan oza <paawan1982@yahoo.com>
Cc: "Discussion list for crash utility usage, maintenance and development" <crash-utility@redhat.com>
Sent: Thursday, 9 August 2012 12:08 AM
Subject: Re: [Crash-utility] using crash for ARM



----- Original Message -----
>
>
> Hi Dave,
>
>
> please find my comments below.
>
> Dave: If a breakpoint were set, it would
> generate an interrupt in the kernel, control would be passed
> to an interrupt handler, and any "work" would have to be done
> there (within the context of the interrupt handler) since the
> crash utility code could not
run in user-space.
>
> Oza: yes, but not necessarily it has to be done in interrupt context,
> but signal could be sent to crash may be SIGTRAP or something.
> the whole kernel preemption could be disabled the moment the signal
> is delivered and whole kernel freezes and control always stay with
> crash utility. where you could inspect kernel datastructures at
> break-pointed kernel.
>
> I could be easily missing many things over here, as it is also just a
> thought from my side without detailed thinking.
> of course on SMP; things become even more complex
>
> and I even do not know the cost vs benefit ratio here.
>
> Dave: The crash utility has never done such a thing since its inception
> in early UNIX. And yes, kgdb, kdb, kprobes, ftrace, or systemtap
> would be more in line with what you're looking for.
>
> Oza:
>
>
kgdb doesnt seem to be inline anymore with kernel versions.
> kdb, you need recompilation of kernel, and I am not sure it supports
> ARM and symbols, it seems to be working with raw addresses.
> ftrace is again tracing mechanism, I am not sure it supports
> breakpoints and watchpoint, of course you can debug the kernel but
> in a different way.* systemtap is again having tracing capabilities.

I'm not sure what you mean by that -- systemtap is far more
than a tracer.* You can write very involved handlers to run
when the breakpoint is hit.

> I could be easily wrong in thinking that crash could suport
> breakpoints and watchpoints, and I could be easily underestimating
> the capabilities of the tools you have mentioned;
>
> but I thought technically it might be feasible to incorporate
> breakpoint support in crash.

You're on your own...

Dave




--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 08-09-2012, 08:11 AM
Mika Westerberg
 
Default using crash for ARM

On Thu, Aug 09, 2012 at 12:06:44AM -0700, paawan oza wrote:
> apart from that If I run crash
>
> ./crash ./vmlinux

I think that Dave meant that you should run crash like:

% crash -d8 vmlinux

and post output here.

> crash 6.0.8
> Copyright (C) 2002-2012* 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.
>
> get_live_memory_source: /dev/mem
> WARNING: ./vmlinux and /proc/version do not match!
>
> WARNING: /proc/version indicates kernel version: 3.0.15+
>
> crash: please use the vmlinux file for that kernel version, or try using
> ****** the System.map for that kernel version as an additional argument.

You should also try to get the vmlinux file (with debugging symbols) that
actually matches the running system.

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 08-09-2012, 12:54 PM
Dave Anderson
 
Default using crash for ARM

----- Original Message -----
>
>
> shell@android:/system # ./crash -d8

OK, so try this:

$ crash -d8 vmlinux

and/or:

$ crash -d8 vmlinux System.map

Dave


> crash 6.0.8
> Copyright (C) 2002-2012 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.
>
>
> find_booted_kernel: search for [Linux version 3.0.15+
> (oza@lc-blr-292) (gcc version 4.4.3 (GCC) ) #2 PREEMPT Wed Aug 8
> 13:39:53 IST 2012]
> searchdirs[7]: /usr/lib/debug/lib/modules/3.0.15+/
> searchdirs[0]: /usr/src/linux/
> searchdirs[1]: /boot/
> searchdirs[2]: /boot/efi/redhat
> searchdirs[3]: /boot/efi/EFI/redhat
> searchdirs[4]: /
> searchdirs[5]: /usr/src/redhat/BUILD/kernel-3.0.15/linux/
> searchdirs[6]: /usr/src/redhat/BUILD/kernel-3.0.15/linux-3.0.15/
> mount_points[0]: / (cafcb0)
> mount_points[1]: /dev (cafcc0)
> mount_points[2]: /dev/pts (cafcd0)
> mount_points[3]: /proc (cafce8)
> mount_points[4]: /sys (cafcf8)
> mount_points[5]: /acct (cafd08)
> mount_points[6]: /mnt/asec (cafd18)
> mount_points[7]: /mnt/obb (cafd30)
> mount_points[8]: /dev/cpuctl (cafd48)
> mount_points[9]: /system (cafd68)
> mount_points[10]: /data (cafd80)
> mount_points[11]: /cache (cafd90)
> mount_points[12]: /sys/kernel/debug (cafda0)
> find_booted_kernel: check: /init
> crash: cannot find booted kernel -- please enter namelist argument
>
>
> Usage:
>
> crash [OPTION]... NAMELIST MEMORY-IMAGE (dumpfile form)
> crash [OPTION]... [NAMELIST] (live system form)
>
> Enter "crash -h" for details.
>
>
> PS: I also get a warning message from system: our own message crash
> used greatest stack depth: 5016 bytes left
>
>
>
> apart from that If I run crash
>
>
> ./crash ./vmlinux
> crash 6.0.8
> Copyright (C) 2002-2012 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.
>
> get_live_memory_source: /dev/mem
> WARNING: ./vmlinux and /proc/version do not match!
>
> WARNING: /proc/version indicates kernel version: 3.0.15+
>
> crash: please use the vmlinux file for that kernel version, or try
> using
> the System.map for that kernel version as an additional argument.
>
>
>
> If I include system.map
> it exits with
> 'can not open secondary temp[orary file"
> void
> open_tmpfile2(void)
> {
> if (pc->tmpfile2)
> error(FATAL, "recursive secondary temporary file usage
");
>
> if ((pc->tmpfile2 = tmpfile()) == NULL)
> error(FATAL, "cannot open secondary temporary file
");
>
> rewind(pc->tmpfile2);
> }
>
>
>
> Regards,
> Oza.
>
>
>
>
>
>
>
>
>
>
>
>
> From: Dave Anderson <anderson@redhat.com>
> To: paawan oza <paawan1982@yahoo.com>
> Cc: "Discussion list for crash utility usage, maintenance and
> development" <crash-utility@redhat.com>
> Sent: Thursday, 9 August 2012 12:11 AM
> Subject: Re: [Crash-utility] using crash for ARM
>
>
>
> ----- Original Message -----
> >
> >
> > > > crash: cannot open secondary temporary file
> > >
> > > When do you see that message?
> >
> > above is the last error statement and crash exits.
> >
> > Regards,
> > Oza.
>
> Attach the output of "crash -d8".
>
> Dave
>
>
>

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 08-10-2012, 06:29 AM
paawan oza
 
Default using crash for ARM

Hi,

please find the logs attached for crash -d8 vmlinux System.map.

crash -d8 vmlinux doesnt work.
it gives

crash 6.0.8
Copyright (C) 2002-2012* 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.

get_live_memory_source: /dev/mem
WARNING: ./vmlinux and /proc/version do not match!

WARNING: /proc/version indicates kernel version: 3.0.15+

crash: please use the vmlinux file for that kernel version, or try using
****** the System.map for that kernel version as an additional argument.

Regards,
Oza.


From: Dave Anderson <anderson@redhat.com>
To: paawan oza <paawan1982@yahoo.com>
Cc:
"Discussion list for crash utility usage, maintenance and development" <crash-utility@redhat.com>
Sent: Thursday, 9 August 2012 6:24 PM
Subject: Re: [Crash-utility] using crash for ARM

----- Original Message -----
>
>
> shell@android:/system # ./crash -d8

OK, so try this:

$ crash -d8 vmlinux

and/or:

$ crash -d8 vmlinux System.map

Dave


> crash 6.0.8
> Copyright (C) 2002-2012 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.
>
>
> find_booted_kernel: search for [Linux version 3.0.15+
> (oza@lc-blr-292) (gcc version 4.4.3 (GCC) ) #2 PREEMPT Wed Aug 8
> 13:39:53 IST 2012]
> searchdirs[7]: /usr/lib/debug/lib/modules/3.0.15+/
> searchdirs[0]: /usr/src/linux/
> searchdirs[1]: /boot/
> searchdirs[2]: /boot/efi/redhat
> searchdirs[3]: /boot/efi/EFI/redhat
> searchdirs[4]: /
> searchdirs[5]: /usr/src/redhat/BUILD/kernel-3.0.15/linux/
> searchdirs[6]: /usr/src/redhat/BUILD/kernel-3.0.15/linux-3.0.15/
> mount_points[0]: /
(cafcb0)
> mount_points[1]: /dev (cafcc0)
> mount_points[2]: /dev/pts (cafcd0)
> mount_points[3]: /proc (cafce8)
> mount_points[4]: /sys (cafcf8)
> mount_points[5]: /acct (cafd08)
> mount_points[6]: /mnt/asec (cafd18)
> mount_points[7]: /mnt/obb (cafd30)
> mount_points[8]: /dev/cpuctl (cafd48)
> mount_points[9]: /system (cafd68)
> mount_points[10]: /data (cafd80)
> mount_points[11]: /cache (cafd90)
> mount_points[12]: /sys/kernel/debug (cafda0)
> find_booted_kernel: check: /init
> crash: cannot find booted kernel -- please enter namelist argument
>
>
> Usage:
>
> crash [OPTION]... NAMELIST MEMORY-IMAGE (dumpfile form)
> crash [OPTION]... [NAMELIST] (live system form)
>
> Enter "crash -h" for details.
>
>
> PS: I also get a warning message from system: our own message crash
> used greatest stack
depth: 5016 bytes left
>
>
>
> apart from that If I run crash
>
>
> ./crash ./vmlinux
> crash 6.0.8
> Copyright (C) 2002-2012 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.
>
>
get_live_memory_source: /dev/mem
> WARNING: ./vmlinux and /proc/version do not match!
>
> WARNING: /proc/version indicates kernel version: 3.0.15+
>
> crash: please use the vmlinux file for that kernel version, or try
> using
> the System.map for that kernel version as an additional argument.
>
>
>
> If I include system.map
> it exits with
> 'can not open secondary temp[orary file"
> void
> open_tmpfile2(void)
> {
> if (pc->tmpfile2)
> error(FATAL, "recursive secondary temporary file usage
");
>
> if ((pc->tmpfile2 = tmpfile()) == NULL)
> error(FATAL, "cannot open secondary temporary file
");
>
> rewind(pc->tmpfile2);
> }
>
>
>
> Regards,
> Oza.
>
>
>
>
>
>
>
>
>
>
>
>
>
From: Dave Anderson <anderson@redhat.com>
> To: paawan oza <paawan1982@yahoo.com>
> Cc: "Discussion list for crash utility usage, maintenance and
> development" <crash-utility@redhat.com>
> Sent: Thursday, 9 August 2012 12:11 AM
> Subject: Re: [Crash-utility] using crash for ARM
>
>
>
> ----- Original Message -----
> >
> >
> > > > crash: cannot open secondary temporary file
> > >
> > > When do you see that message?
> >
> > above is the last error statement and crash exits.
> >
> > Regards,
> > Oza.
>
> Attach the output
of "crash -d8".
>
> Dave
>
>
>


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 08-10-2012, 04:31 PM
Dave Anderson
 
Default using crash for ARM

----- Original Message -----
>
> Hi,
>
> please find the logs attached for crash -d8 vmlinux System.map.
>
> crash -d8 vmlinux doesnt work. it gives
>
> crash 6.0.8
> Copyright (C) 2002-2012 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.
>
> get_live_memory_source: /dev/mem
> WARNING: ./vmlinux and /proc/version do not match!
>
> WARNING: /proc/version indicates kernel version: 3.0.15+
>
> crash: please use the vmlinux file for that kernel version, or try using
> the System.map for that kernel version as an additional argument.
>
> Regards,
> Oza.

For starters, as Mika suggested, you should try your best to use the
actual vmlinux file that is being run on the live system. If the running
kernel's vmlinux file does not have debuginfo data, and you are using a
similar kernel along with the running kernel's System.map file, then you
must be sure that the "other" vmlinux that you are using is as close as
possible to the running kernel. There are no guarantees that using a
System.map file will work.

Anyway, looking at the log file, I'm not sure why there's non-crash related
data intermingled with the crash -d8 output, i.e., like this:

...
c00dfc08 clk_enable
c00dfc50 clk_debug_set_enable
c00dfcac clk_[ 1866.844757] ##> wifi_suspend
[ 1866.856903] i2c i2c-1: mpu_dev_suspend, called regulator_disable. Status: 0
[ 1866.856933] mpu_dev_suspend: Suspend handler executed
[ 1866.872528] PM: suspend of devices complete after 27.886 msecs
[ 1866.872558] PM: suspend devices took 0.030 seconds
[ 1866.873077] PM: late suspend of devices complete after 0.457 msecs
[ 1866.873535] PM: early resume of devices complete after 0.183 msecs
[ 1866.874481] i2c i2c-1: mpu_dev_resume, called regulator_enable. Status: 0
[ 1866.874511] mpu_dev_resume: Resume handler executed
[ 1866.874572] wakeup wake lock: bcmpmu_i2c
[ 1866.874908] get_update_rate: rate = 112000
[ 1866.874938] get_update_rate: rate = 112000
[ 1866.876434] ##> wifi_resume
[ 1866.892822] PM: resume of devices complete after 19.007 msecs
[ 1866.893676] PM: resume devices took 0.020 seconds
reset
c00dfd4c clk_debug_reset
c00dfd90 clk_init
c00dfe10 clk_register
...

Regardless of that, I was looking for a readmem() call, or other debug statement
that might help pinpoint the failure location. The best that can be inferred from
the log data are the GNU_GET_DATATYPE debug statements at the end:

$ grep GNU_GET_DATATYPE teraterm.log
GNU_GET_DATATYPE[runqueue]: returned via gdb_error_hook (1 buffer in use)
GNU_GET_DATATYPE[prio_array]: returned via gdb_error_hook (1 buffer in use)
GNU_GET_DATATYPE[prio_array]: returned via gdb_error_hook (1 buffer in use)
GNU_GET_DATATYPE[prio_array]: returned via gdb_error_hook (1 buffer in use)
GNU_GET_DATATYPE[irq_desc_t]: returned via gdb_error_hook (1 buffer in use)
GNU_GET_DATATYPE[hw_interrupt_type]: returned via gdb_error_hook (1 buffer in use)
GNU_GET_DATATYPE[timer_vec_root]: returned via gdb_error_hook (1 buffer in use)
GNU_GET_DATATYPE[timer_vec]: returned via gdb_error_hook (1 buffer in use)
GNU_GET_DATATYPE[tvec_root_s]: returned via gdb_error_hook (1 buffer in use)
GNU_GET_DATATYPE[softirq_state]: returned via gdb_error_hook (1 buffer in use)
GNU_GET_DATATYPE[desc_struct]: returned via gdb_error_hook (1 buffer in use)
GNU_GET_DATATYPE[kallsyms_header]: returned via gdb_error_hook (1 buffer in use)
GNU_GET_DATATYPE[mem_section]: returned via gdb_error_hook (1 buffer in use)
GNU_GET_DATATYPE[note_buf_t]: returned via gdb_error_hook (1 buffer in use)
$

>From those it's evident that you've successfully made it through kernel_init(),
and have called machdep_init(POST_GDB) from here in main.c:main_loop()

} else if (!(pc->flags & MINIMAL_MODE)) {
read_in_kernel_config(IKCFG_INIT);
kernel_init();
=====> machdep_init(POST_GDB);
vm_init();
machdep_init(POST_VM);
module_init();
help_init();
task_init();
vfs_init();
net_init();
dev_init();
machdep_init(POST_INIT);
}

which calls into arm.c:arm_init(POST_GDB). That function has successfully made
it past the STRUCT_SIZE_INIT(note_buf, "note_buf_t") call:

/*
* We need to have information about note_buf_t which is used to
* hold ELF note containing registers and status of the thread
* that panic'd.
*/
=====> STRUCT_SIZE_INIT(note_buf, "note_buf_t");

STRUCT_SIZE_INIT(elf_prstatus, "elf_prstatus");
MEMBER_OFFSET_INIT(elf_prstatus_pr_pid, "elf_prstatus",
"pr_pid");
MEMBER_OFFSET_INIT(elf_prstatus_pr_reg, "elf_prstatus",
"pr_reg");
break;

But the next STRUCT_SIZE_INIT() for "elf_prstatus" apparently never got completed.

In any case, it ended up in open_tmpfile2():

$ tail teraterm.log
GETBUF(128 -> 0)
FREEBUF(0)
GETBUF(128 -> 0)
FREEBUF(0)
GETBUF(128 -> 0)
FREEBUF(0)

crash: cannot open secondary temporary file

1|shell@android:/system #
$


Although it's not clear how it's ending up in open_tmpfile2(),
it's certainly of interest that the tmpfile() call is failing:

void
open_tmpfile2(void)
{
if (pc->tmpfile2)
error(FATAL, "recursive secondary temporary file usage
");

if ((pc->tmpfile2 = tmpfile()) == NULL)
error(FATAL, "cannot open secondary temporary file
");

rewind(pc->tmpfile2);
}

The man page for tmpfile() shows these reasons:

RETURN VALUE
The tmpfile() function returns a stream descriptor, or NULL if a unique
filename cannot be generated or the unique file cannot be opened. In
the latter case, errno is set to indicate the error.

ERRORS
EACCES Search permission denied for directory in file’s path prefix.

EEXIST Unable to generate a unique filename.

EINTR The call was interrupted by a signal.

EMFILE Too many file descriptors in use by the process.

ENFILE Too many files open in the system.

ENOSPC There was no room in the directory to add the new filename.

EROFS Read-only filesystem.

A couple things you might try:

(1) Put a perror() after the tmpfile() call to determine which errno
is being returned.
(2) Set "pc->flags |= DROP_CORE;" prior to the tmpfile() call.

Like this:

void
open_tmpfile2(void)
{
if (pc->tmpfile2)
error(FATAL, "recursive secondary temporary file usage
");

+ pc->flags |= DROP_CORE;
- if ((pc->tmpfile2 = tmpfile()) == NULL)
+ if ((pc->tmpfile2 = tmpfile()) == NULL) {
+ perror("tmpfile");
error(FATAL, "cannot open secondary temporary file
");
+ }
pc->flags &= ~DROP_CORE;

rewind(pc->tmpfile2);
}

Then get a backtrace by running gdb on the resultant core file, or just
run the whole session from gdb.

Dave






--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 

Thread Tools




All times are GMT. The time now is 08:51 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org