Hi Dave,
2007/03/29 08:31:54 -0500, Dave Anderson <anderson(a)redhat.com> wrote:
Dave Anderson wrote:
>
> Can you make the vmlinux/vmcore pair available to me? Then I
> fix this particular issue as well as testing my implementation of the
> crash utility's excluded page handling.
>
> Thanks,
> Dave
On another note, would it be possible to pass the "dump_level" in the
diskdump header somehow -- while maintaining backwards
compatibility with compressed-diskdump files? Perhaps in the
upper bits of the diskdump->header_version, or something
like that?
I think it would be useful to know exactly which types of pages
were excluded from a dumpfile when analyzing it.
I think it is good that the crash utility can know the dump_level
of a dumpfile. But it is not good that dump_level is merged into
diskdump->header_version, because one member should represent one
meaning. I checked the code of crash-4.0-3.21, and I noticed
diskdump->total_ram_blocks is not referred by the crash utility
though the diskdump module sets the value into it. And makedumpfile
sets 0 into it. It does not have any meaning.
Can this member be changed for dump_level ?
I think the following methods for it:
- If the crash utility reads a dumpfile, it checks diskdump->
header_version.
- If diskdump->header_version is 1 or more, the crash utility
considers diskdump->total_ram_blocks as dump_level.
By the way, the dump_level of diskdump is different from the one
of kdump (makedumpfile). If the crash utility will be able to
display the excluded page-type, we should note it.
The dump_level of diskdump
1: Excluding cache pages with private pages
2: Excluding zero-filled pages
4: Excluding free pages
8: Excluding user process data pages
16: Saving private pages
The dump_level of kdump (makedumpfile)
1: Excluding zero-filled pages
2: Excluding cache pages without private pages
4: Excluding cache pages with private pages
8: Excluding user process data pages
16: Excluding free pages
Thanks
Ken'ichi Ohmichi