using crash for ARM - Page 4

10-04-2012, 10:55 AM

Isn't the problem actually that we read the section entry wrong?
The following (and attached) is the fix I've been using for this.
Oza: it is not a problem as none of the kernel section level translations goes through vtop.if you look at

arm_kvtop(struct task_context *tc, ulong kvaddr, physaddr_t *paddr, int verbose)
{
*
*** if (!IS_KVADDR(kvaddr))
*** *** return FALSE;

*** if (!vt->vmalloc_start) {
*** *** *paddr = VTOP(kvaddr);
*** *** return TRUE;
*** }

*** if (!IS_VMALLOC_ADDR(kvaddr)) {
*** *** *paddr = VTOP(kvaddr);
*** *** if (!verbose)
*** *** *** return TRUE;
*** }

*** return arm_vtop(kvaddr, (ulong *)vt->kernel_pgd[0],
paddr, verbose);
it just uses VTOP for any kernel address other than vmalloc.and vmalloc addresses are not falling in sections.
may in kernel_init part it might be
called, but it is a problem only if 20th bit set; and while section translation we mask 20th bit.

Regards,Oza.
From: Rabin Vincent <rabin@rab.in>
To: "Discussion list for crash utility usage, maintenance and development" <crash-utility@redhat.com>
Cc: Thomas Fänge <thomas.fange@sonymobile.com>
Sent: Thursday, 4 October
2012 2:35 PM
Subject: Re: [Crash-utility] using crash for ARM

2012/10/4 Mika Westerberg <mika.westerberg@iki.fi>:
> 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.

Isn't the problem actually that we read the section entry wrong?
The following (and attached) is the fix I've been using for this.

Rabin

diff --git a/arm.c b/arm.c
index 5930c02..4e7b6dc 100644
--- a/arm.c
+++ b/arm.c
@@ -957,12 +957,14 @@ arm_vtop(ulong vaddr, ulong *pgd, physaddr_t
*paddr, int verbose)
*** *** *** MKSTR((ulong)page_middle)), pmd_pte);

*** if ((pmd_pte & PMD_TYPE_MASK) == PMD_TYPE_SECT) {
+*** *** ulong sectionbase = pmd_pte & _SECTION_PAGE_MASK;
+
*** *** if (verbose) {
*** *** *** fprintf(fp, " PAGE: %s* (1MB)

",
*** *** *** *** mkstring(buf, VADDR_PRLEN,
RJUST | LONG_HEX,
-*** *** *** *** MKSTR(PAGEBASE(pmd_pte))));
+*** *** *** *** MKSTR(sectionbase)));
*** *** }
-*** *** *paddr = PAGEBASE(pmd_pte) + (vaddr & ~_SECTION_PAGE_MASK);
+*** *** *paddr = sectionbase + (vaddr & ~_SECTION_PAGE_MASK);
*** *** return TRUE;
*** }

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

10-04-2012, 11:30 AM

Hi,

I added the code, but I am still getting mismatch for following kernel virtual addresses.
<ignore the text, its my writing, but adding below patch did not help >

looks like we have to check 20th bit and take it into consideration.

Physical address mismatch detected @ section @ vaddress :0xc0100000 and phy_addr : 0x82000000
corrupt page tables;invalid virtual address 0xC0100000
Physical address mismatch detected @ section @ vaddress :0xc0100004 and phy_addr : 0x82000004
corrupt page tables;invalid virtual address 0xC0100004
Physical address mismatch detected @ section @ vaddress :0xc0100008 and phy_addr : 0x82000008
corrupt page tables;invalid virtual address 0xC0100008
Physical address mismatch detected @ section @ vaddress :0xc010000c and phy_addr : 0x8200000C
corrupt page
tables;invalid virtual address 0xC010000C
Physical address mismatch detected @ section @ vaddress :0xc0100010 and phy_addr : 0x82000010
corrupt page tables;invalid virtual address 0xC0100010
Physical address mismatch detected @ section @ vaddress :0xc0100014 and phy_addr : 0x82000014
corrupt page tables;invalid virtual address 0xC0100014
Physical address mismatch detected @ section @ vaddress :0xc0100018 and phy_addr : 0x82000018
corrupt page tables;invalid virtual address 0xC0100018
Physical address mismatch detected @ section @ vaddress :0xc010001c and phy_addr : 0x8200001C
corrupt page tables;invalid virtual address 0xC010001C
Physical address mismatch detected @ section @ vaddress :0xc0100020 and phy_addr : 0x82000020
corrupt page tables;invalid virtual address 0xC0100020
Physical address mismatch detected @ section @ vaddress :0xc0100024 and phy_addr : 0x82000024
corrupt page tables;invalid virtual address
0xC0100024
Physical address mismatch detected @ section @ vaddress :0xc0100028 and phy_addr : 0x82000028
corrupt page tables;invalid virtual address 0xC0100028
Physical address mismatch detected @ section @ vaddress :0xc010002c and phy_addr : 0x8200002C
corrupt page tables;invalid virtual address 0xC010002C
Physical address mism

Regards,
Oza.

From: Rabin Vincent <rabin@rab.in>
To: "Discussion list for crash utility usage, maintenance and development" <crash-utility@redhat.com>
Cc: Thomas Fänge
<thomas.fange@sonymobile.com>
Sent: Thursday, 4 October 2012 2:35 PM
Subject: Re: [Crash-utility] using crash for ARM

2012/10/4 Mika Westerberg <mika.westerberg@iki.fi>:
> 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.

Isn't the problem actually that we read the section entry wrong?
The following (and attached) is the fix I've been using for this.

Rabin

diff --git a/arm.c b/arm.c
index 5930c02..4e7b6dc 100644
--- a/arm.c
+++ b/arm.c
@@ -957,12 +957,14 @@ arm_vtop(ulong vaddr, ulong *pgd, physaddr_t
*paddr, int verbose)
*** *** *** MKSTR((ulong)page_middle)), pmd_pte);

*** if ((pmd_pte & PMD_TYPE_MASK) == PMD_TYPE_SECT) {
+*** *** ulong sectionbase = pmd_pte & _SECTION_PAGE_MASK;
+
*** *** if (verbose) {
*** *** *** fprintf(fp, " PAGE:
%s* (1MB)

",
*** *** *** *** mkstring(buf, VADDR_PRLEN, RJUST | LONG_HEX,
-*** *** *** *** MKSTR(PAGEBASE(pmd_pte))));
+*** *** *** *** MKSTR(sectionbase)));
*** *** }
-*** *** *paddr = PAGEBASE(pmd_pte) + (vaddr & ~_SECTION_PAGE_MASK);
+*** *** *paddr = sectionbase + (vaddr & ~_SECTION_PAGE_MASK);
*** *** return TRUE;
*** }

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

10-04-2012, 11:45 AM

2012/10/4 paawan oza <paawan1982@yahoo.com>:
> Isn't the problem actually that we read the section entry wrong?
> The following (and attached) is the fix I've been using for this.
>
> Oza: it is not a problem as none of the kernel section level translations
> goes through vtop.

It _is_ a problem from the verbose vtop command output, and that's the
one I see you talking about in your original email, right?

> may in kernel_init part it might be called, but it is a problem only
> if 20th bit set; and while section translation we mask 20th bit.

Looks like there are two problems:

(1) The section translation problem, fixed by my patch
(2) The 20-bit problem, fixed by your patch

Before (all verbose section translations wrong, 20-bit set address
wrong):

crash> vtop 0xc000005c | grep PAGE:
PAGE: 11000 (1MB)
crash> vtop 0xc010005c | grep PAGE:
PAGE: 11000 (1MB)
crash> vtop 0xc020005c | grep PAGE:
PAGE: 211000 (1MB)

With my patch (only 20-bit set address wrong):

crash> vtop 0xc000005c | grep PAGE:
PAGE: 0 (1MB)
crash> vtop 0xc010005c | grep PAGE:
PAGE: 0 (1MB)
crash> vtop 0xc020005c | grep PAGE:
PAGE: 200000 (1MB)

With my patch+your patch (even 20-bit address right):

crash> vtop 0xc000005c | grep PAGE:
PAGE: 0 (1MB)
crash> vtop 0xc010005c | grep PAGE:
PAGE: 100000 (1MB)
crash> vtop 0xc020005c | grep PAGE:
PAGE: 200000 (1MB)

Rabin

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

10-04-2012, 12:12 PM

ok,
Let us wait for Dave and others to comment on it, and try to see how this could be pushed.

Regards,
Oza.

From: Rabin Vincent <rabin@rab.in>
To: paawan oza <paawan1982@yahoo.com>; "Discussion list for crash utility usage, maintenance and development" <crash-utility@redhat.com>
Cc: Thomas Fänge <thomas.fange@sonymobile.com>
Sent: Thursday, 4 October 2012 5:15 PM
Subject: Re: [Crash-utility] using crash for ARM

2012/10/4 paawan oza <paawan1982@yahoo.com>:
> Isn't the problem actually that we read the section entry wrong?
> The following (and attached) is the fix I've been using for this.
>
> Oza: it is not a problem as none of the kernel section level translations
> goes through vtop.

It _is_ a problem from the verbose vtop command output, and that's the
one I see you talking about in your original email, right?

> may in kernel_init part it might be called, but it is a problem only
> if 20th bit set; and while section translation we mask 20th bit.

Looks like there are two problems:

(1) The section translation problem, fixed by my
patch
(2) The 20-bit problem, fixed by your patch

Before (all verbose section translations wrong, 20-bit set address
wrong):

crash> vtop 0xc000005c | grep PAGE:
* PAGE:* * 11000* (1MB)
crash> vtop 0xc010005c | grep PAGE:
* PAGE:* * 11000* (1MB)
crash> vtop 0xc020005c | grep PAGE:
* PAGE:* 211000* (1MB)

With my patch (only 20-bit set address wrong):

crash> vtop 0xc000005c | grep PAGE:
* PAGE:* * * * 0* (1MB)
crash> vtop 0xc010005c | grep PAGE:
* PAGE:* * * * 0* (1MB)
crash> vtop 0xc020005c | grep PAGE:
* PAGE:* 200000* (1MB)

With my patch+your patch (even 20-bit address right):

crash> vtop 0xc000005c | grep PAGE:
* PAGE:* * * * 0* (1MB)
crash> vtop 0xc010005c | grep
PAGE:
* PAGE:* 100000* (1MB)
crash> vtop 0xc020005c | grep PAGE:
* PAGE:* 200000* (1MB)

Rabin

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

10-04-2012, 01:00 PM

----- Original Message -----

> > Paawan, your fix looks sane to me but can you add a small comment describing
> > why this is done?
> >
>
> ok,
> Let us wait for Dave and others to comment on it, and try to see how
> this could be pushed.
>
> Regards,
> Oza.

Oza,

Can you please append your actual patch as Rabin has done? The only
thing that I have from you is this pseudo-code description:

> then I have to do workaround for section level physical addresses as
> follows.
> page_dir = pgd + PGD_OFFSET(vaddr) * 2;
> if (bit(vaddr,20)) //if bit is set then move to the next pgd */
> page_dir = page_dir + 1;
> FILL_PGD(PAGEBASE(pgd), KVADDR, PGDIR_SIZE());
> pgd_pte = ULONG(machdep->pgd + PGDIR_OFFSET(page_dir));
>

Then Mika can decide on how to proceed with the two patches.

Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

10-04-2012, 02:06 PM

I shall provide at the earliest.
Thanks for your response.

Regards,
Oza.

From: Dave Anderson <anderson@redhat.com>
To: paawan oza <paawan1982@yahoo.com>; "Discussion list for crash utility usage, maintenance and development" <crash-utility@redhat.com>
Cc: Thomas Fänge <thomas.fange@sonymobile.com>; Rabin Vincent <rabin@rab.in>; Mika Westerberg <mika.westerberg@iki.fi>;
jan karlsson <jan.karlsson@sonymobile.com>
Sent: Thursday, 4 October 2012 6:30 PM
Subject: Re: [Crash-utility] using crash for ARM

----- Original Message -----

> > Paawan, your fix looks sane to me but can you add a small comment describing
> > why this is done?
> >
>
> ok,
> Let us wait for Dave and others to comment on it, and try to see how
> this could be pushed.
>
> Regards,
> Oza.

Oza,

Can you please append your actual patch as Rabin has done?* The only
thing that I have from you is this pseudo-code description:

> then I have to do workaround for section level physical addresses as
> follows.
> page_dir = pgd + PGD_OFFSET(vaddr) * 2;
> if (bit(vaddr,20)) //if bit is set then move to the
next pgd */
> page_dir = page_dir + 1;
> FILL_PGD(PAGEBASE(pgd), KVADDR, PGDIR_SIZE());
> pgd_pte = ULONG(machdep->pgd + PGDIR_OFFSET(page_dir));
>

Then Mika can decide on how to proceed with the two patches.

Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

10-05-2012, 02:58 AM

On Thu, Oct 04, 2012 at 11:05:07AM +0200, Rabin Vincent wrote:
> 2012/10/4 Mika Westerberg <mika.westerberg@iki.fi>:
> > 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.
>
> Isn't the problem actually that we read the section entry wrong?
> The following (and attached) is the fix I've been using for this.

Yeah, it looks like that part of the code is full of bugs :-/

>
> Rabin
>
> diff --git a/arm.c b/arm.c
> index 5930c02..4e7b6dc 100644
> --- a/arm.c
> +++ b/arm.c
> @@ -957,12 +957,14 @@ arm_vtop(ulong vaddr, ulong *pgd, physaddr_t
> *paddr, int verbose)
> MKSTR((ulong)page_middle)), pmd_pte);
>
> if ((pmd_pte & PMD_TYPE_MASK) == PMD_TYPE_SECT) {
> + ulong sectionbase = pmd_pte & _SECTION_PAGE_MASK;
> +
> if (verbose) {
> fprintf(fp, " PAGE: %s (1MB)

",
> mkstring(buf, VADDR_PRLEN, RJUST | LONG_HEX,
> - MKSTR(PAGEBASE(pmd_pte))));
> + MKSTR(sectionbase)));
> }
> - *paddr = PAGEBASE(pmd_pte) + (vaddr & ~_SECTION_PAGE_MASK);
> + *paddr = sectionbase + (vaddr & ~_SECTION_PAGE_MASK);
> return TRUE;
> }

Ack for this patch.

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

10-05-2012, 05:50 AM

Hi,

please find the patch below.

--- arm.c****** 2012-06-29
20:29:18.000000000 +0530

+++ arm_section.c****** 2012-10-04
19:49:01.166889000 +0530

@@ -932,6 +932,13 @@

******** */

******* page_dir = pgd +
PGD_OFFSET(vaddr) * 2;

*

+****** /* 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 (((vaddr)
>> (20)) & 1)

+**************
page_dir = page_dir + 1;

*******
FILL_PGD(PAGEBASE(pgd), KVADDR, PGDIR_SIZE());

******* pgd_pte =
ULONG(machdep->pgd + PGDIR_OFFSET(page_dir));

Regards,Oza.
From: Dave Anderson <anderson@redhat.com>
To: paawan oza <paawan1982@yahoo.com>; "Discussion list for crash utility usage, maintenance and development" <crash-utility@redhat.com>
Cc: Thomas Fänge <thomas.fange@sonymobile.com>; Rabin Vincent <rabin@rab.in>; Mika Westerberg <mika.westerberg@iki.fi>; jan karlsson <jan.karlsson@sonymobile.com>
Sent: Thursday, 4 October 2012 6:30 PM
Subject: Re: [Crash-utility] using crash for ARM

----- Original Message -----

> > Paawan, your fix looks sane to me but can you add a small comment describing
> > why this is done?
> >
>
> ok,
> Let us wait for Dave and others to comment on it, and try to see how
> this could be pushed.
>
> Regards,
> Oza.

Oza,

Can you please append your actual patch as Rabin has done?* The only
thing that I have from you is this pseudo-code description:

> then I have to do workaround for section level physical addresses as
> follows.
> page_dir = pgd + PGD_OFFSET(vaddr) * 2;
> if (bit(vaddr,20)) //if bit is set then move to the next pgd */
> page_dir = page_dir + 1;
> FILL_PGD(PAGEBASE(pgd), KVADDR, PGDIR_SIZE());
> pgd_pte = ULONG(machdep->pgd +
PGDIR_OFFSET(page_dir));
>

Then Mika can decide on how to proceed with the two patches.

Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

10-05-2012, 06:05 AM

Hi
*
I have tested both this patch and the patch by Rabin and they are OK for me. The patches fixes the identified problems and I have not found any unwanted consequences from the patches.
*
Jan
*
Jan Karlsson
Senior Software Engineer
MIB
*
Sony Mobile Communications
Tel: +46703062174
sonymobile.com
*

*
From: paawan oza [mailto

aawan1982@yahoo.com]
Sent: fredag den 5 oktober 2012 07:51
To: Dave Anderson; Discussion list for crash utility usage, maintenance and development
Cc: Fänge, Thomas; Rabin Vincent; Mika Westerberg; Karlsson, Jan
Subject: Re: [Crash-utility] using crash for ARM
*
Hi,

please find the patch below.

--- arm.c****** 2012-06-29 20:29:18.000000000 +0530
+++ arm_section.c****** 2012-10-04 19:49:01.166889000 +0530
@@ -932,6 +932,13 @@
******** */
******* page_dir = pgd + PGD_OFFSET(vaddr) * 2;
*
+****** /* 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 (((vaddr) >> (20)) & 1)
+************** page_dir = page_dir + 1;
******* FILL_PGD(PAGEBASE(pgd), KVADDR, PGDIR_SIZE());
******* pgd_pte = ULONG(machdep->pgd + PGDIR_OFFSET(page_dir));
*
Regards,
Oza.
From: Dave Anderson <anderson@redhat.com>
To: paawan oza <paawan1982@yahoo.com>; "Discussion list for crash utility usage, maintenance and development" <crash-utility@redhat.com>
Cc: Thomas Fänge <thomas.fange@sonymobile.com>; Rabin Vincent <rabin@rab.in>; Mika Westerberg <mika.westerberg@iki.fi>; jan karlsson <jan.karlsson@sonymobile.com>
Sent: Thursday, 4 October 2012 6:30 PM
Subject: Re: [Crash-utility] using crash for ARM

----- Original Message -----

> > Paawan, your fix looks sane to me but can you add a small comment describing
> > why this is done?
> >
>
> ok,
> Let us wait for Dave and others to comment on it, and try to see how
> this could be pushed.
>
> Regards,
> Oza.

Oza,

Can you please append your actual patch as Rabin has done?* The only
thing that I have from you is this pseudo-code description:

> then I have to do workaround for section level physical addresses as
> follows.
> page_dir = pgd + PGD_OFFSET(vaddr) * 2;
> if (bit(vaddr,20)) //if bit is set then move to the next pgd */
> page_dir = page_dir + 1;
> FILL_PGD(PAGEBASE(pgd), KVADDR, PGDIR_SIZE());
> pgd_pte = ULONG(machdep->pgd + PGDIR_OFFSET(page_dir));
>

Then Mika can decide on how to proceed with the two patches.

Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

10-05-2012, 01:22 PM

----- Original Message -----
>
> Hi
>
> I have tested both this patch and the patch by Rabin and they are OK
> for me. The patches fixes the identified problems and I have not
> found any unwanted consequences from the patches.
>
> Jan

They look good to me as well, and since Mika had also ACK'd Oza's patch,
I've queued them both for crash-6.1.1.

Thanks guys,
Dave

>
> Jan Karlsson
> Senior Software Engineer
> MIB
>
> Sony Mobile Communications
> Tel: +46703062174
> sonymobile.com
>
> SONY make.believe
>
>
>
>
>
> From: paawan oza [mailto

aawan1982@yahoo.com]
> Sent: fredag den 5 oktober 2012 07:51
> To: Dave Anderson; Discussion list for crash utility usage,
> maintenance and development
> Cc: Fänge, Thomas; Rabin Vincent; Mika Westerberg; Karlsson, Jan
> Subject: Re: [Crash-utility] using crash for ARM
>
>
>
>
> Hi,
>
> please find the patch below.
>
>
>
>
>
> --- arm.c 2012-06-29 20:29:18.000000000 +0530
>
>
> +++ arm_section.c 2012-10-04 19:49:01.166889000 +0530
>
>
> @@ -932,6 +932,13 @@
>
>
> */
>
>
> page_dir = pgd + PGD_OFFSET(vaddr) * 2;
>
>
>
>
>
> + /* 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 (((vaddr) >> (20)) & 1)
>
>
> + page_dir = page_dir + 1;
>
>
> FILL_PGD(PAGEBASE(pgd), KVADDR, PGDIR_SIZE());
>
>
> pgd_pte = ULONG(machdep->pgd + PGDIR_OFFSET(page_dir));
>
>
>
>
> Regards,
>
>
> Oza.
>
>
>
>
>
>
> From: Dave Anderson < anderson@redhat.com >
> To: paawan oza < paawan1982@yahoo.com >; "Discussion list for crash
> utility usage, maintenance and development" <
> crash-utility@redhat.com >
> Cc: Thomas Fänge < thomas.fange@sonymobile.com >; Rabin Vincent <
> rabin@rab.in >; Mika Westerberg < mika.westerberg@iki.fi >; jan
> karlsson < jan.karlsson@sonymobile.com >
> Sent: Thursday, 4 October 2012 6:30 PM
> Subject: Re: [Crash-utility] using crash for ARM
>
>
>
>
> ----- Original Message -----
>
> > > Paawan, your fix looks sane to me but can you add a small comment
> > > describing
> > > why this is done?
> > >
> >
> > ok,
> > Let us wait for Dave and others to comment on it, and try to see
> > how
> > this could be pushed.
> >
> > Regards,
> > Oza.
>
> Oza,
>
> Can you please append your actual patch as Rabin has done? The only
> thing that I have from you is this pseudo-code description:
>
> > then I have to do workaround for section level physical addresses
> > as
> > follows.
> > page_dir = pgd + PGD_OFFSET(vaddr) * 2;
> > if (bit(vaddr,20)) //if bit is set then move to the next pgd */
> > page_dir = page_dir + 1;
> > FILL_PGD(PAGEBASE(pgd), KVADDR, PGDIR_SIZE());
> > pgd_pte = ULONG(machdep->pgd + PGDIR_OFFSET(page_dir));
> >
>
> Then Mika can decide on how to proceed with the two patches.
>
> Dave
>
>
>
>
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility