[Crash-utility] kmem: WARNING: cannot find mem_map page for address

[Bruce Korb]

Good morning, Dave,

On Tue, Dec 18, 2012 at 6:52 AM, Dave Anderson <anderson at redhat.com> wrote:
> then it is also issued to those end-points here:
>
>         if ((fp != stdout) && (fp != pc->stdpipe)) {
>                 fprintf(fp, "%s%s%s %s", new_line ? "\n" : "",
[...]
>         }
>
> It's that "duplication" above that you're seeing.
>
> And I am simply suggesting that the if statement above should be:
>
>         if ((fp != stdout) && (fp != pc->stdpipe) && (fp != pc->tmpfile)) {

That works best.  I had dismissed that because it was a behavioral change.
Thank you.

>> Also no.  "kmem -v" and "kmem -n" both show the same memory mappings
>> (as best as _my_ memory serves, that is.  For certain, neither has a mapping
>> for 0xffffea001bb1d1e8.)
>>
>> > OK so you say you cannot get the mappings for it, but what
>> > does "vtop 0xffffea001bb1d1e8" show?
>>
>> This:
>>
>> > crash> vtop 0xffffea001bb1d1e8
>> > VIRTUAL           PHYSICAL
>> > ffffea001bb1d1e8  879b1d1e8
>> >
>> > PML4 DIRECTORY: ffffffff817e7000
>> > PAGE DIRECTORY: 87fdf7067
>> >    PUD: 87fdf7000 => 87fdf6067
>> >    PMD: 87fdf66e8 => 8000000879a001e3
>> >   PAGE: 879a00000  (2MB)
>> >
>> >       PTE         PHYSICAL   FLAGS
>> > 8000000879a001e3  879a00000  (PRESENT|RW|ACCESSED|DIRTY|PSE|GLOBAL|NX)
>>
>> But given:
>>
>> > Sorry -- that's irrelevant.  You want to access the physical
>> > memory that the odd vmemmap page address references (not the
>> > physical page behind the page structure itself).
>>
>> Exactly right.  I need to be able to see the binary bits for that page so I can
>> pull them in and write them back out to a file of just those bits.  From there,
>> we'll be formatting a text file showing the lustre trace log.
>>
>> Thank you so much!  Regards, Bruce
>
> Right... seems like it should be such a simple thing to do...   :-(
>
> I don't understand what's going on, but I'm presuming that even if the
> vmemmap-type address doesn't fit into the "advertised" vmemmap range,
> that the kernel's __page_to_pfn() macro should still work to get the
> pfn represented by the page:
>
>  #elif defined(CONFIG_SPARSEMEM)
>  /*
>   * Note: section's mem_map is encorded to reflect its start_pfn.
>   * section[i].section_mem_map == mem_map's address - start_pfn;
>   */
>  #define __page_to_pfn(pg)                                       \
>  ({      const struct page *__pg = (pg);                         \
>          int __sec = page_to_section(__pg);                      \
>          (unsigned long)(__pg - __section_mem_map_addr(__nr_to_section(__sec))); \
>  })
>
> Maybe you could play around with emulating that macro w/crash, and see what
> comes up?

Will do, after a couple of con calls.  Thank you!  Regards, Bruce