Re: [Crash-utility] [PATCH v3 0/3] vmalloc translation support for PPC

On 02/15/2012 10:56 AM, Suzuki K. Poulose wrote: > On 02/13/2012 10:17 PM, Dave Anderson wrote: >> >> ----- Original Message ----- >>> The following series implements : >>> >>> * An infrastructure for platform based vmalloc translation for >>> PPC32 >>> * vmalloc translation support for PPC44x >>> >>> Changes since V2: >>> >>> * Rebased to crash-6.0.3 >>> * Maintains a list of probe functions, rather than platform >>> definitions. >>> >>> >>> Each platform can define their own probe_function which would get >>> the name of the >>> ppc platform (read from kernel) and the probe can check if the >>> platform is one of its >>> variant. The probe function can then update the 'platform' >>> defintions for the virtual >>> address translation. >>> >>> If none of the defined platforms match, falls back to using the >>> default PPC32 >>> definitions. >>> >>> --- >>> >>> Suzuki K. Poulose (3): >>> [ppc] virtual address translation bits for PPC44x >>> [ppc] Support for platform based Virtual address translation >>> [ppc] Non-linear address translation routine >> >> Hi Suzuki, >> >> I'll defer the technical ACK to Toshi, but I do have a couple of >> other suggestions. >> >> Here's a sample vmalloc translation: >> >> crash> vtop d1180000 >> VIRTUAL PHYSICAL >> d1180000 ff800000 >> >> Using ppc440gp board definitions: >> PAGE DIRECTORY: c056f000 >> PGD: c0570a20 => c784b000 >> PMD: c784b000 => c784bc00 >> PTE: c784bc00 => 1ff80051b >> PAGE: ff800000 >> >> PTE PHYSICAL FLAGS >> ff80051b ff800000 (PRESENT|USER|GUARDED|COHERENT|ACCESSED) >> >> PAGE PHYSICAL MAPPING INDEX CNT FLAGS >> crash> >> >> This may have been a pre-existing issue, but for vmalloc >> addresses, the >> page struct translation at the end of the display (under PAGE >> PHYSICAL MAPPING...) >> is missing for vmalloc addresses. For user-space and unity-mapped >> addresses the translation is done as intended: >> >> User-space: >> >> crash> vtop ff8f000 >> VIRTUAL PHYSICAL >> ff8f000 6b90000 >> >> Using ppc440gp board definitions: >> PAGE DIRECTORY: c7a3a000 >> PGD: c7a3a1fc => c7bfc000 >> PMD: c7bfc000 => c7bfcc78 >> PTE: c7bfcc78 => 6b9005b >> PAGE: 6b90000 >> >> PTE PHYSICAL FLAGS >> 6b9005b 6b90000 (PRESENT|USER|GUARDED|COHERENT|WRITETHRU) >> >> VMA START END FLAGS FILE >> c7b09898 ff8f000 ff92000 100073 >> >> PAGE PHYSICAL MAPPING INDEX CNT FLAGS >> c06b5200 6b90000 c7a9fc61 ff8f 1 80068 >> crash> >> >> Kernel unity-mapped: >> >> crash> vtop c7b14000 >> VIRTUAL PHYSICAL >> c7b14000 7b14000 >> >> Using ppc440gp board definitions: >> PAGE DIRECTORY: c056f000 >> PGD: c05708f4 => 0 >> >> PAGE PHYSICAL MAPPING INDEX CNT FLAGS >> c06d4280 7b14000 0 0 1 0 >> crash> >> >> That should be a trivial fix. > > I took a look at the above issue of vtop report and here is what > I find : > > crash> p *vmlist > $17 = { > next = 0xc784e880, > addr = 0xd1002000, > size = 8192, > flags = 1, > pages = 0x0, > nr_pages = 0, > phys_addr = 8837398528, > caller = 0xc042bf40 > } > crash> vtop 0xd1002000 > VIRTUAL PHYSICAL > d1002000 ec00000 > > PAGE DIRECTORY: c0578000 > PGD: c0579a20 => c784b000 > PMD: c784b000 => c784b010 > PTE: c784b010 => 20ec0051b > PAGE: ec00000 > > PTE PHYSICAL FLAGS > ec0051b ec00000 (PRESENT|USER|GUARDED|COHERENT|ACCESSED) > > PAGE PHYSICAL MAPPING INDEX CNT FLAGS > > crash> x /i vmlist->caller > 0xc042bf40 <setup_indirect_pci+84>: blr > > Here, the total amount for RAM on the machine is 128M and looks like > the above address is memory mapped PCI bus, which lies above the 128M. > Also note that the number of pages is '0'. Since the page lies above the > 128M and the number of pages is 0, the dump_mem_map fails to find the page struct > for the corresponding phsyical address. > > If we go further in the vmlist to find the vmalloc address pages that have pages, > we get : > > crash> p *(vmlist->next->next->next) > $16 = { > next = 0xc78e51c0, > addr = 0xd1008000, > size = 8192, > flags = 2, > pages = 0xc7891680, > nr_pages = 1, > phys_addr = 0, > caller = 0xc006a1d0 > } > crash> vtop 0xd1008000 > VIRTUAL PHYSICAL > d1008000 7896000 > > PAGE DIRECTORY: c0578000 > PGD: c0579a20 => c784b000 > PMD: c784b000 => c784b040 > PTE: c784b040 => 789601f > PAGE: 7896000 > > PTE PHYSICAL FLAGS > 789601f 7896000 (PRESENT|USER|RW|GUARDED|COHERENT) > > PAGE PHYSICAL MAPPING INDEX CNT FLAGS > c06d72c0 7896000 0 0 1 0 > > So, may be we could add a check in the vmalloc translation to see if there is really > a page allocated for the block and then do the translation of the pages. I have a patch which could do something like: crash> vtop d1002000 VIRTUAL PHYSICAL d1002000 20ec00000 PAGE DIRECTORY: c0578000 PGD: c0579a20 => c784b000 PMD: c784b000 => c784b010 PTE: c784b010 => 20ec0051b PAGE: 20ec00000 PTE PHYSICAL FLAGS 20ec0051b 20ec00000 (PRESENT|USER|GUARDED|COHERENT|ACCESSED) The memory 0x20ec00000 doesn't have a PFN associated with it. It could be an MMIO region above the RAM(128 MB). crash>