how to use crash utility to parse the binary memory dump
by buyitian
Hi：
my HW is like this:
DDR starts from physical address 0x80000000, size is 1GB.
after crash, there are two dump files: ddr1.bin and ddr2.bin.
each binary file is 512MB.
the vmlinux is on my hand.
how can i use crash utility to parse these two binary?
thanks.
Best Regards
10 years, 4 months
[PATCH] crash-gcore-command extension module: fix NT_PRSTATUS dump bug in compat mode
by Wei Shu
Hi Dave and Daisuke,
during enabling compat mode in ARM64 architecture, I found a bug in compat_fill_prstatus_note
the regset data only have pr_reg, but in compat_fill_prstatus_note, it is treated as compat_elf_prstatus
I made a patch and verified on ARM64 compat mode, please help review the patch, thanks
Best Regards,
Wei Shu
10 years, 4 months
display slabs in cpu partial list for slub
by qiaonuohan
Hello Dave,
Please check this patch. It is used for slub to display slabs in
kmem_cache_cpu.partial list.
I can only get it test on RHEL7.0GA right now. Would you please
help get some other test? Thanks a lot.
--
Regards
Qiao Nuohan
10 years, 4 months
Negative NR_WRITEBACK counter
by Buland Kumar Singh
Hello Everyone,
I am analysing a kernel crash dump (vmcore) captured from RHEL-5
kernel version (2.6.18-371.4.1.el5) and found that the value of
"NR_WRITEBACK" counter is negative (-126).
$ rpm -q crash
crash-7.0.6-2.el6.x86_64
crash> sys | grep -e RELEASE -e MACHINE -e MEMORY
RELEASE: 2.6.18-371.4.1.el5
MACHINE: x86_64 (3000 Mhz)
MEMORY: 31.5 GB
crash> kmem -z | grep -e ZONE -e NR_WRITEBACK
NODE: 0 ZONE: 0 ADDR: ffff810000032000 NAME: "DMA"
NR_WRITEBACK: 0
NODE: 0 ZONE: 1 ADDR: ffff810000032b00 NAME: "DMA32"
NR_WRITEBACK: 0
NODE: 0 ZONE: 2 ADDR: ffff810000033600 NAME: "Normal"
NR_WRITEBACK: -126 <<<<
NODE: 0 ZONE: 3 ADDR: ffff810000034100 NAME: "HighMem"
crash> kmem -V | grep -e NR_WRITEBACK
NR_WRITEBACK: -126 <<<<
crash> vm_stat
vm_stat = $1 =
{{
counter = 1106459
}, {
counter = 2940354
}, {
counter = 6341366
}, {
counter = 301750
}, {
counter = 245858
}, {
counter = 438
}, {
counter = -126 // NR_WRITEBACK <<<<
}, {
counter = 0
}, {
counter = 0
}, {
counter = 19687071384
}, {
counter = 0
}, {
counter = 0
}, {
counter = 29247123
}, {
counter = 19687071384
}, {
counter = 0
}}
As we're running a 64 bit kernel and the counters are signed long,
so this is very unlikely to be a counter overflow. I need pointers
and suggestions to determine the *cause* of negative counter from
vmcore.
Additional Information:
$ git show ce866b34ae1b7f1ce60234cf65855886ac7e7d30
[..]
diff --git a/drivers/base/node.c b/drivers/base/node.c
index 6fed520..a7b3dcb 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -49,9 +49,6 @@ static ssize_t node_read_meminfo(struct sys_device * dev,
char * buf)
get_page_state_node(&ps, nid);
__get_zone_counts(&active, &inactive, &free, NODE_DATA(nid));
- /* Check for negative values in these approximate counters */
- if ((long)ps.nr_writeback < 0)
- ps.nr_writeback = 0;
n = sprintf(buf, "\n"
"Node %d MemTotal: %8lu kB\n"
[..]
Thank you !
--
BKS
10 years, 4 months
Re: [Crash-utility] crash-utility@redhat.com, anderson@redhat.com
by Karlsson, Jan
Hi
I have not seen anything like this before, so I cannot really help you with the problem. You should however be aware the in this case Crash is built as a 32-bit executable and must be built in that way to work properly. So you should look for missing 32-bit libraries.
Jan
Jan Karlsson
Senior Software Engineer
System Assurance
Sony Mobile Communications
Tel: +46 703 062 174
jan.karlsson(a)sonymobile.com
sonymobile.com
-----Original Message-----
From: Yu Chen [mailto:chenyu105@gmail.com]
Sent: den 4 juli 2014 06:40
To: ext-mika.1.westerberg(a)nokia.com; Karlsson, Jan; Fänge, Thomas
Subject: crash-utility(a)redhat.com, anderson(a)redhat.com
Hi all!
I am trying to compile crash-7.0.7 on x86_64 host for arm.
(x86 binary to analyze ARM dumpfiles)
Here's the failure information:
-bash-4.1$ make target=arm
TARGET: ARM
CRASH: 7.0.7
GDB: 7.6
...
checking for gcc... gcc
checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for objcopy... objcopy checking for objdump... objdump checking for readelf... readelf checking for arm-elf-linux-cc... no checking for arm-elf-linux-gcc... no checking for arm-elf-linux-c++... no checking for arm-elf-linux-g++... no checking for arm-elf-linux-cxx... no checking for arm-elf-linux-gxx... no checking for arm-elf-linux-gcc... no checking for arm-elf-linux-gcj... no
...
checking for library containing waddstr... no
configure: WARNING: no enhanced curses library found; disabling TUI checking for library containing tgetent... no
configure: error: no termcap library found
make[3]: *** [configure-gdb] Error 1
make[2]: *** [all] Error 2
crash build failed
make[1]: *** [gdb_merge] Error 1
make: *** [all] Error 2
I thought the reason for above error message was due to lack of termcap library. However, the termcap library could be found on my host machine:
-bash-4.1$ find . -name "*termcap*"
./libtermcap.so.2
./libtermcap.so.2.0.8
-bash-4.1$ pwd
/lib64
-bash-4.1$ uname -a
Linux localhost.localdomain 2.6.32-220.el6.x86_64 #1 SMP Mon Sep 3
07:34:44 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
After I copyed x86_64 libtermcap.a into /lib64 ,the error message still exist.
I am confused if crash should be cross compiled in this situation?
Or is there any step I should take before compile crash?
Many thanks !
10 years, 4 months
