My comment for the fix would be something like below.
/* The unity-mapped region is mapped using 1MB pages, hence 1-level translation
if bit 20 is set, we are 1MB apart physically, hence we move the page_dir
in case bit 20 is set. */
if (bit(vaddr,20))
page_dir = page_dir + 1;
does it make sense ?
Regards,
Oza.
________________________________
From: Mika Westerberg <[email protected]>
To: Dave Anderson <[email protected]>
Cc: paawan oza <[email protected]>; "Discussion list for crash utility
usage, maintenance and development" <[email protected]>; Thomas Fänge
<[email protected]>; jan karlsson <[email protected]>
Sent: Thursday, 4 October 2012 11:56 AM
Subject: Re: [Crash-utility] using crash for ARM
On Wed, Oct 03, 2012 at 09:45:51AM -0400, Dave Anderson wrote:
>
> Right -- it looks to be a bug, presuming that ARM is using 1MB pages
> for the unity-mapped region:
>
> crash> vtop c0000000 | grep PAGE:
> PAGE: 11000 (1MB)
> crash> vtop c0100000 | grep PAGE:
> PAGE: 11000 (1MB)
> crash> vtop c0200000 | grep PAGE:
> PAGE: 211000 (1MB)
> crash> vtop c0300000 | grep PAGE:
> PAGE: 211000 (1MB)
> crash> vtop c0400000 | grep PAGE:
> PAGE: 411000 (1MB)
> crash> vtop c0500000 | grep PAGE:
> PAGE: 411000 (1MB)
> crash>
The unity-mapped region is mapped using 1MB pages. However, we actually have
(when using the Linux ARM 2-level translation scheme):
see arch/arm/include/asm/pgtable-2level.h:
#define PMD_SHIFT 21
#define PGDIR_SHIFT 21
#define PTRS_PER_PGD 2048
So we have 2048 entries in a PGD instead of 4096 making a PGD entry an array
of "two pointers".
Anyway as you and Paawan suggested it looks like a bug - we always use the
first entry instead of the second given that bit 20 is set in the virtual
address.
Paawan, your fix looks sane to me but can you add a small comment describing
why this is done?
--
Crash-utility mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/crash-utility
