vt->kmem_cache_len_nodes not set
by Michael Holzheu
Hello Dave,
I have a s390x dump of a Linux-3.1 kernel where I get the error message:
crash: zero-size memory allocation! (called from 8009f504)
The error comes from max_cpudata_limit() where GETBUF fails:
/*
* Check the shared list of all the nodes.
*/
start_address = (ulong *)GETBUF(sizeof(ulong) * vt->kmem_cache_len_nodes);
--> vt->kmem_cache_len_nodes = 0
I debugged the problem a bit and found out that the reason is
that crash does not set vt->kmem_cache_len_nodes for that dump.
This attribute seem to be only set in kmem_cache_downsize():
if (buffer_size < SIZE(kmem_cache_s)) {
if (kernel_symbol_exists("nr_node_ids")) {
get_symbol_data("nr_node_ids", sizeof(int),
&nr_node_ids);
vt->kmem_cache_len_nodes = nr_node_ids;
} else {
fprintf(fp, "XXX kernel_symbol_exists(\n");
vt->kmem_cache_len_nodes = 1;
}
In my dump the "if" condition returns false (buffer_size = 768,
SIZE(kmem_cache_s = 624) therefore vt->kmem_cache_len_nodes is
not set. Perhaps the content of "cache_cache" is useful to understand
what is going on:
print cache_cache
$7 = {
batchcount = 27,
limit = 54,
shared = 8,
buffer_size = 768, <<-----
reciprocal_buffer_size = 5592406,
flags = 0,
num = 5,
gfporder = 0,
gfpflags = 0,
colour = 0,
colour_off = 256,
slabp_cache = 0x0,
slab_size = 256,
dflags = 0,
ctor = 0,
name = 0x667b8e "kmem_cache",
next = {
next = 0x93b528,
prev = 0xff04158
},
nodelists = 0x93b538,
array = {0xff23e00, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x
0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
}
Any idea what's wrong here?
Best Regards
Michael
12 years, 10 months
SIAL and bison 2.5
by Dave Anderson
Hi Luc,
I note a new set of bison complaints on a Fedora 16 machine:
# make extensions
gcc -Wall -nostartfiles -shared -rdynamic -o echo.so echo.c -fPIC -DX86_64 -DGDB_7_3_1
gcc -Wall -nostartfiles -shared -rdynamic -o trace.so trace.c -fPIC -DX86_64 -DGDB_7_3_1
gcc -Wall -nostartfiles -shared -rdynamic -o dminfo.so dminfo.c -fPIC -DX86_64 -DGDB_7_3_1
cd libsial && make
bison -psial -v -t -d sial.y
sial.y:107.22: warning: a `;' might be needed at the end of action code
sial.y:107.22: warning: future versions of Bison will not add the `;'
sial.y:107.36: warning: a `;' might be needed at the end of action code
sial.y:107.36: warning: future versions of Bison will not add the `;'
sial.y:111.26: warning: a `;' might be needed at the end of action code
sial.y:111.26: warning: future versions of Bison will not add the `;'
sial.y:111.40: warning: a `;' might be needed at the end of action code
sial.y:111.40: warning: future versions of Bison will not add the `;'
sial.y:424.25: warning: a `;' might be needed at the end of action code
sial.y:424.25: warning: future versions of Bison will not add the `;'
sial.y:424.39: warning: a `;' might be needed at the end of action code
sial.y:424.39: warning: future versions of Bison will not add the `;'
sial.y: conflicts: 252 shift/reduce, 20 reduce/reduce
cc -O3 -g -fPIC -c -o sial_util.o sial_util.c
cc -O3 -g -fPIC -c -o sial_node.o sial_node.c
cc -O3 -g -fPIC -c -o sial_var.o sial_var.c
cc -O3 -g -fPIC -c -o sial_func.o sial_func.c
cc -O3 -g -fPIC -c -o sial_str.o sial_str.c
cc -O3 -g -fPIC -c -o sial_op.o sial_op.c
cc -O3 -g -fPIC -c -o sial_num.o sial_num.c
cc -O3 -g -fPIC -c -o sial_stat.o sial_stat.c
cc -O3 -g -fPIC -c -o sial_builtin.o sial_builtin.c
cc -O3 -g -fPIC -c -o sial_type.o sial_type.c
cc -O3 -g -fPIC -c -o sial_case.o sial_case.c
cc -O3 -g -fPIC -c -o sial_api.o sial_api.c
cc -O3 -g -fPIC -c -o sial_member.o sial_member.c
cc -O3 -g -fPIC -c -o sial_alloc.o sial_alloc.c
cc -O3 -g -fPIC -c -o sial_define.o sial_define.c
cc -O3 -g -fPIC -c -o sial_input.o sial_input.c
cc -O3 -g -fPIC -c -o sial_print.o sial_print.c
bison -psialpp -v -t -d sialpp.y
sialpp.y: conflicts: 23 shift/reduce
cc -O3 -g -fPIC -c sialpp.tab.c
cc -O3 -g -fPIC -c sial.tab.c
flex -L -Psial -t sial.l > lex.sial.c
cc -O3 -g -fPIC -c lex.sial.c
flex -Psialpp -t sialpp.l > lex.sialpp.c
cc -O3 -g -fPIC -c lex.sialpp.c
cc -O3 -g -fPIC -o mkbaseop mkbaseop.c
./mkbaseop > baseops.c
cc -O3 -g -fPIC -c baseops.c
ar ccurl libsial.a sial_util.o sial_node.o sial_var.o sial_func.o sial_str.o sial_op.o sial_num.o sial_stat.o sial_builtin.o sial_type.o sial_case.o sial_api.o sial_member.o sial_alloc.o sial_define.o sial_input.o sial_print.o sialpp.tab.o sial.tab.o lex.sial.o lex.sialpp.o baseops.o
gcc -g -I.. -Ilibsial -I../gdb-7.3.1/bfd -I../gdb-7.3.1/include -I../gdb-7.3.1/gdb -I../gdb-7.3.1/gdb/config -I../gdb-7.3.1/gdb/common -I../gdb-7.3.1 -nostartfiles -shared -rdynamic -o sial.so sial.c -fPIC -DX86_64 -DGDB_7_3_1 -Llibsial -lsial
gcc -Wall -I. -nostartfiles -shared -rdynamic -o snap.so snap.c -fPIC -DX86_64 -DGDB_7_3_1
#
Since the warnings don't show up with bison 2.4.1,
I'm guessing it's something new in version 2.5:
# bison --version
bison (GNU Bison) 2.5
Written by Robert Corbett and Richard Stallman.
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
#
Probably worth cleaning up now rather than later?
Thanks,
Dave
12 years, 10 months
Re: [Crash-utility] [PATCH v3] add option -s and -S for subcommand irq
by Dave Anderson
I have verified and applied the "irq -a" and "irq -s" options
on both IA64 and PPC64.
Both S390 and S390X do not support the "irq" command, so I'll defer
all IRQ-related issues to Michael Holzheu if there's any interest
there.
I tried it on 32-bit PPC, but I don't have an SMP vmcore, so "irq -a"
fails as expected. And the "irq -s" option fails like so:
crash> irq -s
CPU0
irq: cannot determine size of irq_desc_t
crash>
And I note that the basic "irq" command does not work on 32-bit PPC:
crash> irq
irq: invalid structure size: irqdesc
FILE: ppc.c LINE: 1292 FUNCTION: ppc_dump_irq()
[./crash] error trace: 10066230 => 100cb078 => 100e3a68 => 100fc608
100fc608: SIZE_verify+232
100e3a68: ppc_dump_irq+168
100cb078: cmd_irq+1960
10066230: exec_command+960
irq: invalid structure size: irqdesc
FILE: ppc.c LINE: 1292 FUNCTION: ppc_dump_irq()
crash>
So I'll defer all PPC "irq" command support to Suzuki or Toshi.
And lastly, many thanks to Zhang Yanfei for implementing these
two options.
Dave
12 years, 10 months
"zero-size memory allocation!" is back for Linux 3.1
by Bob Montgomery
In include/linux/slab_def.h circa linux 3.0, this def for field nodelists:
struct kmem_cache {
/* 1) per-cpu data, touched during every alloc/free */
struct array_cache *array[NR_CPUS];
...
struct kmem_list3 *nodelists[MAX_NUMNODES];
/*
* Do not add fields after nodelists[]
*/
};
Became this in 3.1:
struct kmem_cache {
...
/* 6) per-cpu/per-node data, touched during every alloc/free */
/*
* We put array[] at the end of kmem_cache, because we want to
size
* this array to nr_cpu_ids slots instead of NR_CPUS
* (see kmem_cache_init())
* We still use [NR_CPUS] and not [1] or [0] because cache_cache
* is statically defined, so we reserve the max number of cpus.
*/
struct kmem_list3 **nodelists;
struct array_cache *array[NR_CPUS];
/*
* Do not add fields after array[]
*/
};
Which causes this in crash/memory.c:vm_init()
ARRAY_LENGTH_INIT(vt->kmem_cache_len_nodes, NULL,
"kmem_cache.nodelists", NULL, 0);
to set vt->kmem_cache_len_nodes to 0, and leads to the initialization
failure when max_cpudata_limit calls getbuf with a size of 0.
Got a fix in the works yet?
Thanks,
Bob Montgomery
12 years, 10 months
[PATCH v1 0/2] Compressed KDUMP core analysis support for PPC32
by Suzuki K. Poulose
These patches are based on crash-6.0.2 + PPC32 KDUMP support patches.
---
Suzuki K. Poulose (2):
[ppc] Backtrace support for active tasks
[ppc] Compressed KDUMP support for PPC32
diskdump.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
netdump.c | 2 ++
ppc.c | 13 +++++++++++--
3 files changed, 71 insertions(+), 3 deletions(-)
--
Suzuki K. Poulose
12 years, 10 months
[PATCH] ARM: don't read __per_cpu_offset table again
by Per Fransson
Hi Dave/Mika/Jan and other Crash users,
Here's some code that can be thrown away. The __per_cpu_offset table is read in
arm.c:arm_get_crash_notes() even though it's already available.
Regards,
Per
diff --git a/arm.c b/arm.c
index 5eb5649..36a26cc 100644
--- a/arm.c
+++ b/arm.c
@@ -497,8 +497,6 @@ arm_get_crash_notes(void)
ulong offset;
char *buf, *p;
ulong *notes_ptrs;
- ulong per_cpu_offsets_addr;
- ulong *per_cpu_offsets;
ulong i;
if (!symbol_exists("crash_notes"))
@@ -521,24 +519,9 @@ arm_get_crash_notes(void)
}
if (symbol_exists("__per_cpu_offset")) {
-
- /* Get the __per_cpu_offset array */
- per_cpu_offsets_addr = symbol_value("__per_cpu_offset");
-
- per_cpu_offsets = (ulong *)GETBUF(kt->cpus*sizeof(*per_cpu_offsets));
-
- if (!readmem(per_cpu_offsets_addr, KVADDR, per_cpu_offsets,
- kt->cpus*sizeof(*per_cpu_offsets), "per_cpu_offsets",
- RETURN_ON_ERROR)) {
- error(WARNING, "cannot read per_cpu_offsets\n");
- FREEBUF(per_cpu_offsets);
- return FALSE;
- }
-
/* Add __per_cpu_offset for each cpu to form the pointer to the notes */
for (i = 0; i<kt->cpus; i++)
- notes_ptrs[i] = notes_ptrs[kt->cpus-1] + per_cpu_offsets[i];
- FREEBUF(per_cpu_offsets);
+ notes_ptrs[i] = notes_ptrs[kt->cpus-1] + kt->__per_cpu_offset[i];
}
buf = GETBUF(SIZE(note_buf));
12 years, 10 months
[PATCH] ARM: fix segfault in page table read
by Rabin Vincent
I have an ARM crash dump where the page tables have been corrupted.
crash segfaults while reading it because of a stack overflow due to recursion
in the page table read core:
readmem: e2efcde0, KVADDR, "module unwind table", 24, (ROE), 8600bc0>
addr: e2efcde0 paddr: 22efcde0 cnt: 24
<readmem: bf006550, KVADDR, "module unwind index table", 8, (ROE), 9ccab28>
<readmem: c0004000, KVADDR, "pgd page", 16384, (FOE), 91c18e8>
addr: c0004000 paddr: 4000 cnt: 4096
addr: c0005000 paddr: 5000 cnt: 4096
addr: c0006000 paddr: 6000 cnt: 4096
addr: c0007000 paddr: 7000 cnt: 4096
<readmem: ed2d3000, KVADDR, "page table", 4096, (FOE), 91c58f0>
<readmem: ed2d3000, KVADDR, "page table", 4096, (FOE), 91c58f0>
<readmem: ed2d3000, KVADDR, "page table", 4096, (FOE), 91c58f0>
<readmem: ed2d3000, KVADDR, "page table", 4096, (FOE), 91c58f0>
<readmem: ed2d3000, KVADDR, "page table", 4096, (FOE), 91c58f0>
<readmem: ed2d3000, KVADDR, "page table", 4096, (FOE), 91c58f0>
etc till segfault
The problem appears to be that the ARM code is attempting to PTOV() the
physical address found in the page table and readmem() it as a KVADDR instead
of just directly reading it as a PHYSADDR.
Patch below.
Rabin
diff --git a/arm.c b/arm.c
index 5eb5649..4ca2fcd 100644
--- a/arm.c
+++ b/arm.c
@@ -979,9 +979,9 @@ arm_vtop(ulong vaddr, ulong *pgd, physaddr_t *paddr, int verbose)
/*
* pte_offset_map(pmd, vaddr)
*/
- page_table = (ulong *)PTOV(pmd_page_addr(pmd_pte)) + PTE_OFFSET(vaddr);
+ page_table = pmd_page_addr(pmd_pte) + PTE_OFFSET(vaddr);
- FILL_PTBL(PAGEBASE(page_table), KVADDR, PAGESIZE());
+ FILL_PTBL(PAGEBASE(page_table), PHYSADDR, PAGESIZE());
pte = ULONG(machdep->ptbl + PAGEOFFSET(page_table));
if (verbose) {
12 years, 10 months
[PATCH] improve the performance of kmem -p
by qiaonuohan
Hello Dave,
While I am using 'kmem -p', I feel it is too slow, especially with a big
memory. So I modify something to improve the performance.
The patch is based on crash 6.0.2, and it has been tested on
RHEL6.2_x86_64, RHEL6.2_i386, RHEL5.8_x86_64 and RHEL5.8_i386.
Thanks,
Qiao Nuohan
12 years, 10 months
[PATCH] [ppc] Restore the complete functionality of ppc_get_frame
by Suzuki K. Poulose
In one of my patches to add support for PPC32, I removed some
code to find the stack pointer value for an active task in non-kdump
case.
This patch restores the same.
Signed-off-by : Suzuki K. Poulose <suzuki(a)in.ibm.com>
---
ppc.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/ppc.c b/ppc.c
index 6a1db2a..89b409b 100755
--- a/ppc.c
+++ b/ppc.c
@@ -1202,6 +1202,9 @@ ppc_dumpfile_stack_frame(struct bt_info *bt, ulong *getpc, ulong *getsp)
else
*getpc = (sp->value - 4);
}
+
+ if (getsp)
+ get_ppc_frame(bt, NULL, getsp);
}
/*
12 years, 10 months