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
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
