[Crash-utility] using crash for ARM

[paawan oza]

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 at rab.in>
To: paawan oza <paawan1982 at yahoo.com>; "Discussion list for crash utility usage, maintenance and development" <crash-utility at redhat.com> 
Cc: Thomas Fänge <thomas.fange at sonymobile.com> 
Sent: Thursday, 4 October 2012 5:15 PM
Subject: Re: [Crash-utility] using crash for ARM
 
2012/10/4 paawan oza <paawan1982 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20121004/0ab9e557/attachment.htm>