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-13-2012, 09:08 AM
paawan oza
 
Default using crash for ARM

Hi,

here is the log which I m trying from gdb now.hope this stack trace helps.

./gdb --args ./crash ./vmlinux ./System.map******************** ****************** <
GNU gdb (GDB) 7.3.1
Copyright (C) 2011 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 "arm-none-linux-gnueabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /system/crash...done.
(gdb) start
Temporary breakpoint 1 at 0x8224: file main.c, line 78.
Starting program: /system/crash ./vmlinux ./System.map

Temporary breakpoint 1, main (argc=3, argv=0xbefffba4) at main.c:78
78***** main.c: No such file or directory.
******* in main.c
(gdb) bt
#0* main (argc=3, argv=0xbefffba4) at main.c:78
(gdb) b open_tmpfile2
Breakpoint 2 at 0x6d46c: file filesys.c, line 1126.
(gdb) c
Continuing.

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.

GNU gdb (GDB) 7.3.1
Copyright (C) 2011 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
"arm-none-linux-gnueabi"...

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


Breakpoint 2, open_tmpfile2 () at filesys.c:1126
1126*** filesys.c: No such file or directory.
******* in filesys.c
(gdb) bt
#0* open_tmpfile2 () at filesys.c:1126
#1* 0x000f324c in anon_member_offset (name=0x433604 "page",
*** member=0x433680 "mapping") at symbols.c:5104
#2* 0x000f2c4c in datatype_info (name=0x433604 "page",
*** member=0x433680 "mapping", dm=0xfffffffe) at symbols.c:4930
#3* 0x000260f0 in vm_init () at memory.c:383
#4* 0x0000b1a0 in main_loop () at main.c:644
#5* 0x00173050 in current_interp_command_loop () at interps.c:288
#6* 0x001749b0 in captured_command_loop (data="" at ./main.c:228
#7* 0x00172a50 in
catch_errors (func=0x1749a8 <captured_command_loop>,
*** func_args=0x0, errstring=0x506b88 "", mask=<optimized out>)
*** at exceptions.c:531
#8* 0x0017431c in captured_main (data="" out>) at ./main.c:958
#9* 0x00172a50 in catch_errors (func=0x173818 <captured_main>,
*** func_args=0xbefff9d8, errstring=0x506b88 "", mask=<optimized out>)
*** at exceptions.c:531
#10 0x00173628 in gdb_main (args=<optimized out>) at ./main.c:973
#11 gdb_main_entry (argc=<optimized out>, argv=<optimized out>)
*** at ./main.c:993
#12 0x000bed6c in gdb_main_loop (argc=2, argv=0xbefffba4)
*** at gdb_interface.c:76
#13 0x0000b014 in main (argc=3, argv=0xbefffba4) at main.c:604
(gdb) n
1129*** in filesys.c
(gdb) c
Continuing.
tmpfile: No such file or
directory
error no is 2
crash: cannot open secondary temporary file

[/system/crash] error trace: f2c4c => f324c => 6d508 => 13138
crash: /usr/bin/nm: no such file
DROP_CORE flag set: forcing a segmentation fault

Program received signal SIGQUIT, Quit.
0x003be42c in kill ()
(gdb)
PS: I am pretty sure that I am taking vmlinux from the same build and System.map as well, but that should not be a problem as long as crash had gone ahead.
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: Friday, 10 August 2012 10:01 PM
Subject: Re: [Crash-utility] 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
 
Old 08-13-2012, 09:38 AM
paawan oza
 
Default using crash for ARM

Hi,
I just thought it might be file creation issue and permission issue.with change as following: I am able to get to crash prompt.
void
open_tmpfile2(void)
{
******* if (pc->tmpfile2)
*************** error(FATAL, "recursive secondary temporary file usage
");

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

****** pc->tmpfile2 = fopen ("/system/tmp", "w"
);
****** if (pc->tmpfile2 == NULL) {
********** printf("error no is %d",errno);
****** perror("tmpfile");

****** error(FATAL, "cannot open secondary temporary file
");
***** }
* //***** pc->flags &= ~DROP_CORE;
******* rewind(pc->tmpfile2);
}

/system is mounted as read-write filesystem, I thought read-only file-system might be the issue.

still I get some warnings
shell@android:/system # ./crash ./vmlinux ./System.map

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.

GNU gdb (GDB) 7.3.1
Copyright (C) 2011 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 "arm-none-linux-gnueabi"...

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

crash: invalid size request: 0* type: "array cache array"
crash: unable to initialize kmem slab cache subsystem

* SYSTEM MAP: ./System.map
DEBUG KERNEL: ./vmlinux
*** DUMPFILE: /dev/mem
******* CPUS: 1
******* DATE: Sat Jan* 1 04:19:18 2000
***** UPTIME: 01:02:54
LOAD AVERAGE: 1.28, 0.98, 0.76
****** TASKS: 505
*** NODENAME: localhost
**** RELEASE: 3.0.15+
**** VERSION: #4 PREEMPT Mon Aug 13 12:02:58 IST 2012
**** MACHINE: armv7l* (unknown Mhz)
*****
MEMORY: 462 MB
******** PID: 2559
**** COMMAND: "crash"
******* TASK: d2b2b140* [THREAD_INFO: d170c000]
******** CPU: 0
****** STATE: TASK_RUNNING (ACTIVE)

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: Friday, 10 August 2012 10:01 PM
Subject: Re: [Crash-utility] 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
 
Old 08-13-2012, 05:55 PM
Dave Anderson
 
Default using crash for ARM

----- Original Message -----
>
>
> Hi,
>
>
> I just thought it might be file creation issue and permission issue.
> with change as following: I am able to get to crash prompt.
>
>
> void
> open_tmpfile2(void)
> {
> if (pc->tmpfile2)
> error(FATAL, "recursive secondary temporary file usage
");
>
> // pc->flags |= DROP_CORE;
> // if ((pc->tmpfile2 = tmpfile()) == NULL)
> // error(FATAL, "cannot open secondary temporary file
");
>
> pc->tmpfile2 = fopen ("/system/tmp", "w" );
> if (pc->tmpfile2 == NULL) {
> printf("error no is %d",errno);
> perror("tmpfile");
>
> error(FATAL, "cannot open secondary temporary file
");
> }
> // pc->flags &= ~DROP_CORE;
> rewind(pc->tmpfile2);
> }
>
>
>
> /system is mounted as read-write filesystem, I thought read-only
> file-system might be the issue.

You will need to do the same kind of thing for the open_tmpfile() function
as well.

I thought that setting a TMPDIR environment variable might allow you to use
an alternate directory from "/tmp", but that doesn't seem to apply to tmpfile()
usage.

>
>
> still I get some warnings
>
>
> shell@android:/system # ./crash ./vmlinux ./System.map
>
> 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.
>
> GNU gdb (GDB)jj 7.3.1
> Copyright (C) 2011 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 "arm-none-linux-gnueabi"...
>
> WARNING: kernels compiled by different gcc versions:
> ./vmlinux: (unknown)
> live system kernel: 4.4.3

I asked this before, but did you ever show the output of:

$ strings ./vmlinux | grep "Linux version"

It should match the output of /proc/version w/respect to the
gcc version embedded in the linux_banner string that was
used to compile the kernel.

> crash: invalid size request: 0 type: "array cache array"
> crash: unable to initialize kmem slab cache subsystem

For some reason, the call in vm_init() here is failing to initialize
the array length of the kmem_cache.array[] array:

}
MEMBER_OFFSET_INIT(kmem_cache_s_array, "kmem_cache", "array");
====> ARRAY_LENGTH_INIT(len, NULL, "kmem_cache.array", NULL, 0);
}
MEMBER_OFFSET_INIT(slab_list, "slab", "list");
MEMBER_OFFSET_INIT(slab_s_mem, "slab", "s_mem");
MEMBER_OFFSET_INIT(slab_inuse, "slab", "inuse");

The ARRAY_LENGTH_INIT() macro ends up calling get_array_length(),
passing "kmem_cache.array" as the first argument. It should end up
using the open_tmpfile2() function to parse the output of the gdb
command "ptype struct kmem_cache".

After you get a crash> prompt, what do you see when you enter this?:

crash> ptype struct kmem_cache

For example, I see this on a RHEL5 kernel:

crash> ptype struct kmem_cache
type = struct kmem_cache {
struct array_cache *array[255];
unsigned int batchcount;
unsigned int limit;
unsigned int shared;
unsigned int buffer_size;
struct kmem_list3 *nodelists[64];
unsigned int flags;
unsigned int num;
unsigned int gfporder;
gfp_t gfpflags;
size_t colour;
unsigned int colour_off;
struct kmem_cache *slabp_cache;
unsigned int slab_size;
unsigned int dflags;
void (*ctor)(void *, struct kmem_cache *, long unsigned int);
void (*dtor)(void *, struct kmem_cache *, long unsigned int);
const char *name;
struct list_head next;
}
crash>

Dave


>
> SYSTEM MAP: ./System.map
> DEBUG KERNEL: ./vmlinux
> DUMPFILE: /dev/mem
> CPUS: 1
> DATE: Sat Jan 1 04:19:18 2000
> UPTIME: 01:02:54
> LOAD AVERAGE: 1.28, 0.98, 0.76
> TASKS: 505
> NODENAME: localhost
> RELEASE: 3.0.15+
> VERSION: #4 PREEMPT Mon Aug 13 12:02:58 IST 2012
> MACHINE: armv7l (unknown Mhz)
> MEMORY: 462 MB
> PID: 2559
> COMMAND: "crash"
> TASK: d2b2b140 [THREAD_INFO: d170c000]
> CPU: 0
> STATE: TASK_RUNNING (ACTIVE)
>
> 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: Friday, 10 August 2012 10:01 PM
> Subject: Re: [Crash-utility] 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
 
Old 08-14-2012, 08:51 AM
paawan oza
 
Default using crash for ARM

strings ./vmlinux | grep "Linux version"
Linux version 3.0.15+ (oza@lc-blr-291) (gcc version 4.4.3 (GCC) ) #4 PREEMPT Mon Aug 13 12:02:58 IST 2012

cat /proc/version
Linux version 3.0.15+ (oza@lc-blr-291) (gcc version 4.4.3 (GCC) ) #4 PREEMPT Mon Aug 13 12:02:58 IST 2012
crash> ptype struct kmem_cache
type = struct kmem_cache {
*** struct array_cache *array[1];
*** unsigned int batchcount;
*** unsigned int limit;
*** unsigned int shared;
*** unsigned int buffer_size;
*** u32 reciprocal_buffer_size;
*** unsigned int flags;
*** unsigned int num;
*** unsigned int
gfporder;
*** gfp_t gfpflags;
*** size_t colour;
*** unsigned int colour_off;
*** struct kmem_cache *slabp_cache;
*** unsigned int slab_size;
*** unsigned int dflags;
*** void (*ctor)(void *);
*** const char *name;
*** struct list_head next;
*** struct kmem_list3 *nodelists[1];
}
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: Monday, 13 August 2012 11:25 PM
Subject: Re: [Crash-utility] using crash for ARM



----- Original Message -----
>
>
> Hi,
>
>
> I just thought it might be file creation issue and permission issue.
> with change as following: I am able to get to crash prompt.
>
>
> void
> open_tmpfile2(void)
> {
> if (pc->tmpfile2)
> error(FATAL, "recursive secondary temporary file usage
");
>
> // pc->flags |= DROP_CORE;
> // if ((pc->tmpfile2 = tmpfile()) == NULL)
> // error(FATAL, "cannot open secondary temporary file
");
>
> pc->tmpfile2 = fopen
("/system/tmp", "w" );
> if (pc->tmpfile2 == NULL) {
> printf("error no is %d",errno);
> perror("tmpfile");
>
> error(FATAL, "cannot open secondary temporary file
");
> }
> // pc->flags &= ~DROP_CORE;
> rewind(pc->tmpfile2);
> }
>
>
>
> /system is mounted as read-write filesystem, I thought read-only
> file-system might be the issue.

You will need to do the same kind of thing for the open_tmpfile() function
as well.

I thought that setting a TMPDIR environment variable might allow you to use
an alternate directory from "/tmp", but that doesn't seem to apply to tmpfile()
usage.

>
>
> still I get some warnings
>
>
> shell@android:/system # ./crash ./vmlinux ./System.map
>
> 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.
>
> GNU gdb (GDB)jj 7.3.1
> Copyright (C) 2011 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 "arm-none-linux-gnueabi"...
>
> WARNING: kernels compiled by different gcc versions:
> ./vmlinux: (unknown)
> live system kernel: 4.4.3

I asked this before, but did you ever show the output of:

* $ strings ./vmlinux | grep "Linux version"

It should match the output of /proc/version w/respect to the
gcc version embedded in the linux_banner string that was
used to compile the kernel.

> crash: invalid size request: 0 type: "array cache array"
> crash: unable to initialize kmem slab cache subsystem

For some reason, the call in vm_init() here is failing to initialize
the array length of the kmem_cache.array[] array:

* * * *
* * * * * * * * }
* * * * * * * * * * * * MEMBER_OFFSET_INIT(kmem_cache_s_array, "kmem_cache", "array");
* ====>* * * * * * * * ARRAY_LENGTH_INIT(len, NULL, "kmem_cache.array", NULL, 0);
* * * * * * * * }
* * * * * * * * MEMBER_OFFSET_INIT(slab_list, "slab", "list");
* * * * * * * * MEMBER_OFFSET_INIT(slab_s_mem, "slab", "s_mem");
* * * * * * * * MEMBER_OFFSET_INIT(slab_inuse, "slab", "inuse");

The ARRAY_LENGTH_INIT() macro ends up calling get_array_length(),
passing "kmem_cache.array" as the first argument.* It should end up
using the open_tmpfile2() function to parse the output of the gdb
command "ptype struct
kmem_cache".

After you get a crash> prompt, what do you see when you enter this?:

* crash> ptype struct kmem_cache

For example, I see this on a RHEL5 kernel:

* crash> ptype struct kmem_cache
* type = struct kmem_cache {
* * * struct array_cache *array[255];
* * * unsigned int batchcount;
* * * unsigned int limit;
* * * unsigned int shared;
* * * unsigned int buffer_size;
* * * struct kmem_list3 *nodelists[64];
* * * unsigned int flags;
* * * unsigned int num;
* * * unsigned int gfporder;
* * * gfp_t gfpflags;
* * * size_t colour;
* * * unsigned int colour_off;
* * * struct kmem_cache *slabp_cache;
* * * unsigned int slab_size;
* * *
unsigned int dflags;
* * * void (*ctor)(void *, struct kmem_cache *, long unsigned int);
* * * void (*dtor)(void *, struct kmem_cache *, long unsigned int);
* * * const char *name;
* * * struct list_head next;
* }
* crash>

Dave


>
> SYSTEM MAP: ./System.map
> DEBUG KERNEL: ./vmlinux
> DUMPFILE: /dev/mem
> CPUS: 1
> DATE: Sat Jan 1 04:19:18 2000
> UPTIME: 01:02:54
> LOAD AVERAGE: 1.28, 0.98, 0.76
> TASKS: 505
> NODENAME: localhost
> RELEASE: 3.0.15+
> VERSION: #4 PREEMPT Mon Aug 13 12:02:58 IST 2012
> MACHINE: armv7l (unknown Mhz)
> MEMORY: 462 MB
> PID: 2559
> COMMAND: "crash"
> TASK: d2b2b140 [THREAD_INFO: d170c000]
> CPU: 0
> STATE: TASK_RUNNING (ACTIVE)
>
> 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: Friday, 10 August 2012 10:01 PM
> Subject: Re: [Crash-utility] 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
 
Old 08-14-2012, 02:16 PM
Dave Anderson
 
Default using crash for ARM

----- Original Message -----
>
>
> strings ./vmlinux | grep "Linux version"
> Linux version 3.0.15+ (oza@lc-blr-291) (gcc version 4.4.3 (GCC) ) #4 PREEMPT Mon Aug 13 12:02:58 IST 2012
>
> cat /proc/version
> Linux version 3.0.15+ (oza@lc-blr-291) (gcc version 4.4.3 (GCC) ) #4 PREEMPT Mon Aug 13 12:02:58 IST 2012

Looks OK -- so you'll have to debug verify_namelist(). It does a
popen("/usr/bin/strings ./vmlinux") and searches for the linux_banner
string here:

while (fgets(buffer, BUFSIZE-1, pipe)) {
if (!strstr(buffer, "Linux version 2.") &&
!strstr(buffer, "Linux version 3."))
continue;

and when it finds it, it picks out the gcc version number. I don't
know why it's not working in your case.

Also, since your vmlinux file is identical to /proc/version, why are
you using a System.map argument again?

>
> crash> ptype struct kmem_cache
> type = struct kmem_cache {
> struct array_cache *array[1];
> unsigned int batchcount;
> unsigned int limit;
> unsigned int shared;
> unsigned int buffer_size;
> u32 reciprocal_buffer_size;
> unsigned int flags;
> unsigned int num;
> unsigned int gfporder;
> gfp_t gfpflags;
> size_t colour;
> unsigned int colour_off;
> struct kmem_cache *slabp_cache;
> unsigned int slab_size;
> unsigned int dflags;
> void (*ctor)(void *);
> const char *name;
> struct list_head next;
> struct kmem_list3 *nodelists[1];
> }

OK, in this case you'll have to debug get_array_length(), and figure
out why it's not finding the lookfor2 string -- which should be set
to "*array[" -- in the ptype command output. Again, I don't know
why it's not finding it.

Dave

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

Paawan,

Right -- it looks to be a bug, presuming that ARM is using 1MB pages
for the unity-mapped region:

crash> vtop c0000000 | grep PAGE:
PAGE: 11000 (1MB)
crash> vtop c0100000 | grep PAGE:
PAGE: 11000 (1MB)
crash> vtop c0200000 | grep PAGE:
PAGE: 211000 (1MB)
crash> vtop c0300000 | grep PAGE:
PAGE: 211000 (1MB)
crash> vtop c0400000 | grep PAGE:
PAGE: 411000 (1MB)
crash> vtop c0500000 | grep PAGE:
PAGE: 411000 (1MB)
crash>

And confusing the issue even more, when the virtual memory is read,
the data at c0000000 and c0100000 is different (as expected), but the
virtual-to-physical translation "paddr:" value indicates different
physical addresses that what are shown above:

crash> set debug 4
debug: 4
crash> rd c0000000
<addr: c0000000 count: 1 flag: 488 (KVADDR)>
<readmem: c0000000, KVADDR, "32-bit KVADDR", 4, (FOE), ff8bea60>
<read_kdump: addr: c0000000 paddr: 0 cnt: 4>
c0000000: ea000012 ....
crash> rd c0100000
<addr: c0100000 count: 1 flag: 488 (KVADDR)>
<readmem: c0100000, KVADDR, "32-bit KVADDR", 4, (FOE), ff8bea60>
<read_kdump: addr: c0100000 paddr: 100000 cnt: 4>
c0100000: 3694c21d ...6
crash>

In other words, above it shows that c0000000 is at physical address 0,
and that c0100000 is at 100000, i.e., not 11000 as shown by the
verbose vtop display.

I'll leave it up to the crash utility's ARM maintainers to come up
with the proper answer and fix for the verbose vtop display. I've
cc'd them with this email. Also please use the crash-utility@redhat.com
mailing list for these kinds of discussions.

Thanks,
Dave



----- Original Message -----
>
> Hi Dave,
>
> The section translation inside 'arm_vtop' function and getting to the
> physical address looks beyond my understanding.
>
> if (verbose)
> fprintf(fp, "PAGE DIRECTORY: %lx
", (ulong)pgd);
>
> /*
> * pgd_offset(pgd, vaddr)
> */
> page_dir = pgd + PGD_OFFSET(vaddr) * 2;
> FILL_PGD(PAGEBASE(pgd), KVADDR, PGDIR_SIZE());
> pgd_pte = ULONG(machdep->pgd + PGDIR_OFFSET(page_dir));
>
> if (verbose)
> fprintf(fp, " PGD: %s => %lx
",
> mkstring(buf, VADDR_PRLEN, RJUST | LONG_HEX,
> MKSTR((ulong)page_dir)), pgd_pte);
>
> if (!pgd_pte)
> return FALSE;
>
> /*
> * pmd_offset(pgd, vaddr)
> *
> * Here PMD is folded into a PGD.
> */
> pmd_pte = pgd_pte;
> page_middle = page_dir;
>
> if (verbose)
> fprintf(fp, " PMD: %s => %lx
",
> mkstring(buf, VADDR_PRLEN, RJUST | LONG_HEX,
> MKSTR((ulong)page_middle)), pmd_pte);
>
> if ((pmd_pte & PMD_TYPE_MASK) == PMD_TYPE_SECT) {
> if (verbose) {
> fprintf(fp, " PAGE: %s (1MB)

",
> mkstring(buf, VADDR_PRLEN, RJUST | LONG_HEX,
> MKSTR(PAGEBASE(pmd_pte))));
> }
> *paddr = PAGEBASE(pmd_pte) + (vaddr & ~_SECTION_PAGE_MASK);
> return TRUE;
> }
>
>
>
>
>
> if you look at
> page_dir = pgd + PGD_OFFSET(vaddr) * 2;
> FILL_PGD(PAGEBASE(pgd), KVADDR, PGDIR_SIZE());
> pgd_pte = ULONG(machdep->pgd + PGDIR_OFFSET(page_dir));
>
>
> the final first level discriptor is not coming properly for
> kernel virtual address with [20st counting from 0....n] bit set.
>
>
>
>
> if you look at the following output:
>
>
> crash> vtop 0xc010005c
> VIRTUAL PHYSICAL
> c010005c 8210005c
>
> PAGE DIRECTORY: c0004000
> PGD: c0007000 => 8200040e
> PMD: c0007000 => 8200040e
> PAGE: 82000000 (1MB)
>
>
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
> c103c000 82000000 c1d16f28 3 54 8027c
> crash> vtop 0xc000005c
> VIRTUAL PHYSICAL
> c000005c 8200005c
>
> PAGE DIRECTORY: c0004000
> PGD: c0007000 => 8200040e
> PMD: c0007000 => 8200040e
> PAGE: 82000000 (1MB)
>
>
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
> c103c000 82000000 c1d16f28 3 54 8027c
>
>
>
> virtual to physical mapping is fine, because it doesnt even go
> through arm_vtop() function.
> as it is straight one to one mapping, you use VTOP macro.
> so basically section code snippet which I sent you never come into
> picture.
> if you have a look at the both kernel virtual addresses
>
>
> 0xc010005c and
> 0xc000005c
> both are 1MB apart. but still following contents are same.
>
> PAGE DIRECTORY: c0004000
> PGD: c0007000 => 8200040e
> PMD: c0007000 => 8200040e
>
> PAGE: 82000000 (1MB)
>
>
> I shall clarify more, If you require more info.
> I hope I am not missing anything here.
>
>
>
> PS:
> If I want to have correct physical address corresponding to
> 0xc010005c
>
>
> then I have to do workaround for section level physical addresses as
> follows.
> page_dir = pgd + PGD_OFFSET(vaddr) * 2;
> if (bit(vaddr,20)) //if bit is set then move to the next pgd */
> page_dir = page_dir + 1;
> FILL_PGD(PAGEBASE(pgd), KVADDR, PGDIR_SIZE());
> pgd_pte = ULONG(machdep->pgd + PGDIR_OFFSET(page_dir));
>
>
>
> 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: Tuesday, 14 August 2012 7:46 PM
> Subject: Re: [Crash-utility] using crash for ARM
>
>
>
> ----- Original Message -----
> >
> >
> > strings ./vmlinux | grep "Linux version"
> > Linux version 3.0.15+ (oza@lc-blr-291) (gcc version 4.4.3 (GCC) )
> > #4 PREEMPT Mon Aug 13 12:02:58 IST 2012
> >
> > cat /proc/version
> > Linux version 3.0.15+ (oza@lc-blr-291) (gcc version 4.4.3 (GCC) )
> > #4 PREEMPT Mon Aug 13 12:02:58 IST 2012
>
> Looks OK -- so you'll have to debug verify_namelist(). It does a
> popen("/usr/bin/strings ./vmlinux") and searches for the linux_banner
> string here:
>
> while (fgets(buffer, BUFSIZE-1, pipe)) {
> if (!strstr(buffer, "Linux version 2.") &&
> !strstr(buffer, "Linux version 3."))
> continue;
>
> and when it finds it, it picks out the gcc version number. I don't
> know why it's not working in your case.
>
> Also, since your vmlinux file is identical to /proc/version, why are
> you using a System.map argument again?
>
> >
> > crash> ptype struct kmem_cache
> > type = struct kmem_cache {
> > struct array_cache *array[1];
> > unsigned int batchcount;
> > unsigned int limit;
> > unsigned int shared;
> > unsigned int buffer_size;
> > u32 reciprocal_buffer_size;
> > unsigned int flags;
> > unsigned int num;
> > unsigned int gfporder;
> > gfp_t gfpflags;
> > size_t colour;
> > unsigned int colour_off;
> > struct kmem_cache *slabp_cache;
> > unsigned int slab_size;
> > unsigned int dflags;
> > void (*ctor)(void *);
> > const char *name;
> > struct list_head next;
> > struct kmem_list3 *nodelists[1];
> > }
>
> OK, in this case you'll have to debug get_array_length(), and figure
> out why it's not finding the lookfor2 string -- which should be set
> to "*array[" -- in the ptype command output. Again, I don't know
> why it's not finding it.
>
> Dave
>
>
>

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

Is there anyway we can submit the patch and contribute form our side ?

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>; Mika Westerberg <mika.westerberg@iki.fi>; Thomas Fnge <thomas.fange@sonymobile.com>; jan karlsson
<jan.karlsson@sonymobile.com>
Sent: Wednesday, 3 October 2012 7:15 PM
Subject: Re: [Crash-utility] using crash for ARM

Paawan,

Right -- it looks to be a bug, presuming that ARM is using 1MB pages
for the unity-mapped region:

crash> vtop c0000000 | grep PAGE:
* PAGE:* * 11000* (1MB)
crash> vtop c0100000 | grep PAGE:
* PAGE:* * 11000* (1MB)
crash> vtop c0200000 | grep PAGE:
* PAGE:* 211000* (1MB)
crash> vtop c0300000 | grep PAGE:
* PAGE:* 211000* (1MB)
crash> vtop c0400000 | grep PAGE:
* PAGE:* 411000* (1MB)
crash> vtop c0500000 | grep PAGE:
* PAGE:* 411000* (1MB)
crash>

And confusing the issue even more, when the virtual memory is
read,
the data at c0000000 and c0100000 is different (as expected), but the
virtual-to-physical translation "paddr:" value indicates different
physical addresses that what are shown above:

crash> set debug 4
debug: 4
crash> rd c0000000
<addr: c0000000 count: 1 flag: 488 (KVADDR)>
<readmem: c0000000, KVADDR, "32-bit KVADDR", 4, (FOE), ff8bea60>
<read_kdump: addr: c0000000 paddr: 0 cnt: 4>
c0000000:* ea000012* * * * * * * * * * * * * * * ....
crash> rd c0100000
<addr: c0100000 count: 1 flag: 488 (KVADDR)>
<readmem: c0100000, KVADDR, "32-bit KVADDR", 4, (FOE), ff8bea60>
<read_kdump: addr: c0100000 paddr: 100000 cnt: 4>
c0100000:* 3694c21d* * * * * * * * * * * * * * * ...6
crash>

In
other words, above it shows that c0000000 is at physical address 0,
and that c0100000 is at 100000, i.e., not 11000 as shown by the
verbose vtop display.

I'll leave it up to the crash utility's ARM maintainers to come up
with the proper answer and fix for the verbose vtop display.* I've
cc'd them with this email.* Also please use the crash-utility@redhat.com
mailing list for these kinds of discussions.

Thanks,
* Dave



----- Original Message -----
>
> Hi Dave,
>
> The section translation inside 'arm_vtop' function and getting to the
> physical address looks beyond my understanding.
>
> if (verbose)
> fprintf(fp, "PAGE DIRECTORY: %lx
", (ulong)pgd);
>
> /*
> * pgd_offset(pgd, vaddr)
> */
> page_dir = pgd + PGD_OFFSET(vaddr) *
2;
> FILL_PGD(PAGEBASE(pgd), KVADDR, PGDIR_SIZE());
> pgd_pte = ULONG(machdep->pgd + PGDIR_OFFSET(page_dir));
>
> if (verbose)
> fprintf(fp, " PGD: %s => %lx
",
> mkstring(buf, VADDR_PRLEN, RJUST | LONG_HEX,
> MKSTR((ulong)page_dir)), pgd_pte);
>
> if (!pgd_pte)
> return FALSE;
>
> /*
> * pmd_offset(pgd, vaddr)
> *
> * Here PMD is folded into a PGD.
> */
> pmd_pte = pgd_pte;
> page_middle = page_dir;
>
> if (verbose)
> fprintf(fp, " PMD: %s => %lx
",
> mkstring(buf, VADDR_PRLEN, RJUST | LONG_HEX,
> MKSTR((ulong)page_middle)), pmd_pte);
>
> if ((pmd_pte & PMD_TYPE_MASK) == PMD_TYPE_SECT) {
> if (verbose) {
> fprintf(fp, " PAGE: %s (1MB)

",
> mkstring(buf, VADDR_PRLEN, RJUST | LONG_HEX,
> MKSTR(PAGEBASE(pmd_pte))));
> }
> *paddr = PAGEBASE(pmd_pte) +
(vaddr & ~_SECTION_PAGE_MASK);
> return TRUE;
> }
>
>
>
>
>
> if you look at
> page_dir = pgd + PGD_OFFSET(vaddr) * 2;
> FILL_PGD(PAGEBASE(pgd), KVADDR, PGDIR_SIZE());
> pgd_pte = ULONG(machdep->pgd + PGDIR_OFFSET(page_dir));
>
>
> the final first level discriptor is not coming properly for
> kernel virtual address with [20st counting from 0....n] bit set.
>
>
>
>
> if you look at the following output:
>
>
> crash> vtop 0xc010005c
> VIRTUAL PHYSICAL
> c010005c 8210005c
>
> PAGE DIRECTORY: c0004000
> PGD: c0007000 => 8200040e
> PMD: c0007000 => 8200040e
> PAGE: 82000000 (1MB)
>
>
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
> c103c000 82000000 c1d16f28 3 54 8027c
> crash> vtop 0xc000005c
> VIRTUAL
PHYSICAL
> c000005c 8200005c
>
> PAGE DIRECTORY: c0004000
> PGD: c0007000 => 8200040e
> PMD: c0007000 => 8200040e
> PAGE: 82000000 (1MB)
>
>
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
> c103c000 82000000 c1d16f28 3 54 8027c
>
>
>
> virtual to physical mapping is fine, because it doesnt even go
> through arm_vtop() function.
> as it is straight one to one mapping, you use VTOP macro.
> so basically section code snippet which I sent you never come into
> picture.
> if you have a look at the both kernel virtual addresses
>
>
> 0xc010005c and
> 0xc000005c
> both are 1MB apart. but still following contents are same.
>
> PAGE DIRECTORY: c0004000
> PGD: c0007000 => 8200040e
> PMD: c0007000 => 8200040e
>
> PAGE: 82000000 (1MB)
>
>
> I shall
clarify more, If you require more info.
> I hope I am not missing anything here.
>
>
>
> PS:
> If I want to have correct physical address corresponding to
> 0xc010005c
>
>
> then I have to do workaround for section level physical addresses as
> follows.
> page_dir = pgd + PGD_OFFSET(vaddr) * 2;
> if (bit(vaddr,20)) //if bit is set then move to the next pgd */
> page_dir = page_dir + 1;
> FILL_PGD(PAGEBASE(pgd), KVADDR, PGDIR_SIZE());
> pgd_pte = ULONG(machdep->pgd + PGDIR_OFFSET(page_dir));
>
>
>
> 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: Tuesday, 14 August 2012 7:46 PM
> Subject: Re: [Crash-utility] using crash for ARM
>
>
>
> ----- Original Message -----
> >
> >
> > strings ./vmlinux | grep "Linux version"
> > Linux version 3.0.15+ (oza@lc-blr-291) (gcc version 4.4.3 (GCC) )
> > #4 PREEMPT Mon Aug 13 12:02:58 IST 2012
> >
> > cat /proc/version
> > Linux version 3.0.15+ (oza@lc-blr-291) (gcc version 4.4.3 (GCC) )
> > #4 PREEMPT Mon Aug 13 12:02:58 IST 2012
>
> Looks OK -- so you'll have to debug verify_namelist(). It does a
> popen("/usr/bin/strings ./vmlinux") and
searches for the linux_banner
> string here:
>
> while (fgets(buffer, BUFSIZE-1, pipe)) {
> if (!strstr(buffer, "Linux version 2.") &&
> !strstr(buffer, "Linux version 3."))
> continue;
>
> and when it finds it, it picks out the gcc version number. I don't
> know why it's not working in your case.
>
> Also, since your vmlinux file is identical to /proc/version, why are
> you using a System.map argument again?
>
> >
> > crash> ptype struct kmem_cache
> > type = struct kmem_cache {
> > struct array_cache *array[1];
> > unsigned int batchcount;
> > unsigned int limit;
> > unsigned int shared;
> > unsigned int buffer_size;
> > u32 reciprocal_buffer_size;
> > unsigned int flags;
> > unsigned int num;
> > unsigned int gfporder;
> > gfp_t
gfpflags;
> > size_t colour;
> > unsigned int colour_off;
> > struct kmem_cache *slabp_cache;
> > unsigned int slab_size;
> > unsigned int dflags;
> > void (*ctor)(void *);
> > const char *name;
> > struct list_head next;
> > struct kmem_list3 *nodelists[1];
> > }
>
> OK, in this case you'll have to debug get_array_length(), and figure
> out why it's not finding the lookfor2 string -- which should be set
> to "*array[" -- in the ptype command output. Again, I don't know
> why it's not finding it.
>
> Dave
>
>
>


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 10-04-2012, 06:26 AM
Mika Westerberg
 
Default using crash for ARM

On Wed, Oct 03, 2012 at 09:45:51AM -0400, Dave Anderson wrote:
>
> Right -- it looks to be a bug, presuming that ARM is using 1MB pages
> for the unity-mapped region:
>
> crash> vtop c0000000 | grep PAGE:
> PAGE: 11000 (1MB)
> crash> vtop c0100000 | grep PAGE:
> PAGE: 11000 (1MB)
> crash> vtop c0200000 | grep PAGE:
> PAGE: 211000 (1MB)
> crash> vtop c0300000 | grep PAGE:
> PAGE: 211000 (1MB)
> crash> vtop c0400000 | grep PAGE:
> PAGE: 411000 (1MB)
> crash> vtop c0500000 | grep PAGE:
> PAGE: 411000 (1MB)
> crash>

The unity-mapped region is mapped using 1MB pages. However, we actually have
(when using the Linux ARM 2-level translation scheme):

see arch/arm/include/asm/pgtable-2level.h:

#define PMD_SHIFT 21
#define PGDIR_SHIFT 21

#define PTRS_PER_PGD 2048

So we have 2048 entries in a PGD instead of 4096 making a PGD entry an array
of "two pointers".

Anyway as you and Paawan suggested it looks like a bug - we always use the
first entry instead of the second given that bit 20 is set in the virtual
address.

Paawan, your fix looks sane to me but can you add a small comment describing
why this is done?

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 10-04-2012, 09:05 AM
Rabin Vincent
 
Default using crash for ARM

2012/10/4 Mika Westerberg <mika.westerberg@iki.fi>:
> The unity-mapped region is mapped using 1MB pages. However, we actually have
> (when using the Linux ARM 2-level translation scheme):
>
> see arch/arm/include/asm/pgtable-2level.h:
>
> #define PMD_SHIFT 21
> #define PGDIR_SHIFT 21
>
> #define PTRS_PER_PGD 2048
>
> So we have 2048 entries in a PGD instead of 4096 making a PGD entry an array
> of "two pointers".
>
> Anyway as you and Paawan suggested it looks like a bug - we always use the
> first entry instead of the second given that bit 20 is set in the virtual
> address.

Isn't the problem actually that we read the section entry wrong?
The following (and attached) is the fix I've been using for this.

Rabin

diff --git a/arm.c b/arm.c
index 5930c02..4e7b6dc 100644
--- a/arm.c
+++ b/arm.c
@@ -957,12 +957,14 @@ arm_vtop(ulong vaddr, ulong *pgd, physaddr_t
*paddr, int verbose)
MKSTR((ulong)page_middle)), pmd_pte);

if ((pmd_pte & PMD_TYPE_MASK) == PMD_TYPE_SECT) {
+ ulong sectionbase = pmd_pte & _SECTION_PAGE_MASK;
+
if (verbose) {
fprintf(fp, " PAGE: %s (1MB)

",
mkstring(buf, VADDR_PRLEN, RJUST | LONG_HEX,
- MKSTR(PAGEBASE(pmd_pte))));
+ MKSTR(sectionbase)));
}
- *paddr = PAGEBASE(pmd_pte) + (vaddr & ~_SECTION_PAGE_MASK);
+ *paddr = sectionbase + (vaddr & ~_SECTION_PAGE_MASK);
return TRUE;
}
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 10-04-2012, 10:44 AM
paawan oza
 
Default using crash for ARM

My comment for the fix would be something like below.
/* The unity-mapped region is mapped using 1MB pages, hence 1-level translation
*** if bit 20 is set, we are 1MB apart physically, hence we move the page_dir
*** in case bit 20 is set. */
if (bit(vaddr,20))
*** page_dir = page_dir + 1;
does it make sense ?
Regards,Oza.

From: Mika Westerberg <mika.westerberg@iki.fi>
To: Dave Anderson <anderson@redhat.com>
Cc: paawan oza <paawan1982@yahoo.com>; "Discussion list for crash utility usage, maintenance and development" <crash-utility@redhat.com>; Thomas Fnge <thomas.fange@sonymobile.com>; jan karlsson
<jan.karlsson@sonymobile.com>
Sent: Thursday, 4 October 2012 11:56 AM
Subject: Re: [Crash-utility] using crash for ARM

On Wed, Oct 03, 2012 at 09:45:51AM -0400, Dave Anderson wrote:
>
> Right -- it looks to be a bug, presuming that ARM is using 1MB pages
> for the unity-mapped region:
>*
>* crash> vtop c0000000 | grep PAGE:
>* PAGE:* * 11000* (1MB)
>* crash> vtop c0100000 | grep PAGE:
>* PAGE:* * 11000* (1MB)
>* crash> vtop c0200000 | grep PAGE:
>* PAGE:* 211000* (1MB)
>* crash> vtop c0300000 | grep PAGE:
>* PAGE:* 211000* (1MB)
>* crash> vtop c0400000 | grep PAGE:
>* PAGE:* 411000* (1MB)
>*
crash> vtop c0500000 | grep PAGE:
>* PAGE:* 411000* (1MB)
>* crash>

The unity-mapped region is mapped using 1MB pages. However, we actually have
(when using the Linux ARM 2-level translation scheme):

see arch/arm/include/asm/pgtable-2level.h:

#define PMD_SHIFT* * * * * * * 21
#define PGDIR_SHIFT* * * * * * 21

#define PTRS_PER_PGD* * * * * * 2048

So we have 2048 entries in a PGD instead of 4096 making a PGD entry an array
of "two pointers".

Anyway as you and Paawan suggested it looks like a bug - we always use the
first entry instead of the second given that bit 20 is set in the virtual
address.

Paawan, your fix looks sane to me but can you add a small comment describing
why this is done?


--
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 07:40 AM.

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