5:21 a.m.
Some days ago I was in a situation that I had to convert vmcore in
kvmdump format into ELF since some extension module we have locally
can be used only on relatively old crash utility, around version 4,
but such old crash utility cannot handle kvmdump format.
To do the conversion in handy, I used snap command with some modifications
so that it tries to use iomem information in vmcore instead of host's
/proc/iomem. This patch is its cleaned-up version.
In this development, I naturally got down to also making an interface
for an access to resource objects, and so together with the snap
command's patch, I also extended kmem command for iomem/ioport
support. Actually:
kmem -r displays /proc/iomem
crash> kmem -r
00000000-0000ffff : reserved
00010000-0009dbff : System RAM
0009dc00-0009ffff : reserved
000c0000-000c7fff : Video ROM
...
and kmem -R displays /proc/ioport
crash> kmem -R
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
...
Looking into old version of kernel source code back, resource structure
has been unchanged since linux-2.4.0. I borrowed the way of walking on
resouce tree in this patch from the lastest v3.3-rc series, but I
guess the logic is also applicable to old kernels. I expect Dave's
regression testsuite.
Also, there would be another command more sutable for iomem/ioport.
If necessay, I'll repost the patch.
---
HATAYAMA Daisuke (4):
Add vmcore snapshot support
Add kmem -r and -R options
Add dump iomem/ioport functions; a helper for resource objects
Add a helper function for iterating resource objects
defs.h | 9 ++++
extensions/snap.c | 54 ++++++++++++++++++++++-
help.c | 2 +
memory.c | 122 +++++++++++++++++++++++++++++++++++++++++++++++++++--
4 files changed, 180 insertions(+), 7 deletions(-)
--
Thanks.
HATAYAMA Daisuke
9:17 a.m.
----- Original Message -----
Some days ago I was in a situation that I had to convert vmcore in
kvmdump format into ELF since some extension module we have locally
can be used only on relatively old crash utility, around version 4,
but such old crash utility cannot handle kvmdump format.
That's a pretty weak argument -- what did crash version ~4 have
that the latest version does not? I don't recall ever removing
any functionality w/respect to extension module without replacing
it with a better interface. In other words, why can't you fix your
local extension module? I need a better reason for modifying
the snap module other than that.
To do the conversion in handy, I used snap command with some
modifications
so that it tries to use iomem information in vmcore instead of host's
/proc/iomem. This patch is its cleaned-up version.
In this development, I naturally got down to also making an interface
for an access to resource objects, and so together with the snap
command's patch, I also extended kmem command for iomem/ioport
support. Actually:
kmem -r displays /proc/iomem
crash> kmem -r
00000000-0000ffff : reserved
00010000-0009dbff : System RAM
0009dc00-0009ffff : reserved
000c0000-000c7fff : Video ROM
...
and kmem -R displays /proc/ioport
crash> kmem -R
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
...
Looking into old version of kernel source code back, resource structure
has been unchanged since linux-2.4.0. I borrowed the way of walking on
resouce tree in this patch from the lastest v3.3-rc series, but I
guess the logic is also applicable to old kernels. I expect Dave's
regression testsuite.
Also, there would be another command more sutable for iomem/ioport.
If necessay, I'll repost the patch.
---
Why reinvent the wheel? The "dev -i" command does all of the above, plus
gives you the resource structure address:
crash> dev -i
RESOURCE RANGE NAME
ffffffff80312080 0000-ffff PCI IO
ffffffff8030a9c0 0000-001f dma1
ffffffff8030a9f8 0020-0021 pic1
ffffffff8030aa30 0040-0043 timer0
ffffffff8030aa68 0050-0053 timer1
ffffffff8030aaa0 0060-0060 keyboard
ffffffff8030aad8 0064-0064 keyboard
ffff81102fd42140 0070-0077 rtc
... [ cut ] ...
ffff8102370a3b28 3400-34ff 0000:00:07.2
ffff810c2ff6dc78 4000-4fff PCI Bus #03
ffff810a3709f360 4000-40ff 0000:03:00.0
ffff81022feb1740 4000-40ff cciss
ffff8106370a3478 5000-5fff PCI Bus #04
ffff810637099360 5000-50ff 0000:04:00.0
ffff81062fd02a00 5000-50ff cciss
RESOURCE RANGE NAME
ffffffff803120c0 00000000-ffffffffffffffff PCI mem
ffff81000009e000 00010000-0009f3ff System RAM
ffff810000102000 0009f400-0009ffff reserved
ffffffff8030aca0 000a0000-000bffff Video RAM area
ffffffff8030ae40 000c0000-000cafff Video ROM
ffffffff8030ace0 000cb000-000cc7ff Adapter ROM
ffffffff8030ae80 000f0000-000fffff System ROM
ffff810000102100 00100000-cfd4bfff System RAM
ffffffff8030ac40 00200000-0048367d Kernel code
ffffffff8030ac00 0048367e-005c9bff Kernel data
ffffffff803166a0 01000000-08ffffff Crash kernel
ffffffff80310880 10000000-13ffffff GART
ffff810000102180 cfd4c000-cfd55fff ACPI Tables
ffff810000102200 cfd56000-cfd56fff System RAM
ffff810000102280 cfd57000-dfffffff reserved
ffff810a370a4ce8 e2000000-e20fffff PCI Bus #01
... [cut] ...
ffff8106370a34b0 fde00000-fdffffff PCI Bus #04
ffff810637099398 fdef0000-fdef0fff 0000:04:00.0
ffff81062fd029c0 fdef0000-fdef0fff cciss
ffff8106370992f0 fdf00000-fdffffff 0000:04:00.0
ffff81062fd02a40 fdf00000-fdffffff cciss
ffff810000102300 fec00000-fecfffff reserved
ffff810000102380 fee00000-fee0ffff reserved
ffff810000102400 ffc00000-ffffffff reserved
ffff810000102480 100000000-102fffefff System RAM
crash>
Dave
8:14 a.m.
From: Dave Anderson <anderson(a)redhat.com>
Subject: Re: [Crash-utility] [PATCH] kmem, snap: iomem/ioport display and vmcore snapshot
support
Date: Tue, 13 Mar 2012 10:17:20 -0400 (EDT)
----- Original Message -----
> Some days ago I was in a situation that I had to convert vmcore in
> kvmdump format into ELF since some extension module we have locally
> can be used only on relatively old crash utility, around version 4,
> but such old crash utility cannot handle kvmdump format.
That's a pretty weak argument -- what did crash version ~4 have
that the latest version does not? I don't recall ever removing
any functionality w/respect to extension module without replacing
it with a better interface. In other words, why can't you fix your
local extension module? I need a better reason for modifying
the snap module other than that.
I don't know the detail of the local extension module. The man who
requested a help to me explained that his module gets information of
vmcore using crash (gdb) scripts and retrives values from the scripts'
output via pipe. While old crash behaves well, recent ones appear to
hang in the situation where both reading and writing sides wait each
other. Is there any difference of behaviour on communication with gdb?
Anyway it's natural that we should modify the extension module, and
we'll do that soon. The patch for snap command was a workaround, but
there's merit to the patch that it makes it possible to use it as
handy vmcore conversion tool, not just as live kernel dump command, so
I've posted this here. By this, snap command will become able to
convert all the format currently crash supports into ELF. Though I
have yet to test this, this can convert lkcd foramt into ELF, for
example. Someone might want to use this for vmcore not suppoted by
Makedumpfile.
Why reinvent the wheel? The "dev -i" command does all of the above, plus
gives you the resource structure address:
crash> dev -i
RESOURCE RANGE NAME
ffffffff80312080 0000-ffff PCI IO
<cut>
I myself thought it's strange if it's not present. Before making my
patch, I did minimum check by searching crash source code for related
symbols such as ``resource'', but I didn't find anything. Now I see
some symbols found with the same keyword. I think I did something
wrong at that time.
Thanks.
HATAYAMA, Daisuke
8:16 a.m.
----- Original Message -----
From: Dave Anderson <anderson(a)redhat.com>
Subject: Re: [Crash-utility] [PATCH] kmem, snap: iomem/ioport display
and vmcore snapshot support
Date: Tue, 13 Mar 2012 10:17:20 -0400 (EDT)
>
>
> ----- Original Message -----
>> Some days ago I was in a situation that I had to convert vmcore in
>> kvmdump format into ELF since some extension module we have locally
>> can be used only on relatively old crash utility, around version 4,
>> but such old crash utility cannot handle kvmdump format.
>
> That's a pretty weak argument -- what did crash version ~4 have
> that the latest version does not? I don't recall ever removing
> any functionality w/respect to extension module without replacing
> it with a better interface. In other words, why can't you fix your
> local extension module? I need a better reason for modifying
> the snap module other than that.
>
I don't know the detail of the local extension module. The man who
requested a help to me explained that his module gets information of
vmcore using crash (gdb) scripts and retrives values from the scripts'
output via pipe. While old crash behaves well, recent ones appear to
hang in the situation where both reading and writing sides wait each
other. Is there any difference of behaviour on communication with
gdb?
I don't know exactly. There's certainly have been new gdb versions,
and the changelog has a few small patches w/respect to gdb commands,
but it's hard to say how they might affect the usage of gdb scripts
from a module (?).
Anyway it's natural that we should modify the extension module, and
we'll do that soon. The patch for snap command was a workaround, but
there's merit to the patch that it makes it possible to use it as
handy vmcore conversion tool, not just as live kernel dump command, so
I've posted this here. By this, snap command will become able to
convert all the format currently crash supports into ELF. Though I
have yet to test this, this can convert lkcd foramt into ELF, for
example. Someone might want to use this for vmcore not suppoted by
Makedumpfile.
OK, here's what to do. The snap extension module is just that -- it
takes a "snapshot" of live physical memory and creates an ELF file.
I don't want to change that.
However, I suppose the concept of a "conversion-to-ELF" tool makes sense.
That being the case, please create a standalone extension module, and
call it "mkelf", or "kvm2elf", or whatever name you want. Then we
can
add it to the collection of modules on the extension module web page.
Thanks,
Dave
>
> Why reinvent the wheel? The "dev -i" command does all of the above, plus
> gives you the resource structure address:
>
> crash> dev -i
> RESOURCE RANGE NAME
> ffffffff80312080 0000-ffff PCI IO
<cut>
I myself thought it's strange if it's not present. Before making my
patch, I did minimum check by searching crash source code for related
symbols such as ``resource'', but I didn't find anything. Now I see
some symbols found with the same keyword. I think I did something
wrong at that time.
Thanks.
HATAYAMA, Daisuke
8:14 a.m.
From: Dave Anderson <anderson(a)redhat.com>
Subject: Re: [Crash-utility] [PATCH] kmem, snap: iomem/ioport display and vmcore snapshot
support
Date: Wed, 14 Mar 2012 09:16:29 -0400 (EDT)
----- Original Message -----
> From: Dave Anderson <anderson(a)redhat.com>
> Subject: Re: [Crash-utility] [PATCH] kmem, snap: iomem/ioport display
> and vmcore snapshot support
> Date: Tue, 13 Mar 2012 10:17:20 -0400 (EDT)
>
<snip>
>
> Anyway it's natural that we should modify the extension module, and
> we'll do that soon. The patch for snap command was a workaround, but
> there's merit to the patch that it makes it possible to use it as
> handy vmcore conversion tool, not just as live kernel dump command, so
> I've posted this here. By this, snap command will become able to
> convert all the format currently crash supports into ELF. Though I
> have yet to test this, this can convert lkcd foramt into ELF, for
> example. Someone might want to use this for vmcore not suppoted by
> Makedumpfile.
OK, here's what to do. The snap extension module is just that -- it
takes a "snapshot" of live physical memory and creates an ELF file.
I don't want to change that.
It appeared to me that it's natural to add the support of vmcore
memory to snap command for a small change of the code; part of getting
memory mapping only.
However, I suppose the concept of a "conversion-to-ELF"
tool makes sense.
That being the case, please create a standalone extension module, and
call it "mkelf", or "kvm2elf", or whatever name you want. Then we
can
add it to the collection of modules on the extension module web page.
OK. This takes just a little more time than extending snap
command. I'll send the patch next or a few weeks later. I would barrow
most part from the source code of snap command.
Thanks.
HATAYAMA, Daisuke
404
days inactive
4666
days old
devel@lists.crash-utility.osci.io
4 comments
2 participants
participants (2)
-
Dave Anderson -
HATAYAMA Daisuke