[PATCH] Add -r option to timer
by qiaonuohan
Hello Dave,
The attached patches are used to display hrtimers.
To see detailed information, can refer to the patches.
--
--
Regards
Qiao Nuohan
11 years, 8 months
Re: [Crash-utility] SLES 9 Dump
by Dave Anderson
> I tried again using kerntypes and it failed with a different error.
>
> # /RedHat/crash-6.1.0-X86/crash vmlinux-2.6.5-7.321-bigsmp dump-pts02504
> Kerntypes-2.6.5-7.321-bigsmp
> ...
> crash: cannot resolve "_stext"
>
>
> Eugene
Try putting *both* the System.map file (required for _stext) and
the Kerntypes file (required for debuginfo data) on the command
line.
If there is really no "_stext" symbol in the System.map file, then
you're screwed. Although, I would have presumed that it could get
the _stext symbol from the stripped vmlinux file. If you do
"nm -Bn vmlinux", does it show an _stext symbol?
Dave
Dave
>
> -----Original Message-----
> From: Ku, Eugene
> Sent: Tuesday, March 05, 2013 6:04 PM
> To: Dave Anderson
> Cc: Ku, Eugene
> Subject: RE: [Crash-utility] SLES 9 Dump
>
> Dave,
>
> I rebuilt 6.1.0 crash as you had suggested.
>
> # file /RedHat/crash-6.1.0-X86/crash
> /RedHat/crash-6.1.0-X86/crash: ELF 32-bit LSB executable, Intel 80386,
> version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared
> libs), for GNU/Linux 2.6.9, not stripped
>
> I then ran it against the dump. I got the following error messages.
>
> # /RedHat/crash-6.1.0-X86/crash vmlinux-2.6.5-7.321-bigsmp dump-pts02504
> ...
> crash: vmlinux-2.6.5-7.321-bigsmp: no debugging data available
>
>
> I tried again with additional System.map but got the same error.
>
> # /RedHat/crash-6.1.0-X86/crash vmlinux-2.6.5-7.321-bigsmp dump-pts02504
> System.map-2.6.5-7.321-bigsmp
> ...
> crash: vmlinux-2.6.5-7.321-bigsmp: no debugging data available
>
>
> Eugene
>
11 years, 8 months
[PATCH] cgget: add support to kernel 3.7 and 3.8
by Zhang Xiaohe
Hello Dave,
There are some changes in cgroups of kernel 3.7 and 3.8, so I
made this patch to support them.
The main changes are in subsystem memory and devices. Here is
this patch.
Thanks,
Zhang Xiaohe
11 years, 8 months
printing the linked structures
by Yogesh Blore
Hi,
Here is a scenario in which three structures (of type 'struct
anon_vma_chain') are linked with the element 'struct list_head
same_anon_vma'. Please check the following structure.
crash> struct anon_vma_chain -o
struct anon_vma_chain {
[0] struct vm_area_struct *vma;
[4] struct anon_vma *anon_vma;
[8] struct list_head same_vma;
[16] struct list_head same_anon_vma;
}
SIZE: 24
The following are the three structures that are linked:
crash> anon_vma_chain -l anon_vma_chain.same_anon_vma 0xe4315510
struct anon_vma_chain {
vma = 0xe43144f0,
anon_vma = 0xe49e2d98,
same_vma = {
next = 0xe4314528,
prev = 0xe43154f0
},
same_anon_vma = {
next = 0xe4fe4f60,
prev = 0xe4e833a8
}
}
same_anon_vma.next=0xe4fe4f60 from the previous structure, is used to
extract the next structure.
crash> anon_vma_chain -l anon_vma_chain.same_anon_vma 0xe4fe4f60
struct anon_vma_chain {
vma = 0xe4fe85f8,
anon_vma = 0xe49e2d98,
same_vma = {
next = 0xe4fe8630,
prev = 0xe4fe4f40
},
same_anon_vma = {
next = 0xe45a1df8,
prev = 0xe4315510
}
}
same_anon_vma.next=0xe45a1df8 from the previous structure, is used to
extract the next structure.
crash> anon_vma_chain -l anon_vma_chain.same_anon_vma 0xe45a1df8
struct anon_vma_chain {
vma = 0xe45a73e8,
anon_vma = 0xe49e2d98,
same_vma = {
next = 0xe45a7420,
prev = 0xe45a1dd8
},
same_anon_vma = {
next = 0xe461fb40,
prev = 0xe4fe4f60
}
}
Is there something like "anon_vma_chain -l
anon_vma_chain.same_anon_vma 0xe4315510 -c 3" to get three structures
that are linked using anon_vma_chain.same_anon_vma. Actually
"anon_vma_chain -l anon_vma_chain.same_anon_vma 0xe4315510 -c 3"
doesn't work in this case. It seems like -c option works only in case
of array of structures. Could someone help me to print the above three
structures with a single command?
Thanks,
Yogesh
11 years, 8 months
fix gdb_get_datatype cannot handle integer type
by Lei Wen
Hi Dave,
Current when pass integer type to gdb_get_datatype in crash, it would return
req->typecode=0 and req->length=0.
As it only allow TYPE_CODE_ENUM to be passed. here is a patch for fixing it.
Do you think it could be merged?
+--- gdb-7.3.1/gdb/symtab.c
++++ gdb-7.3.1/gdb/symtab.c
+@@ -5064,14 +5064,13 @@ gdb_get_datatype(struct gnu_request *req)
+ if (gdb_CRASHDEBUG(2))
+ console("expr->elts[0].opcode: OP_VAR_VALUE\n");
+ type = expr->elts[2].symbol->type;
+- if (TYPE_CODE(type) == TYPE_CODE_ENUM) {
+- req->typecode = TYPE_CODE(type);
+- req->value = SYMBOL_VALUE(expr->elts[2].symbol);
+- req->tagname = TYPE_TAG_NAME(type);
+- if (!req->tagname) {
+- val = evaluate_type(expr);
+- eval_enum(value_type(val), req);
+- }
++ req->typecode = TYPE_CODE(type);
++ req->length = TYPE_LENGTH(type);
++ req->value = SYMBOL_VALUE(expr->elts[2].symbol);
++ req->tagname = TYPE_TAG_NAME(type);
++ if (!req->tagname) {
++ val = evaluate_type(expr);
++ eval_enum(value_type(val), req);
+ }
+ break;
+
Thanks,
Lei
11 years, 8 months
Re: [Crash-utility] dis command not correct in crash [ARM]
by Lei Wen
Hi Mike,
On Tue, Mar 5, 2013 at 3:49 AM, Mika Westerberg <mika.westerberg(a)iki.fi>wrote:
> On Mon, Mar 04, 2013 at 10:20:42AM +0800, Lei Wen wrote:
> > I met "dis" command not correct issue when use the crash, any idea?
> > For built-in "dis" command in crash:
> > crash> dis task_rq_lock
> > 0xc015a2d8 <task_rq_lock>: rscsgt r0, sp, r3, lsl #14
> > 0xc015a2dc <task_rq_lock+4>: mrcgt 8, 7, r0, cr2, cr13, {5}
> > 0xc015a2e0 <task_rq_lock+8>: mcrvc 8, 4, r3, cr13, cr3, {6}
> > 0xc015a2e4 <task_rq_lock+12>: lslsvc r3, r10, r8
> > 0xc015a2e8 <task_rq_lock+16>: bl 0xc049fe34
> > <__ip_route_output_key+220>
>
> Looks weird.
>
> What is the kernel version? Does the 'dis' command work for other
> functions?
>
Seems other functions is not working either...
Is the page table being corrupted? But I still could parse out the dump
image and check the kernel dmesg for it, which is also weird.
crash> dis sched_rt_handler
0xc0160ed8 <sched_rt_handler>: cdppl 13, 5, cr2, cr6, cr13, {4}
0xc0160edc <sched_rt_handler+4>: stcle 9, cr7, [r7], #132 ;
0x84
0xc0160ee0 <sched_rt_handler+8>: ; <UNDEFINED>
instruction: 0x167256bb
(gdb) disas sched_rt_handler
Dump of assembler code for function sched_rt_handler:
0xc0160ed8 <+0>: push {r4, r5, r6, r7, r8, r9, r10, r11, lr}
0xc0160edc <+4>: add r11, sp, #32
0xc0160ee0 <+8>: ldr r4, [pc, #384] ; 0xc0161068
<sched_rt_handler+400>
Thanks,
Lei
11 years, 8 months
Re: [Crash-utility] Question for ARM developers/users w/respect to makedumpfile [PROBLEM SOLVED]
by Dave Anderson
With respect to this long-running thread:
[Crash-utility] Question for ARM developers/users w/respect to makedumpfile
https://www.redhat.com/archives/crash-utility/2013-January/msg00049.html
and the kludge/patch that went into crash-6.1.3:
- Workaround for the "crash --osrelease dumpfile" option to be able
to work with malformed ARM compressed kdump headers. ARM compressed
kdumps that indicate header version 3 may contain a malformed
kdump_sub_header structure with offset_vmcoreinfo and size_vmcoreinfo
fields offset by 4 bytes, and the actual vmcoreinfo data is not
preceded by its ELF note header and its "VMCOREINFO" string. This
workaround finds the vmcoreinfo data and patches the stored header's
offset_vmcoreinfo and size_vmcoreinfo values. Without the patch, the
"--osrelease dumpfile" command line option fails with the message
"crash: compressed kdump: cannot lseek dump vmcoreinfo", followed by
"unknown".
(anderson(a)redhat.com)
Luc Chouinard has come to the rescue and figured out what was going on.
It is not a matter of a "malformed" ARM compressed kdump header, but rather
a result of using a 32-bit x86 crash binary created with "make target=ARM"
to analyze ARM compressed kdumps.
The ARM guys on the list can confirm this, but Luc debugged this issue
with a natively-built crash utility, and determined:
Seems like the off_t members of the kdump_sub_header struct are being
aligned on 8 byte boundaries. Which would explain the problem you are
pointing out. This can be a normal compiler behavior for the arm processor,
which will generate exceptions for unaligned memory accesses. This is
something we had to chase down and fix for some of our cross platform
code base (i386 and arm). The Arm experts may have to confirm, but I'd
think that all 'long long' members of structs may cause problem when
cross interpreted by a ARM crash.
Now AFAICT, I believe that the only "cross interpreted" items that would
come into play would be the kdump_sub_header:
struct kdump_sub_header {
unsigned long phys_base;
int dump_level; /* header_version 1 and later */
int split; /* header_version 2 and later */
unsigned long start_pfn; /* header_version 2 and later */
unsigned long end_pfn; /* header_version 2 and later */
off_t offset_vmcoreinfo; /* header_version 3 and later */
unsigned long size_vmcoreinfo; /* header_version 3 and later */
off_t offset_note; /* header_version 4 and later */
unsigned long size_note; /* header_version 4 and later */
off_t offset_eraseinfo; /* header_version 5 and later */
unsigned long size_eraseinfo; /* header_version 5 and later */
};
The header is originally created on the crashing ARM host, and written
by an ARM makedumpfile binary into the dumpfile header. But when crash
is build on an x86/x86_64 host with "make target=ARM", but resultant
binary is a 32-bit x86 binary:
$ make target=ARM
...
$ file crash
crash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x0459d34779357928839cd4d05f04517a441dc555, not stripped
And when compiled as an x86 binary, the structure's offsets would be:
struct kdump_sub_header {
[0] unsigned long phys_base;
[4] int dump_level; /* header_version 1 and later */
[8] int split; /* header_version 2 and later */
[12] unsigned long start_pfn; /* header_version 2 and later */
[16] unsigned long end_pfn; /* header_version 2 and later */
[20] off_t offset_vmcoreinfo; /* header_version 3 and later */
[28] unsigned long size_vmcoreinfo; /* header_version 3 and later */
[32] off_t offset_note; /* header_version 4 and later */
[40] unsigned long size_note; /* header_version 4 and later */
[44] off_t offset_eraseinfo; /* header_version 5 and later */
[52] unsigned long size_eraseinfo; /* header_version 5 and later */
};
But when compiled on an ARM processor, each 64-bit "off_t" would be pushed
up to an 8-byte boundary:
struct kdump_sub_header {
[0] unsigned long phys_base;
[4] int dump_level; /* header_version 1 and later */
[8] int split; /* header_version 2 and later */
[12] unsigned long start_pfn; /* header_version 2 and later */
[16] unsigned long end_pfn; /* header_version 2 and later */
[24] off_t offset_vmcoreinfo; /* header_version 3 and later */
[32] unsigned long size_vmcoreinfo; /* header_version 3 and later */
[40] off_t offset_note; /* header_version 4 and later */
[48] unsigned long size_note; /* header_version 4 and later */
[56] off_t offset_eraseinfo; /* header_version 5 and later */
[62] unsigned long size_eraseinfo; /* header_version 5 and later */
};
So the "kludge" for "crash --osrelease" and "crash --log" will have
to continue, but only if the crash binary was built with "make target=ARM".
Again, many thanks to Luc for tracking this issue down.
Dave
11 years, 8 months
dis command not correct in crash
by Lei Wen
Hi,
I met "dis" command not correct issue when use the crash, any idea?
For built-in "dis" command in crash:
crash> dis task_rq_lock
0xc015a2d8 <task_rq_lock>: rscsgt r0, sp, r3, lsl #14
0xc015a2dc <task_rq_lock+4>: mrcgt 8, 7, r0, cr2, cr13, {5}
0xc015a2e0 <task_rq_lock+8>: mcrvc 8, 4, r3, cr13, cr3, {6}
0xc015a2e4 <task_rq_lock+12>: lslsvc r3, r10, r8
0xc015a2e8 <task_rq_lock+16>: bl 0xc049fe34
<__ip_route_output_key+220>
But if I use arm-none-linux-gnueabi-gdb to load the vmlinux and do the
disassemble job, I would see:
(gdb) disas task_rq_lock
Dump of assembler code for function task_rq_lock:
0xc015a2d8 <+0>: push {r4, r5, r6, r7, r8, r10, r11, lr}
0xc015a2dc <+4>: add r7, r0, #620 ; 0x26c
0xc015a2e0 <+8>: ldr r6, [pc, #100] ; 0xc015a34c
<task_rq_lock+116>
0xc015a2e4 <+12>: add r11, sp, #28
0xc015a2e8 <+16>: mov r5, r0
Thanks,
Lei
11 years, 8 months
Any method to extract system holding lock, like spinlock/mutex?
by Lei Wen
Hi list,
Anyone has done such kind of job before?
I just read Documentation/mutex-design.txt from kernel code, it claims:
* - list of all locks held in the system, printout of them
I think kernel could do this kind of thing, then crash also could do
it, am i right?
Thanks,
Lei
11 years, 8 months
