[Crash-utility] is_page_ptr vs. x86_64_kvtop

[Bruce Korb]

On 03/18/13 12:19, Dave Anderson wrote:
>> That seems large to me too, by about a factor of 10.
>> It _is_ a largish system.
> 
> What does the initial system banner (or the "sys" command) show?

1/16 of a terabyte (64GB :)

> At first I didnn't understand how there could be a MEM_MAP of "0"
[...]
> But after section 131, the PFN values start at 4328521728 -- which
> is 16512GB (~16.5 TB).  So clearly the section data is [scrogged]

It's been bugging me, too...

>> NR      SECTION        CODED_MEM_MAP        MEM_MAP       PFN
>> [...]
>> 131  ffff88107fff9060  ffffea0000000000  ffffea000e540000  4292608
>> 132096  ffff880838574558  ffff881038105798  ffff8848a8105798 4328521728 (bogus from here onward...)
>> [...]
>> 237507  ffff8810369d2fa0  ffff881033219740  ffff8875ac759740 7782629376
>> kmem: page excluded: kernel virtual address: ffff8810369d3000  type: "memory section"

> So again, the output with the full kmem -n display contains
> bizarre values after section 131, causing it to go off into
> the weeds:

> So clearly crash is mishandling the memory setup being presented to it.

"doesn't know how to handle", but what I need isn't in the dump anyway.

> But I have *no* idea what the problem is.

Then I'm not alone.

>> If the kmem -n output didn't seem to skip over the address of
>> interest....
> 
> Right, it would walk through all of the sections from obviously misinterpreted
> section data above, and would not find your target page.

>> So:  what physical pages are missing and why are the missing?
>> With those two questions resolved, we can fix the dump specification
>> to include the missing pages.
> 
> I don't know how SUSE sets up their dumping operation.

And I don't have direct access to the machines causing me the trouble.
The engineers who do are digesting your post to see if they can
add back in the missing pages.  We'll see. Thank you so much!!

Regards, Bruce