Re: [Crash-utility] is_page_ptr vs. x86_64_kvtop
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