2:42 p.m.
- Fix for kernels in which the irq_desc_t typedef is not included in
the vmlinux debuginfo data, by using the 2.6-era struct irq_desc.
Without the patch, the "irq" command fails with the error message,
"irq: cannot determine size of irq_desc_t". (hugh(a)mimosa.com)
- Implemented new "irq -u" option that displays only in-use IRQs, now
that there can be several thousand entries in the irq_desc[] array.
(anderson(a)redhat.com)
- Prevent occasional 99% cpu usage waiting for the built-in less
command to complete. (anderson(a)redhat.com)
- Implemented support for the use of "kerntypes" debuginfo files that
are created by the LKCD "dwarfextract" utility, as an alternative to
the use of the vmlinux file. This requires the use of the matching
System.map file, as in this example:
# crash kerntypes System.map [vmcore]
This capability was written by Cliff Wickman of SGI, and he has
generously offered to maintain its functionality. (cpw(a)sgi.com)
- Fixes, code improvement and cleanup for "crash -h [command]".
(hugh(a)mimosa.com)
- The output of command data exceeding a terminal page-size has been
traditionally fed by default to "/usr/bin/less -E -X" with a prompt;
if the /usr/bin/less command was not available on the host system,
output would be fed to "/bin/more" instead. Scrolling can be turned
off with "set scroll off" or the built-in alias "sf", and back on
with "set scroll on" or the built-in alias "sn". This release
allows the user to specify an alternative scrolling program by
creating a CRASHPAGER environment variable, which be used by default
if it exists. Also, the "set scroll [arg]" internal variable setting
command, which until now accepted "on" and "off" as arguments, now
accepts "less", "more" and "CRASHPAGER" as alternative
arguments,
both during runtime, or in .crashrc files. Also, new crash command
line arguments have also been added to override the default and/or
.crashrc settings: --more, --less, and --CRASHPAGER. Lastly, the
output of the "crash -h [command]" will also use the relevant scroll
command selection. (anderson(a)redhat.com)
- Updated crash(8) man page. (hugh(a)mimosa.com, anderson(a)redhat.com)
Download from: http://people.redhat.com/anderson
4:10 p.m.
Hi,
* Dave Anderson <anderson(a)redhat.com> [2007-07-20 21:42]:
- Implemented support for the use of "kerntypes" debuginfo files that
are created by the LKCD "dwarfextract" utility, as an alternative to
the use of the vmlinux file. This requires the use of the matching
System.map file, as in this example:
# crash kerntypes System.map [vmcore]
This capability was written by Cliff Wickman of SGI, and he has
generously offered to maintain its functionality. (cpw(a)sgi.com)
Hm ..., I like the feature, but it doesn't work here (x86_64,
2.6.22.1). I just compiled the kernel with debugging information (-g),
then
dwarfextract -p -s vmlinux Kerntypes
and now
crash -s /boot/System.map-2.6.22.1-default Kerntypes
WARNING: cannot determine pgdat list for this kernel/architecture
crash> p jiffies
p: gdb request failed: p jiffies
Am I doing sth. wrong here? With
crash -s /boot/System.map-2.6.22.1-default vmlinux
everything works flawlessly.
Thanks,
Bernhard
PS: I compiled dwarfextract with the patches from lkcdutils
(https://lkcd.svn.sourceforge.net/svnroot/lkcd/trunk/lkcdutils/PATCHES/)
applied to libdwarf from http://reality.sgiweb.org/davea/dwarf.html
(latest version).
9:09 a.m.
Bernhard Walle wrote:
Hi,
* Dave Anderson <anderson(a)redhat.com> [2007-07-20 21:42]:
>- Implemented support for the use of "kerntypes" debuginfo files that
> are created by the LKCD "dwarfextract" utility, as an alternative to
> the use of the vmlinux file. This requires the use of the matching
> System.map file, as in this example:
>
> # crash kerntypes System.map [vmcore]
>
> This capability was written by Cliff Wickman of SGI, and he has
> generously offered to maintain its functionality. (cpw(a)sgi.com)
Hm ..., I like the feature, but it doesn't work here (x86_64,
2.6.22.1). I just compiled the kernel with debugging information (-g),
then
dwarfextract -p -s vmlinux Kerntypes
and now
crash -s /boot/System.map-2.6.22.1-default Kerntypes
WARNING: cannot determine pgdat list for this kernel/architecture
crash> p jiffies
p: gdb request failed: p jiffies
Am I doing sth. wrong here? With
crash -s /boot/System.map-2.6.22.1-default vmlinux
everything works flawlessly.
And this is why I coerced Cliff into the support of this venture... ;-)
Anyway, Cliff and I went back-and-forth through several patch
submissions, and one of the things that I did insist upon was
that the Kerntypes-specific code be totally segregated from the
"traditional" code. (You can see a number of "LKCD_KERNTYPES()"
checks that do just that.) But that's why the vmlinux file usage
still should work "flawlessly"...
My guess is that Cliff was using an older kernel that was able
to either use the "if" block of this if-else statement, or that
either next_online_node() or next_online_pgdat() worked OK:
* This order may have to change based upon architecture...
*/
if (symbol_exists("pgdat_list") &&
(VALID_MEMBER(pglist_data_node_next) ||
VALID_MEMBER(pglist_data_pgdat_next))) {
get_symbol_data("pgdat_list", sizeof(void *),
&pgdat);
vt->flags &= ~NODES_ONLINE;
} else if (vt->flags & NODES_ONLINE) {
if ((node = next_online_node(0)) < 0) {
error(WARNING,
"cannot determine first node from
node_online_map\n\n");
return;
}
if (!(pgdat = next_online_pgdat(node))) {
error(WARNING,
"cannot determine pgdat list for this
kernel/architecture\n\n");
return;
}
}
I guess I'd work back from there -- figure out what it does "right"
when you use the vmlinux, and determine why it doesn't take that
path when using the kerntypes file.
But as to why the "p jiffies" failed, I'm sure I don't understand
why that doesn't work?
Cliff -- correct me if I'm wrong -- simple gdb commands against a
kerntypes file should work OK, correct?
Dave
Thanks,
Bernhard
PS: I compiled dwarfextract with the patches from lkcdutils
(https://lkcd.svn.sourceforge.net/svnroot/lkcd/trunk/lkcdutils/PATCHES/)
applied to libdwarf from http://reality.sgiweb.org/davea/dwarf.html
(latest version).
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
11:09 a.m.
crash-utility-bounces(a)redhat.com wrote on 07/20/2007 09:42:31 PM:
[snip]
- Implemented support for the use of "kerntypes" debuginfo
files that
are created by the LKCD "dwarfextract" utility, as an alternative to
the use of the vmlinux file. This requires the use of the matching
System.map file, as in this example:
# crash kerntypes System.map [vmcore]
This capability was written by Cliff Wickman of SGI, and he has
generously offered to maintain its functionality. (cpw(a)sgi.com)
Hi Dave and Cliff,
Which format does the dwarfextract utility produce? Is it still
ELF format just containing the dwarf sections?
Is it possible to use the "traditional" lkcd kerntypes file, a
simple C-file containing a bunch of kernel includes, which is
compiled with -g?
Michael
11:32 a.m.
On Mon, Jul 23, 2007 at 06:09:37PM +0200, Michael Holzheu wrote:
crash-utility-bounces(a)redhat.com wrote on 07/20/2007 09:42:31 PM:
[snip]
> - Implemented support for the use of "kerntypes" debuginfo files that
> are created by the LKCD "dwarfextract" utility, as an alternative to
> the use of the vmlinux file. This requires the use of the matching
> System.map file, as in this example:
>
> # crash kerntypes System.map [vmcore]
>
> This capability was written by Cliff Wickman of SGI, and he has
> generously offered to maintain its functionality. (cpw(a)sgi.com)
>
Hi Dave and Cliff,
Which format does the dwarfextract utility produce? Is it still
ELF format just containing the dwarf sections?
Is it possible to use the "traditional" lkcd kerntypes file, a
simple C-file containing a bunch of kernel includes, which is
compiled with -g?
Michael
The kerntypes produced by dwarfextract is just like the "traditional"
lkcd kerntypes file, except that tool can pull types from many compiled
objects and combine them into one.
The difference between a kerntypes and a -g vmlinux is that the former
has only structure type information, nothing about kernel symbols themselves.
That is why the gdb "p" command fails if using kerntypes.
And also why Bernhard saw the failure in finding a node's pglist_data
structure.
In the 2.6.22 kernel there is no linked list thru the pglist_data's. We
have to index into the node_data array.
But crash uses gdb to test that node_data is an array, so that
fails with kerntypes.
I need to check all the places where get_symbol_type() is called and
use an alternate method if using kerntypes.
-Cliff
--
Cliff Wickman
Silicon Graphics, Inc.
cpw(a)sgi.com
(651) 683-3824
11:55 a.m.
crash-utility-bounces(a)redhat.com wrote on 07/23/2007 06:32:59 PM:
The kerntypes produced by dwarfextract is just like the
"traditional"
lkcd kerntypes file, except that tool can pull types from many compiled
objects and combine them into one.
Hallo Cliff,
So dwarfextract produces ELF format? I ask this question, because
sometimes it would be useful to have a small kerntypes file which
could be used for both crash and lcrash. Is that possible now?
Michael
1:23 p.m.
On Mon, Jul 23, 2007 at 06:55:19PM +0200, Michael Holzheu wrote:
crash-utility-bounces(a)redhat.com wrote on 07/23/2007 06:32:59 PM:
> The kerntypes produced by dwarfextract is just like the "traditional"
> lkcd kerntypes file, except that tool can pull types from many compiled
> objects and combine them into one.
>
Hallo Cliff,
So dwarfextract produces ELF format? I ask this question, because
sometimes it would be useful to have a small kerntypes file which
could be used for both crash and lcrash. Is that possible now?
Yes it's in ELF format.
--
Cliff Wickman
Silicon Graphics, Inc.
cpw(a)sgi.com
(651) 683-3824
7009
days inactive
7012
days old
devel@lists.crash-utility.osci.io
6 comments
4 participants
participants (4)
-
Bernhard Walle -
Cliff Wickman -
Dave Anderson -
Michael Holzheu