Breakpoints in crash
by Dheeraj Sangamkar
Hi,
I use crash regularly(everyday) and its fabulous.
I dont know if there is a way to specify break points in kernel code
using crash during live debugging.
There are kernel debuggers from some OSes where this is possible. I am
wondering if there is a plan to include breakpointing functionality in
crash sometime in the future.
Dheeraj
16 years, 9 months
Re: [Crash-utility] memory requirement for crash tool
by Dave Anderson
----- "Dharmosoth Seetharam" <seetharam_21(a)yahoo.com> wrote:
> Hi,
>
> I have a question regarding the memory requirement for crash tool
> to start analyzing or extract few command's results from the
> kernel core of size more than 50G.
>
> my system details
> arch : x86_64
> memory: 128M
>
> But I want to analyze kernel core of size 50G+.
>
> Now I am unable to do that.
>
> Can you please tell me how much memory it needs to get atleast "bt"
> information?
No I can't -- I have no idea. 128MB is pretty pitiful. But with
enough swap I would guess that the crash session will come up eventually?
You might try adding "--active" to the command line, which will
only gather task data for the active task on each cpu.
Dave
16 years, 10 months
[PATCH] Add i386 linux-2.6.30 support.
by Ken'ichi Ohmichi
Hi,
The latest crash (version 4.0-8.11) fails on i386 linux-2.6.30:
# crash -s vmlinux vmcore
crash: cannot resolve: "hardirq_ctx"
#
The reason is that both hardirq_ctx and softirq_ctx have been defined
by DEFINE_PER_CPU() since linux-2.6.30. This change is the following:
--- a/arch/x86/kernel/irq_32.c
+++ b/arch/x86/kernel/irq_32.c
[snip]
-static union irq_ctx *hardirq_ctx[NR_CPUS] __read_mostly;
-static union irq_ctx *softirq_ctx[NR_CPUS] __read_mostly;
+static DEFINE_PER_CPU(union irq_ctx *, hardirq_ctx);
+static DEFINE_PER_CPU(union irq_ctx *, softirq_ctx);
By this patch, the crash utility can read the dumpfile of i386 linux-2.6.30.
Thanks
Ken'ichi Ohmichi
Signed-off-by: Ken'ichi Ohmichi <oomichi(a)mxs.nes.nec.co.jp>
---
--- a/task.c 2009-07-01 00:31:20.000000000 +0900
+++ b/task.c 2009-07-06 15:37:35.000000000 +0900
@@ -488,10 +488,27 @@ irqstacks_init(void)
thread_info_buf = GETBUF(SIZE(irq_ctx));
- i = get_array_length("hardirq_ctx", NULL, 0);
- get_symbol_data("hardirq_ctx",
- sizeof(long)*(i <= NR_CPUS ? i : NR_CPUS),
- &tt->hardirq_ctx[0]);
+ if (symbol_exists("hardirq_ctx")) {
+ i = get_array_length("hardirq_ctx", NULL, 0);
+ get_symbol_data("hardirq_ctx",
+ sizeof(long)*(i <= NR_CPUS ? i : NR_CPUS),
+ &tt->hardirq_ctx[0]);
+ } else if (symbol_exists("per_cpu__hardirq_ctx")) {
+ if ((kt->flags & SMP) && (kt->flags & PER_CPU_OFF)) {
+ for (i = 0; i < NR_CPUS; i++) {
+ if (!kt->__per_cpu_offset[i])
+ continue;
+ tt->hardirq_ctx[i] =
+ symbol_value("per_cpu__hardirq_ctx") +
+ kt->__per_cpu_offset[i];
+ }
+ } else {
+ tt->hardirq_ctx[0] =
+ symbol_value("per_cpu__hardirq_ctx");
+ }
+ } else {
+ error(FATAL, "cannot get hardirq_ctx.");
+ }
for (i = 0; i < NR_CPUS; i++) {
if (!(tt->hardirq_ctx[i]))
@@ -509,10 +526,27 @@ irqstacks_init(void)
ULONG(thread_info_buf+OFFSET(thread_info_task));
}
- i = get_array_length("softirq_ctx", NULL, 0);
- get_symbol_data("softirq_ctx",
- sizeof(long)*(i <= NR_CPUS ? i : NR_CPUS),
- &tt->softirq_ctx[0]);
+ if (symbol_exists("softirq_ctx")) {
+ i = get_array_length("softirq_ctx", NULL, 0);
+ get_symbol_data("softirq_ctx",
+ sizeof(long)*(i <= NR_CPUS ? i : NR_CPUS),
+ &tt->softirq_ctx[0]);
+ } else if (symbol_exists("per_cpu__softirq_ctx")) {
+ if ((kt->flags & SMP) && (kt->flags & PER_CPU_OFF)) {
+ for (i = 0; i < NR_CPUS; i++) {
+ if (!kt->__per_cpu_offset[i])
+ continue;
+ tt->softirq_ctx[i] =
+ symbol_value("per_cpu__softirq_ctx") +
+ kt->__per_cpu_offset[i];
+ }
+ } else {
+ tt->softirq_ctx[0] =
+ symbol_value("per_cpu__softirq_ctx");
+ }
+ } else {
+ error(FATAL, "cannot get softirq_ctx.");
+ }
for (i = 0; i < NR_CPUS; i++) {
if (!(tt->softirq_ctx[i]))
16 years, 10 months
memory requirement for crash tool
by Dharmosoth Seetharam
Hi,
I have a question regarding the memory requirement for crash tool
to start analyzing or extract few command's results from the
kernel core of size more than 50G.
my system details
arch : x86_64
memory: 128M
But I want to analyze kernel core of size 50G+.
Now I am unable to do that.
Can you please tell me how much memory it needs to get atleast "bt" information?
thanks,
Seetharam
See the Web's breaking stories, chosen by people like you. Check out Yahoo! Buzz. http://in.buzz.yahoo.com/
16 years, 10 months
Crash for SLES 10 hangs.
by Alok Kataria
Hi,
I am trying to debug a bug on SLES 10 kernel using crash.
I have the vmlinux and the vmlinux.debug file for the corresponding
kernel but when I try to start crash it hangs while loading the "slab
cache" data.
****
crash 4.0-7.2.3.el5_3.1
....
....
GNU gdb 6.1
....
This GDB was configured as "x86_64-unknown-linux-gnu"...
please wait... (gathering kmem slab cache data)
****
I then ran crash with "-d 99" debugging support.
Looking at the debug data generated from crash, below is the text which
is repeatedly printed by crash.
------
crash: invalid kernel virtual address: 47 type: "kmem_list3 shared"
<readmem: ffff81000f6266c8, KVADDR, "kmem_list3 shared", 8, (ROE|Q), 7fff89fb1f00>
<readmem: f88948c3c0310006, KVADDR, "shared array_cache limit", 4, (ROE|Q), 7fff89fb1f0c>
crash: invalid kernel virtual address: f88948c3c0310006 type: "shared array_cache limit"
FREEBUF(1)
<readmem: ffff81000f5ab1a0, KVADDR, "kmem_cache_s buffer", 1648, (ROE), a5a480>
<readmem: ffff81000f5ab1a0, KVADDR, "array cache array", 1024, (ROE), 7fff89fb1f10>
GETBUF(512 -> 1)
<readmem: ffff81000f5ab5b0, KVADDR, "array nodelist array", 512, (ROE), a57c80>
<readmem: 47, KVADDR, "kmem_list3 shared", 8, (ROE|Q), 7fff89fb1f00>
crash: invalid kernel virtual address: 47 type: "kmem_list3 shared"
<readmem: 47, KVADDR, "kmem_list3 shared", 8, (ROE|Q), 7fff89fb1f00>
------
Is there a way to tell crash to skip loading slab data ? Or is this a
known bug with crash on sles 10 ?
Please let me know what might be going wrong here.
Thanks,
Alok
16 years, 10 months
Re: [Crash-utility] Crash for SLES 10 hangs.
by Dave Anderson
----- "Alok Kataria" <akataria(a)vmware.com> wrote:
> Hi,
>
> I am trying to debug a bug on SLES 10 kernel using crash.
> I have the vmlinux and the vmlinux.debug file for the corresponding
> kernel but when I try to start crash it hangs while loading the "slab
> cache" data.
> ****
> crash 4.0-7.2.3.el5_3.1
> ....
> ....
> GNU gdb 6.1
> ....
> This GDB was configured as "x86_64-unknown-linux-gnu"...
>
> please wait... (gathering kmem slab cache data)
> ****
>
> I then ran crash with "-d 99" debugging support.
> Looking at the debug data generated from crash, below is the text which
> is repeatedly printed by crash.
>
> ------
> crash: invalid kernel virtual address: 47 type: "kmem_list3 shared"
> <readmem: ffff81000f6266c8, KVADDR, "kmem_list3 shared", 8, (ROE|Q), 7fff89fb1f00>
> <readmem: f88948c3c0310006, KVADDR, "shared array_cache limit", 4, (ROE|Q), 7fff89fb1f0c>
>
> crash: invalid kernel virtual address: f88948c3c0310006 type: "shared array_cache limit"
> FREEBUF(1)
> <readmem: ffff81000f5ab1a0, KVADDR, "kmem_cache_s buffer", 1648, (ROE), a5a480>
> <readmem: ffff81000f5ab1a0, KVADDR, "array cache array", 1024, (ROE), 7fff89fb1f10>
> GETBUF(512 -> 1)
> <readmem: ffff81000f5ab5b0, KVADDR, "array nodelist array", 512, (ROE), a57c80>
> <readmem: 47, KVADDR, "kmem_list3 shared", 8, (ROE|Q), 7fff89fb1f00>
> crash: invalid kernel virtual address: 47 type: "kmem_list3 shared"
> <readmem: 47, KVADDR, "kmem_list3 shared", 8, (ROE|Q), 7fff89fb1f00>
> ------
>
> Is there a way to tell crash to skip loading slab data ? Or is this a
> known bug with crash on sles 10 ?
I can't help you with SLES10 issues, or whether this is a "known bug"
on SLES10, but yes, you can skip the kmem/slab initialization by
putting "--no_kmem_cache" on the command line.
Dave
>
> Please let me know what might be going wrong here.
>
> Thanks,
> Alok
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
16 years, 10 months
