Re: [Crash-utility] crash 4.0-2.8 fails on 2.6.14-rc5 (EM64T)
Badari Pulavarty wrote:
It looks like level page table changed the layout. Now,
0xffff810000000000 is a valid.
Documentation/x86_64/mm.txt
Virtual memory map with 4 level page tables:
0000000000000000 - 00007fffffffffff (=47bits) user space, different per
mm
hole caused by [48:63] sign extension
ffff800000000000 - ffff80ffffffffff (=40bits) guard hole
ffff810000000000 - ffffc0ffffffffff (=46bits) direct mapping of phys.
memory
ffffc10000000000 - ffffc1ffffffffff (=40bits) hole
ffffc20000000000 - ffffe1ffffffffff (=45bits) vmalloc/ioremap space
... unused hole ...
ffffffff80000000 - ffffffff82800000 (=40MB) kernel text mapping, from
phys 0
... unused hole ...
ffffffff88000000 - fffffffffff00000 (=1919MB) module mapping space
Thanks,
Badari
Yep. (our last messages crossed...)
There probably will need to be some work done to deal with
page table walkthroughs in x86_64_kvtop() and x86_64_uvtop()
for translating non-unity-mapped memory like user space
and vmalloc space.
But just getting the basic unity-mapped memory accesses will
be a initial necessity before even looking into that.
Dave
Attachments:
- attachment.html (text/html — 1.7 KB)