Re: [Crash-utility] kmem: WARNING: cannot find mem_map page for address
----- Original Message -----
Hi Dave,
On Tue, Dec 18, 2012 at 2:12 PM, Dave Anderson <anderson(a)redhat.com>
wrote:
>> > crash> p mem_section[0x400]
>> > $13 = (struct mem_section *) 0xffffffff81a26658
>> > crash> p mem_section[0x400][0x0]
>> > $14 = {
>> > section_mem_map = 0xffffffff81a26630,
>> > pageblock_flags = 0xffffffff81a26680
>> > }
I think I did show the memory section. But it is understandable if you missed it.
I plodded my way through the macros to figure out that the flag value
of
> crash> p $tp->page->flags
> $9 = 0x200000000000000
ultimately maps to indexes of 0x400 and 0.
(47 bit shift for first index)
There are only two fields because of kernel build options.
> crash> struct mem_section ffff88021e5eb000 -x
> struct mem_section {
> section_mem_map = 0xffffea0000000003,
> pageblock_flags = 0xffff88021e1eaa00,
Since your example has upper 4 bytes of 0xffffea00, similar to
the (cfs_page_t *) 0xffffea001bb1d1e8 page address I am trying to
understand, maybe the 0xffffffff81a26630 address is bogus?
> page_cgroup = 0xffff880215880000,
> pad = 0x0
Right, mem_section->section_mem_map has to contain a vmemmap address for
this to make any sense.
You might try the obvious, which is to do what is done for the advertised
vmemmap pages.
Get the page structure offset from the beginning of the vmemmap range:
crash> eval 0xffffea001bb1d1e8 - ffffea0000000000
hexadecimal: 1bb1d1e8
decimal: 464638440
octal: 3354350750
binary: 0000000000000000000000000000000000011011101100011101000111101000
crash>
Get the page number (pfn) by dividing that by the sizeof a page (64 on my system):
crash> eval 1bb1d1e8 / 64
hexadecimal: 6ec747
decimal: 7259975
octal: 33543507
binary: 0000000000000000000000000000000000000000011011101100011101000111
crash>
Multiply the resultant pfn times the page size to get the physical address:
crash> eval 6ec747 * 4k
hexadecimal: 6ec747000 (29039900KB)
decimal: 29736857600
octal: 335435070000
binary: 0000000000000000000000000000011011101100011101000111000000000000
crash>
And then "rd -p" the physical address to see if (1) it exists, and (2) you can
somehow verify that the data is correct -- if that's even possible.
Dave