Good morning, Dave,
On Tue, Dec 18, 2012 at 6:52 AM, Dave Anderson <anderson@xxxxxxxxxx> 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
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
