HuKeping | 30 Sep 13:49 2014

[PATCH] Endian-mismatch: crash shows a contrary error message

When the vmcore or vmlinux is not the same endian with the host,
crash will give out a error message to show that mismatching, but
the message itself is not correct.
This patch fix that logical bug.

Signed-off-by: Hu Keping <hukeping <at> huawei.com>
---
 tools.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools.c b/tools.c
index 4ff3fd5..cb684b1 100644
--- a/tools.c
+++ b/tools.c
 <at>  <at>  -5515,12 +5515,12  <at>  <at>  endian_mismatch(char *file, char dumpfile_endian, ulong query)
 	case ELFDATA2LSB:
 		if (__BYTE_ORDER == __LITTLE_ENDIAN)
 			return FALSE;
-		endian = "big-endian";
+		endian = "little-endian";
 		break;
 	case ELFDATA2MSB:
 		if (__BYTE_ORDER == __BIG_ENDIAN)	
 			return FALSE;
-		endian = "little-endian";
+		endian = "big-endian";
 		break;
 	default:
 		endian = "unknown";	
--

-- 
(Continue reading)

Qiao Nuohan | 29 Sep 04:08 2014

[PATCH v2 00/25] support hiding data of offline cpu

For those who don't care about the removed cpu, data of offline cpu is
bothering. This patchset is trying to hide data of offline cpu. Please
check each patch to see what is hiden.

The last version is here:
https://www.redhat.com/archives/crash-utility/2014-September/msg00000.html

Changelog:
v1->v2:
1. patch 1: add environment variable and its argument to hide/show
   data of offline cpu.
2. add description of environment variable to crash.8
3. remove the restrict of x86_64
4. add "<OFFLINE>" to indicate those hiden data.
5. patch 22/23: addd "<OFFLINE>" to indicate idle task on offline
   cpu

Qiao Nuohan (25):
  add a flag to display/hide data of offline cpus
  add an API to check whether to hide a cpus' data
  x86_64: modify help -m/-M to hide offline cpus' data
  x86_64: modify bt -E to hide offline cpus' data
  x86_64: modify mach to hide offline cpus' data
  x86_64: modify mach -c to hide offline cpus' data
  modify help -r to hide offline cpus' registers
  modify bt -c to hide offline cpus' data
  modify display_sys_stats() to hide cpus' number
  modify help -k to hide offline cpus' number
  modify set -c to hide offline cpu
  modify irq -s to hide offline cpus' data
(Continue reading)

HuKeping | 28 Sep 11:59 2014

[PATCH] arm32: fix "unknown HZ value" error

This patch fix the error info
"UPTIME: (cannot calculate: unknown HZ value)"
on arm(32 bit), if the CONFIG_IKCONFIG was not selected.

Signed-off-by: Hu Keping <hukeping <at> huawei.com>
---
 arm.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/arm.c b/arm.c
index 7405583..cfdc5f1 100644
--- a/arm.c
+++ b/arm.c
 <at>  <at>  -315,6 +315,9  <at>  <at>  arm_init(int when)
 				   "pr_pid");
 		MEMBER_OFFSET_INIT(elf_prstatus_pr_reg, "elf_prstatus",
 				   "pr_reg");
+	
+		if(!machdep->hz)
+			machdep->hz = 100;
 		break;

 	case POST_VM:
--

-- 
1.8.5.5

Mark Vitale | 25 Sep 18:07 2014
Picon

building an RPM w/ LZO support

I've been using crash 6.x for some time on Centos6, a binary RPM installed from a yum repo.
Yesterday I realized I didn't have the crash extensions installed.  And a yum
search found no listing for crash-extensions in my current repos.  

So I downloaded a 7.0.8 source RPM from crash-utility.com, built and installed it:

$ rpmbuild -vv --rebuild crash-7.0.8-0.src.rpm
$ cd ~/rpmbuild/RPMS/x86
$ sudo yum localinstall --nogpgcheck crash-7.0.8-0.rpm

But when I tested it on a previously working set of vmlinux/vmcore files, 
I got the following error:

crash: compressed kdump: uncompress failed: no lzo compression support 

I eventually ended up extracting the source rpm and doing:

$ cd ~/dev/src/crash-7.0.8
$ make lzo

and this copy of crash works.

However, I really wanted to make a new RPM out of this, but everything I tried
always ended up reverting to no LZO.  Looking at the configure.c source, I see
that 'make release' has a different method for building the Makefile which does 
not seem to allow for LZO. Is it possible to build an lzo-enabled rpm using 
crash configure and make?  Or with rpmbuild?  If so, how?

Thanks,
--
(Continue reading)

Hu Keping | 24 Sep 05:36 2014

About the comments

hi there,

I'm a freshman to CRASH, I want to make some contribute for it as I
found it very usefull, especially with Kdump.

But i run to a little trouble when i read the source code of it for
there is not enough comments for some critical data structures say,
struct syment, struct bt_info, etc.

I would really appreciate it if there would be some progress on that.

Thanks.

--
Hu Keping

Liu Hua | 21 Sep 04:14 2014

[PATCH V2] crash: arm32: a better way to identify LPAE enabled kernel

Thanks to Dave's suggest, I impove the way to identify
LPAE enabled kernel for arm platform, for compatibility with
some old kernel.

If a vmcore santisfy one of the following conditions, It must
be generated by a LPAE enabled kernel.

(1) it has CONFIG_ARM_LPAE=y vmcore_info
(2) swapper_pg_dir and its next symbol value differ by 0x5000

changes from V1:
 - drop function next_symbol_value

Signed-off-by: Liu Hua <sdu.liu <at> huawei.com>
---
 arm.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arm.c b/arm.c
index cb7d841..e7d3dbc 100644
--- a/arm.c
+++ b/arm.c
 <at>  <at>  -190,6 +190,8  <at>  <at>  void
 arm_init(int when)
 {
 	ulong vaddr;
+	char *string;
+	struct syment *sp;

 #if defined(__i386__) || defined(__x86_64__)
(Continue reading)

Vasily Averin | 19 Sep 13:07 2014

[patch] incorrect pid_ns check

Dear Dave,

I've found that crash does not find all tasks on OpenVZ kernels.
Currently pid_ns check in refresh_hlist_task_table_v3() checks only first entry 
in pid_hash[i] hlist. If this entry is not related to init_pid_ns
it forget about other entries in hlist and switches to next element
in pid_hash array.

Attached patch fix this problem.

Thank you,
	Vasily Averin
diff -up crash-7.0.8/task.c.pidns crash-7.0.8/task.c
--- crash-7.0.8/task.c.pidns	2014-09-11 11:08:25.000000000 -0400
+++ crash-7.0.8/task.c	2014-09-19 06:15:42.000000000 -0400
 <at>  <at>  -2033,7 +2033,7  <at>  <at>  do_chained:
 		 *  Use init_pid_ns level 0 (PIDTYPE_PID).
 		 */
 		if (upid_ns != tt->init_pid_ns)
-			continue;
+			goto chain_next;

 		pid = upid - OFFSET(pid_numbers);

diff -up crash-7.0.8/task.c.pidns crash-7.0.8/task.c
--- crash-7.0.8/task.c.pidns	2014-09-11 11:08:25.000000000 -0400
(Continue reading)

Liu Hua | 18 Sep 11:32 2014

[PATCH] crash: arm32: a better way to identify LPAE enabled kernel

Thanks to Dave's suggest, I impove the way to identify
LPAE enabled kernel for arm platform, for compatibility with
some old kernel.

If a vmcore santisfy one of the following conditions, It must
be generated by a LPAE enabled kernel.

(1) it has CONFIG_ARM_LPAE=y vmcore_info
(2) swapper_pg_dir and its next symbol value differ by 0x5000

Signed-off-by: Liu Hua <sdu.liu <at> huawei.com>
---
 arm.c     | 11 ++++++++++-
 symbols.c | 10 ++++++++++
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/arm.c b/arm.c
index cb7d841..76ba699 100644
--- a/arm.c
+++ b/arm.c
 <at>  <at>  -190,6 +190,8  <at>  <at>  void
 arm_init(int when)
 {
 	ulong vaddr;
+	char *string;
+	ulong difference;

 #if defined(__i386__) || defined(__x86_64__)
 	if (ACTIVE())
 <at>  <at>  -229,8 +231,15  <at>  <at>  arm_init(int when)
(Continue reading)

Liu Hua | 18 Sep 11:28 2014

[PATCH] crash: arm32: a better way to identify LPAE enabled kernel

Thanks to Dave's suggest, I impove the way to identify
LPAE enabled kernel for arm platform, for compatibility with
some old kernel.

If a vmcore santisfy one of the following conditions, It must
be generated by a LPAE enabled kernel.

(1) it has CONFIG_ARM_LPAE=y vmcore_info
(2) swapper_pg_dir and its next symbol value differ by 0x5000

Signed-off-by: Liu Hua <sdu.liu <at> huawei.com>
---
 arm.c     | 11 ++++++++++-
 symbols.c | 10 ++++++++++
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/arm.c b/arm.c
index cb7d841..76ba699 100644
--- a/arm.c
+++ b/arm.c
 <at>  <at>  -190,6 +190,8  <at>  <at>  void
 arm_init(int when)
 {
 	ulong vaddr;
+	char *string;
+	ulong difference;

 #if defined(__i386__) || defined(__x86_64__)
 	if (ACTIVE())
 <at>  <at>  -229,8 +231,15  <at>  <at>  arm_init(int when)
(Continue reading)

Michael Holzheu | 12 Sep 16:42 2014
Picon

[PATCH] crash/s390x: Fix CPU timer and clock comparator output for bt -a

Hello Dave,

The output of CPU timer and clock comparator has always been incorrect
because:

 - We added S390X_WORD_SIZE (8) instead of 4 to get the second word
 - We did not left shift the clock comparator by 8

So fix this by getting the complete 64 bit values and by shifting the
clock comparator correctly.

Signed-off-by: Michael Holzheu <holzheu <at> linux.vnet.ibm.com>
---
 s390x.c |   14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

--- a/s390x.c
+++ b/s390x.c
 <at>  <at>  -1343,14 +1343,16  <at>  <at>  s390x_print_lowcore(char* lc, struct bt_
 	fprintf(fp,"  -prefix   : %#010lx\n", tmp[0]);
 	
 	ptr = lc + MEMBER_OFFSET(lc_struct, "cpu_timer_save_area");
-	tmp[0]=UINT(ptr);
-	tmp[1]=UINT(ptr + S390X_WORD_SIZE);
-	fprintf(fp,"  -cpu timer: %#010lx %#010lx\n", tmp[0],tmp[1]);
+	tmp[0]=ULONG(ptr);
+	fprintf(fp,"  -cpu timer: %#018lx\n", tmp[0]);

 	ptr = lc + MEMBER_OFFSET(lc_struct, "clock_comp_save_area");
-	tmp[0]=UINT(ptr);
(Continue reading)

Dave Anderson | 11 Sep 21:12 2014
Picon

crash 7.0.8 is available


Download from: http://people.redhat.com/anderson
                 or
               https://github.com/crash-utility/crash/releases

The master branch serves as a development branch that will contain all 
patches that are queued for the next release:

  $ git clone git://github.com/crash-utility/crash.git

Changelog:

 - Fix for the handling of 32-bit ELF xendump dumpfiles if the guest 
   was configured with more than 4GB of memory.  Without the patch, the
   crash session may fail during initialization with the error message 
   "crash: vmlinux and <dumpfile> do not match!".
   (dslutz <at> verizon.com)

 - Fix for file-handling errors when a compressed vmlinux.debug file 
   is followed by a vmlinux file on the crash command line.  When the 
   crash session ends, two errors will occur:
     (1) the vmlinux file will be deleted  
     (2) the temporary uncompressed version of the vmlinux.debug file
         will remain in /var/tmp
   This problem also occurs in the highly unlikely case where a 
   compressed vmlinux file is followed by a vmlinux.debug file on the
   command line, and the uncompressed temporary version of the vmlinux
   file is larger than the vmlinux.debug file.  In that case:
     (1) the vmlinux.debug file will be deleted
     (2) the temporary uncompressed version of the vmlinux file
(Continue reading)


Gmane