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, 10 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, 10 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, 10 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, 11 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, 11 months
