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

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.