Bob Montgomery wrote:
> I've been experimenting with the makedumpfile utility for kdump on ia64.
> One of my experiments was to verify that a page that should have been
> missing indeed was missing. I used crash 4.0-3.8 to look for a user
> page that should have been omitted from the dump.
>
> crash> x/xg 0xe0000040fc00c000
> 0xe0000040fc00c000: 0x0000000000000000
>
> On a full dump from makedumpfile as well as on a straight copy of
> vmcore, crash reports this:
>
> crash> x/xg 0xe0000040fc00c000
> 0xe0000040fc00c000: 0x00010102464c457f
>
> The dumpfiles created by makedumpfile appear to crash as diskdump files,
> and crash appears to excuse missing pages and report 0x0 contents here:
>
> diskdump.c:read_diskdump, line 454:
>
> if (!page_is_dumpable(pfn)) {
> memset(bufptr, 0, cnt);
> return cnt;
>
> Shouldn't there be some indication that a requested page is missing as
> opposed to being legitimately full of zeros?
>
> Bob Montgomery
Hi Bob,
That decision was made by the diskdump developers
when I accepted their diskdump-specific work into the
crash utility.
As I recall, I kind of agreed with you at the time, but there
was some compelling reason that they had that argued for
passing a zero-filled page -- although I don't recall what it
was?
I don't believe it had anything to do with user pages,
but in the case of some of the other kernel pages that can
be left out of the dump, passing back a zero-filled page
was a cleaner way to handle whatever the problem was.
Anyway, I've long since forgotten why they wanted it
that way...
Perhaps the diskdump guys on this list can refresh my
memory?
Thanks,
Dave
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
