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

Suzuki K. Poulose suzuki at in.ibm.com
Wed Feb 15 05:26:48 UTC 2012


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.

Thoughts ?

Suzuki




More information about the Crash-utility mailing list