[Crash-utility] crash 4.0-2.8 fails on 2.6.14-rc5 (EM64T)

Dave Anderson anderson at redhat.com
Thu Oct 27 18:42:55 UTC 2005


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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20051027/8d95837b/attachment.htm>


More information about the Crash-utility mailing list