do_radix_tree() function in filesys.c
by Alan Tyson
I notice that there is a function to look at radix trees in filesys.c,
but it's not called by anything in the crash executable from what I can
see. In fact when I wrote a small extension to call it, I see that it
simply doesn't work for several reasons (wrong structures, incorrect
dereferencing of pointers). Attached is a patch which addresses these.
I've tested it on i686, x86_64 and ia64.
If you think that this type of ("utility") code is best left out of
crash, then let's just remove this from the source and not clutter it
with dead code. Personally, I think it's nice to have it there... when
it works.
Regards,
Alan Tyson, HP.
16 years, 10 months
(no subject)
by ramin.shariatian＠ineo.com
Cordialement,
Ramin Shariatian
Tél: 01 57 60 42 40
16 years, 10 months
[PATCH] crash: add pcpu_info support
by Kirill Shileev
Dear all,
We are a team developing the virtualization solution for the Linux
kernel called OpenVZ. Since many people are running kernels patched by
OpenVZ, they can definitely benefit from using the crash utility.
Unfortunately, it's not possible to run crash on top of OpenVZ kernel
without some slight modification of it's code. The reason is the
introduction of some additional data structure to the OpenVZ kernel code
which virtualize runqueues among other things. So the way crash needs to
read struct rq is a bit different from vanilla kernel.
Attached patch adds the needed functionality in a backward-compatible
way. Can you please add it to crash devel tree?
--
Kind regards, Kirill
16 years, 10 months
Re: source line numbers and modules
by Alan Tyson
Dave Anderson wrote:
>Alan Tyson wrote:
>
>
>>Hi,
>>
>>Could someone please explain why we cannot get source line numbers when
>>disassembling modules? Is the problem missing functionality in
>>store_load_module_symbols() or is there an inherent limitation with the
>>gdb linked in with crash in that it cannot accept additional debug_line
>>information for modules? I ask because gdb has this functionality for
>>user-space shared libraries and it seems to work OK. Or am I missing
>>something which is much more complex?
>>
>>Thanks,
>>
>>Alan Tyson,
>>Hewlett-Packard.
>>
>>
>
>What architecture?
>
>
x86_64. Sorry I omitted to mention this.
>I'm presuming that you're running the "mod" command to load
>the debuginfo data from the target module:
>
> << working example on i686 snipped >>
>
>
Yes I am. Indeed it seems that i686 and ia64 work fine. But x86_64 has
the problem.
Thanks,
Alan.
16 years, 10 months
[PATCH] bt for i386 xen-dom0
by Ken'ichi Ohmichi
Hi,
I found the problem that the subcommand "bt" cannot display the stack
of "bash" process on i386 xen-dom0 like the following:
crash> bt
PID: 3954 TASK: e502aaa0 CPU: 0 COMMAND: "bash"
crash>
This problem happens if running "bt" for "swapper" process too:
crash> bt
PID: 0 TASK: c7ca5550 CPU: 1 COMMAND: "swapper"
crash>
The cause is that bt->stackbase is overwritten in get_netdump_regs_x86()
even if the symbol "crash_kexec" is found. This patch fixes the overwritten
problem, and the result is the following:
crash> bt
PID: 3954 TASK: e502aaa0 CPU: 0 COMMAND: "bash"
#0 [eb30ef34] crash_kexec at c043852a
#1 [eb30ef78] write_sysrq_trigger at c0498b75
#2 [eb30ef84] vfs_write at c0467a6d
#3 [eb30ef9c] sys_write at c046805c
#4 [eb30efb8] system_call at c0405348
EAX: ffffffda EBX: 00000001 ECX: b7c5d000 EDX: 00000002
DS: 007b ESI: 00000002 ES: 007b EDI: b7c5d000
SS: 007b ESP: bfdb5eb8 EBP: bfdb5ed8
CS: 0073 EIP: 00295402 ERR: 00000004 EFLAGS: 00000246
crash>
crash> bt
PID: 0 TASK: c7ca5550 CPU: 1 COMMAND: "swapper"
#0 [c10fdfac] xen_idle at c040321a
#1 [c10fdfac] cpu_idle at c0403334
crash>
Thanks
Ken'ichi Ohmichi
Signed-off-by: Ken'ichi Ohmichi <oomichi(a)mxs.nes.nec.co.jp>
---
diff -rpuN crash-4.0-4.13.org/netdump.c crash-4.0-4.13/netdump.c
--- crash-4.0-4.13.org/netdump.c 2008-01-15 19:24:09.000000000 +0900
+++ crash-4.0-4.13/netdump.c 2008-01-15 19:31:52.000000000 +0900
@@ -2039,6 +2039,12 @@ next_sysrq:
return;
}
+ if (halt_eip && halt_esp) {
+ *eip = halt_eip;
+ *esp = halt_esp;
+ return;
+ }
+
if (panic)
return;
@@ -2064,12 +2070,6 @@ next_sysrq:
goto retry;
}
- if (halt_eip && halt_esp) {
- *eip = halt_eip;
- *esp = halt_esp;
- return;
- }
-
if (CRASHDEBUG(1))
error(INFO,
"get_netdump_regs_x86: cannot find anything useful (task: %lx)\n", bt->task);
_
16 years, 10 months
source line numbers and modules
by Alan Tyson
Hi,
Could someone please explain why we cannot get source line numbers when
disassembling modules? Is the problem missing functionality in
store_load_module_symbols() or is there an inherent limitation with the
gdb linked in with crash in that it cannot accept additional debug_line
information for modules? I ask because gdb has this functionality for
user-space shared libraries and it seems to work OK. Or am I missing
something which is much more complex?
Thanks,
Alan Tyson,
Hewlett-Packard.
16 years, 10 months
crash version 4.0-4.13 is available
by Dave Anderson
Changelog:
- If the vmlinux file or dumpfile is a machine type mismatch with
the crash utility binary, or far less likely, a ppc64 or ia64
endian mismatch, the crash session will fail during initialization
with the generic error message, "crash: <filename>: not a
supported file format". To aid the user in understanding what
caused the failure, this patch prepends an additional error
message that clarifies the reason behind the mismatch.
(anderson(a)redhat.com, bwalle(a)suse.de)
- An update for "kmem -V" option, which currently displays the kernel's
"vm_stat" counter values, will now also display the "vm_event_states"
counter values, both of which were introduced in 2.6.18. For 2.6
kernels prior to 2.6.18, the precursor "page_states" counter values
will be displayed. (anderson(a)redhat.com)
- Implemented a new "kmem -z" option to display per-zone memory
statistics. The amount of data displayed is dependent upon the
kernel version. At a minimum, the size, min/low/high and free
page counts are shown. If the zone struct contains nr_active,
nr_inactive, pages_scanned and all_unreclaimable members, those
fields are shown. If the zone struct contains a per-zone vm_stat[]
array (identical to the system-wide vm_stat[] array), its contents
are dumped. For any other data in the zone, the address of the
zone structure is displayed.
(anderson(a)redhat.com)
- Fix for the RSS amounts displayed by the "ps" and "vm" commands
on 2.6 kernels prior to 2.6.13. (anderson(a)redhat.com)
- Fix for the x86 "bt" command when running a version of crash built
on a pre-2.6.20 host against a 2.6.20 or later dumpfile, or when
running a version of crash build on a 2.6.20 or later host against
a pre-2.6.20 dumpfile. Without the patch, kernel exception frames
would be mistaken for, and displayed as, user exception frames, and
parts of the backtrace above the kernel exception frame would be
truncated. (atyson(a)hp.com)
- Fix for FC8 xen x86 kernels (2.6.21-2952.fc8xen) that fail during
initialization after reporting "WARNING: cannot read linux_banner
string", followed by the fatal error message "crash: vmlinux and
vmcore do not match!". This required a change to the virtual
address mask value used to determine the base value of the x86
kernel's unity-mapped virtual address region. (anderson(a)redhat.com)
- Set a default "phys_base" value for recent fully-virtualized
relocatable x86_64 kernels whose text start address is not equal
to the __START_KERNEL_map value. Without the patch, the crash
session fails during initialization with the warning message
"WARNING: cannot read linux_banner string", followed by the fatal
error message "crash: vmlinux and vmcore do not match!". The
error can alternatively be worked around if the "phys_base" value
is first determined by running a crash session on the live system
that generated the dumpfile, by entering: "help -m | grep phys_base".
The value shown can then be used when running against the dumpfile
like so: "crash --machdep phys_base=<value> vmlinux vmcore"
(anderson(a)redhat.com)
- Debug: implemented a new "--active" crash command line option, which
will gather only the active tasks from each runqueue, skipping the
traversal of the kernel's pid_hash mechanism.
(anderson(a)redhat.com)
- Debug: "help -n" formats and displays ASCII VMCOREINFO data.
(anderson(a)redhat.com)
Download from: http://people.redhat.com/anderson
16 years, 10 months
Re: Crash-utility Digest, Vol 28, Issue 4
by baiwd
Luc:
>
> Message: 2
> Date: Thu, 10 Jan 2008 08:36:53 -0500
> From: Luc Chouinard <lchouinard(a)trueposition.com>
> Subject: Re: [Crash-utility] sial.c's apigetctype
> To: Discussion "list for crash utility usage, maintenance and
> development" <crash-utility(a)redhat.com>
> Message-ID: <1199972213.18723.3.camel@NgVboss2>
> Content-Type: text/plain
>
> Bai, those code paths have been fine tuned based on my limited
> understanding of the gdb type information layout. You cannot use a 'fall
> through' in this switch. It's a one to one match test.
>
> What's behind your question? Are you having problems with a script
> and/or symbol/type resolution? If so, send us/me a test case.
>
> Luc
>
I am very sorry for misunderstanding the meaning of your codes.
You are right,
break could not be deleted. Thank you for your providing this tool and
your expaining.
16 years, 10 months
sial.c's apigetctype
by baiwd
Hi:
I found some codes like
case TYPE_CODE_ENUM: if(sial_is_enum(ctype)) goto match; break;
I wonder that whether it would be better if these codes could be
changed as
following:
Signed-off-by: Bai Weidong <baiwd(a)cn.fujitsu.com>
--- crash-4.0-4.12/extensions/sial.c 2007-12-13 02:48:09.000000000 +0800
+++ crash-4.0-4.12/extensions/sial.new.c 2008-01-10 16:47:15.000000000 +0800
@@ -155,10 +155,10 @@ apigetctype(int ctype, char *name, TYPE_
if(sial_is_typedef(ctype) && v) goto match;
switch(TYPE_CODE(type)) {
case TYPE_CODE_TYPEDEF: case TYPE_CODE_INT:
- if(sial_is_typedef(ctype)) goto match; break;
- case TYPE_CODE_ENUM: if(sial_is_enum(ctype)) goto match; break;
- case TYPE_CODE_STRUCT: if(sial_is_struct(ctype)) goto match; break;
- case TYPE_CODE_UNION: if(sial_is_union(ctype)) goto match; break;
+ if(sial_is_typedef(ctype)) goto match;
+ case TYPE_CODE_ENUM: if(sial_is_enum(ctype)) goto match;
+ case TYPE_CODE_STRUCT: if(sial_is_struct(ctype)) goto match;
+ case TYPE_CODE_UNION: if(sial_is_union(ctype)) goto match;
}
sial_dbg_named(DBG_TYPE, name, 2, "Found but no match.\n");
}
Best Regards
Bai Weidong
16 years, 10 months
