Aaron Tomlin | 6 Jul 10:20 2015
Picon

[PATCH 1/2] dis: Make the starting address of a function special for hexadecimal targets too

If no count is not entered, and the target address is the starting address
of a function, disassemble the entire function.
However this is only true, if the given target is symbolic.

This patch simply removes that restriction when the target is a hexadecimal
address:

For example, each of the following commands will return the same result.

 - Where 0xffffffff80137e9d is assumed to be the address of the
   first instruction in do_fork()

  crash> dis 0xffffffff80137e9d
  crash> dis do_fork

Signed-off-by: Aaron Tomlin <atomlin <at> redhat.com>
---
 kernel.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel.c b/kernel.c
index 4932282..628779c 100644
--- a/kernel.c
+++ b/kernel.c
 <at>  <at>  -1436,6 +1436,8  <at>  <at>  cmd_dis(void)
 					req->addr);
 				unfiltered = TRUE;
 			}
+			if (!offset)
+				req->flags |= GNU_FUNCTION_ONLY;
(Continue reading)

Rabin Vincent | 4 Jul 22:10 2015
Picon

[PATCH] extensions: use -m32 for target=MIPS build of eppic

Force -m32 in eppic.mk, similiar to how it's already done for ARM and
X86.
---
 extensions/eppic.mk |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/extensions/eppic.mk b/extensions/eppic.mk
index 7421ebc..de3ff4f 100644
--- a/extensions/eppic.mk
+++ b/extensions/eppic.mk
 <at>  <at>  -16,6 +16,9  <at>  <at>  endif
 ifeq ($(TARGET), ARM)
         TARGET_FLAGS += -m32
 endif
+ifeq ($(TARGET), MIPS)
+        TARGET_FLAGS += -m32
+endif
 ifeq ($(TARGET), X86)
         TARGET_FLAGS += -m32
 endif
--

-- 
1.7.10.4

Rabin Vincent | 3 Jul 14:33 2015
Picon

task: recursive temporary file usage

Hi,

If I try to print a non-existing member of task_struct with foreach, I get
expected error messages:

 crash> foreach task -R invalid
 PID: 0      TASK: 806d9d30  CPU: 0   COMMAND: "swapper/0"
 task: invalid: not a task_struct or thread_info member

 PID: 0      TASK: 8fce2808  CPU: 1   COMMAND: "swapper/1"
 task: invalid: not a task_struct or thread_info member

 PID: 1      TASK: 8fc9c768  CPU: 0   COMMAND: "systemd"
 task: invalid: not a task_struct or thread_info member

But, if I try to do this with a non-existing submember of an existing
member, I get 'recursive temporary file usage':

 crash> foreach task -R se.invalid
 PID: 0      TASK: 806d9d30  CPU: 0   COMMAND: "swapper/0"
 task: invalid data structure member reference: se.invalid
 task: recursive temporary file usage
 task: recursive temporary file usage
 task: recursive temporary file usage
 task: recursive temporary file usage

This is with the the latest crash from git.  I think this started from
the patches which introduced the deep-printing of structures.  I haven't
investigated further yet, though.

(Continue reading)

Arseniy Krasnov | 3 Jul 10:15 2015

Re: [PATCH] read physical memory layout from device tree (32-bit ARM)

Sorry for patch mistakes...

> Looking at the kernel sources, I can't understand exactly how it works
with multiple physical base addresses?
> There is another __virt_to_phys() that is constrained to
CONFIG_PATCH_ARM_PHYS_VIRT, but it seems to depend
> on !SPARSEMEM?  Can you explain how the kernel does it?
Exactly!, i've found another __virt_to_phys() in our kernel, which works in
same way as vtop_sparse() in my patch.

> Your dumpfile is an ELF vmcore.  Can you show me the output of "readelf
-a"
> on your vmcore?
Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  NOTE           0x0000d4 0x00000000 0x00000000 0x00850 0x00850     0
  LOAD           0x000924 0xc0000000 0x20000000 0xf800000 0xf800000 RWE 0
  LOAD           0xf800924 0xe0000000 0x40000000 0x00000 0x00000 RWE 0
  LOAD           0xf800924 0xe1000000 0x41000000 0x2b000000 0x2b000000 RWE 0
  LOAD           0x3a800924 0x24800000 0x84800000 0x2b000000 0x2b000000 RWE
0
Yes it reflects memory regions of board, but not precisely(I don't know
why). As you can see third PT_LOAD has
PhysAddr more for 0x1000000 than needed, may be previous PT_LOAD with
0x40000000 and size 0 must be considered.

> I don't know what "provided device tree" file means.  Where does the file
come from?
It is just binary file with information about hardware which used by kernel
during boot. Also there is information
(Continue reading)

Arseniy Krasnov | 2 Jul 11:15 2015

[PATCH] read physical memory layout from device tree

Sorry, forgot to set subject...

Hello Dave,
here is patch mentioned in bug
https://bugzilla.redhat.com/show_bug.cgi?id=1238151.
It adds new option "--dtbmem" which reads physical memory layout from
provided device tree and use it for kernel virtual
to physical memory address translation. This is needed because some unusual
boards have sparse memory and it is impossible
to translate address using offset cause memory "holes" must be considered.
Fail occurs during read of "mem_section" symbol.
With this patch everything works ok. I use device tree parser based on
'fdtdump' utility from device tree compiler.

Of course it is just basic concept and code doesn't look good, but if this
idea will be useful i'll improve it.

>From a634cf95aadff1a4372f066cca009332bcec2fc6 Mon Sep 17 00:00:00 2001
From: Arseniy Krasnov <a.krasnov <at> samsung.com>
Date: Wed, 1 Jul 2015 10:26:34 +0300
Subject: [PATCH] crashtool: phys memory layout from device tree.

---
 Makefile  |   7 +-
 arm.c     |  39 +++++++-
 defs.h    |   9 ++
 main.c    |   8 +-
 mem_dtb.c | 299
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 354 insertions(+), 8 deletions(-)  create mode 100644
(Continue reading)

Arseniy Krasnov | 2 Jul 09:38 2015

(no subject)

Hello Dave,
here is patch mentioned in bug
https://bugzilla.redhat.com/show_bug.cgi?id=1238151.
It adds new option "--dtbmem" which reads physical memory layout from
provided device tree and
use it for kernel virtual to physical memory address translation. This is
needed because some
unusual boards have sparse memory and it is impossible to translate address
using offset cause
memory "holes" must be considered. Fail occurs during read of "mem_section"
symbol. With this
patch everything works ok. I use device tree parser based on 'fdtdump'
utility from device tree
compiler.

Of course it is just basic concept and code doesn't look good, but if this
idea will be useful
i'll improve it.

>From a634cf95aadff1a4372f066cca009332bcec2fc6 Mon Sep 17 00:00:00 2001
From: Arseniy Krasnov <a.krasnov <at> samsung.com>
Date: Wed, 1 Jul 2015 10:26:34 +0300
Subject: [PATCH] crashtool: phys memory layout from device tree.

---
 Makefile  |   7 +-
 arm.c     |  39 +++++++-
 defs.h    |   9 ++
 main.c    |   8 +-
 mem_dtb.c | 299
(Continue reading)

Rabin Vincent | 1 Jul 21:23 2015
Picon

[PATCH] Make runq -g work without RT_GROUP_SCHED

CONFIG_FAIR_GROUP_SCHED (which provides task_group.cfs_rq) and
CONFIG_RT_GROUP_SCHED (which provides task_group.rt_rq) need not be both
enabled in a kernel.  Let's support runq -g even if only one of them is
enabled.
---
 task.c |   46 ++++++++++++++++++++++++++++------------------
 1 file changed, 28 insertions(+), 18 deletions(-)

diff --git a/task.c b/task.c
index 3a88d68..3e6aff4 100644
--- a/task.c
+++ b/task.c
 <at>  <at>  -7747,8 +7747,8  <at>  <at>  cmd_runq(void)
 			dump_milliseconds_flag = 1;
 			break;
 		case 'g':
-			if (INVALID_MEMBER(task_group_cfs_rq) ||
-			    INVALID_MEMBER(task_group_rt_rq) ||
+			if ((INVALID_MEMBER(task_group_cfs_rq) &&
+			     INVALID_MEMBER(task_group_rt_rq)) ||
 			    INVALID_MEMBER(task_group_parent))
 				option_not_supported(c);
 			dump_task_group_flag = 1;
 <at>  <at>  -9134,8 +9134,8  <at>  <at>  static void
 dump_tasks_by_task_group(void)
 {
 	int cpu, displayed;
-	ulong root_task_group, cfs_rq, cfs_rq_p;
-	ulong rt_rq, rt_rq_p;
+	ulong root_task_group, cfs_rq = 0, cfs_rq_p;
(Continue reading)

yangoliver | 26 Jun 15:55 2015
Picon

[PATCH v4] files: support dump file memory mapping

Hi Dave,

This is v4 patch for files memory mapping dump support.

The major changes in this version are,

1. Your alignment patch for NRPAGES

2. Changed files -a to files -p

   Changed output and displayed INODE, ADDRESS_SPACE, NRPAGES
   at beginning.

3. Updated help.c and added exmaple outputs for new options.

4. Some minor code cleanup, for function name defined in defs.h

Here is my patch,

Added two options in files command,

1. -m option, which allows dump file mapping and
   page count for each files
2. -p option, which could dump each pages within
   the mapping for given inode address

The foreach command also could work with -m, so
that we can easily find which processes/files hold
biggest page cache within the system.

(Continue reading)

yangoliver | 24 Jun 17:48 2015
Picon

[PATCH v3] files: support dump file memory mapping

Dave,

This is the v3 of patch for memory mapping dump support in files cmd.

This version patch fixed following problems,

1. Rebased to latest crash upstream.

2. Cleanup unnecessary code in defs.h.

3. Add RADIX_TREE_DUMP_CB, make do_radix_tree API unchange for other flags.

4. Fixed line up problems on 32bit kernel

   ADDR_SPACE got changed by MAPPING.
   PAGE-COUNT got changed by PAGE-CNT.

5. New files CLI options 

   -m replaced -M, and -a replaced original -m

   files -a use inode address instead of address space.
   This change make files -a more separate with files -m.
   I did see the debug scenario that use file -a separately.

6. Added basic helps information.

   Will update exmaple info later, after review is done.

Below is the v3 patch, let me know your comments.
(Continue reading)

Michael Holzheu | 22 Jun 18:58 2015
Picon

ps: issue with "waking" and "parked" task states?

Hi Dave,

I recently looked into a linux 4.0 dump where the "ps" command prints "??"
for the state field of several tasks:

crash> ps
    741    660   1      7b408000      ??   0.0    2152   2592  chcpu
    748      2  24      20c284f00     IN   0.0       0      0  [migration/24]
    752      2  22      20b1ccf00     ??   0.0       0      0  [migration/25]

Looking at the "task_struct->state" I get the following:

 crash> task_struct 7b408000 | grep state
   state = 0x100,
 crash> task_struct 20b1ccf00 | grep state
   state = 0x200

Looking into include/linux/sched.h states are defined as follows:

 #define TASK_RUNNING            0
 ...
 #define TASK_WAKING             256
 #define TASK_PARKED             512

When I issue "help -t" I get the following:

           RUNNING:   0 (0x0)
     INTERRUPTIBLE:   1 (0x1)
   UNINTERRUPTIBLE:   2 (0x2)
           STOPPED:   4 (0x4)
(Continue reading)

yangoliver | 17 Jun 17:49 2015
Picon

[PATCH v2] files: support dump file pages from its address space

Dave,

Sorry, I can't reply the mail to orignial thread, as my vpn got
blocked and I can't access my gmail account.

This is the v2 version of files -M and -m support. Following issues got
fixed in this version,

1. Patch is based on current git HEAD

2. Fixed warnings during make warn

3. files -M show full file path

4. Change PGCACHE-PGS to PAGE-COUNT

   Some background informtion: Each Linux fd points to a file struct.
   And each file struct or inode had a address space. If the file is
   a regular file, the address space defined a page tree, which are the
   page caches for this file. Some of file types don't use page cache.
   Page tree support was from 2.6 kernel, I couldn't access early Linux
   commit log. But at least 2.6.8 already had the definition.

5. Fixied page tree dump bugs, make sure page dump matched page number

   This is a bug in my radix tree dump code.
   I will share a method to valid page dumps later.

6. Use common dump_mem_map api instead of SPARSEMEM version

(Continue reading)


Gmane