Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Crash Utility (http://www.linux-archive.org/crash-utility/)
-   -   update vtop (http://www.linux-archive.org/crash-utility/647587-update-vtop.html)

Toshikazu Nakayama 03-22-2012 09:42 AM
update vtop
 
This patch update ppc32 vtop.
- Translate kvaddr for fsl-booke by using TLBCAM setting
- Remove PMD from display because virtual address bit is not assigned
- Fixup displayed PHYSICAL values of fsl-booke PTE format
- Fixup bug for page flags setup which I made previous patch

Updated command images are below.

- kvaddr can be translated by using TLBCAM

crash> sym powerpc_base_platform
c0913024 (S) powerpc_base_platform
crash> vtop c0913024
VIRTUAL PHYSICAL
c0913024 913024

PAGE DIRECTORY: c08d1000
PGD: c08d2810 => 0

TLBCAM[0]: MAS0 MAS1 MAS2 MAS3 MAS7
10000001 c0000900 c0000004 15 0
VIRTUAL RANGE : c0000000 - cfffffff
PHYSICAL RANGE: 0 - fffffff
=> VIRTUAL PHYSICAL TLBCAM-OFFSET
c0913024 913024 9515044

PAGE PHYSICAL MAPPING INDEX CNT FLAGS
d0012260 913000 0 0 1 400

Next,
- vtop won't display PMD
- physical address is not equal to PTE
- FLAGS can be handled well

crash> vtop -c 4145 10000000
VIRTUAL PHYSICAL
10000000 ef448000

PAGE DIRECTORY: e85c4000
PGD: e85c4200 => e873c000
PTE: e873c000 => ef44824020d
PAGE: ef448000

PTE PHYSICAL FLAGS
ef44824020d ef448000 (PRESENT|USER|COHERENT|ACCESSED)

VMA START END FLAGS FILE
ea1d3960 10000000 10af9000 8001875 /tmp/toshi/crash

However, ... could not read vtop'd physical address data from /dev/mem now.

crash> rd -p ef448000
rd: read error: physical address: ef448000 type: "32-bit PHYSADDR"

Although my environment tends to set higher PTE value,
PFN is valid physical scope number, my maximum is 4GB.

crash> log | grep totalpages
On node 0 totalpages: 1048576
crash> eval 1048576
hexadecimal: 100000 (1MB)
decimal: 1048576
octal: 4000000
binary: 00000000000100000000000000000000

Is there any constraint in "rd" or is my "/dev/mem" something wrong?

Thanks,
Toshi

Toshikazu Nakayama (5):
ppc32: add macros for machdep flags about ppc32 pte
ppc32: add special vtop for FSL BOOKE
ppc32: Ignore PMD
ppc32: fixup vtop display items
ppc32: fix page flags setup macro

defs.h | 10 ++++
ppc.c | 162 ++++++++++++++++++++++++++++++++++++++++++++++++++ ++-----------
2 files changed, 143 insertions(+), 29 deletions(-)

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

Dave Anderson 03-22-2012 01:57 PM
update vtop
 
----- Original Message -----
> This patch update ppc32 vtop.
> - Translate kvaddr for fsl-booke by using TLBCAM setting
> - Remove PMD from display because virtual address bit is not assigned
> - Fixup displayed PHYSICAL values of fsl-booke PTE format
> - Fixup bug for page flags setup which I made previous patch
>
> Updated command images are below.
>
> - kvaddr can be translated by using TLBCAM
>
> crash> sym powerpc_base_platform
> c0913024 (S) powerpc_base_platform
> crash> vtop c0913024
> VIRTUAL PHYSICAL
> c0913024 913024
>
> PAGE DIRECTORY: c08d1000
> PGD: c08d2810 => 0
>
> TLBCAM[0]: MAS0 MAS1 MAS2 MAS3 MAS7
> 10000001 c0000900 c0000004 15 0
> VIRTUAL RANGE : c0000000 - cfffffff
> PHYSICAL RANGE: 0 - fffffff
> => VIRTUAL PHYSICAL TLBCAM-OFFSET
> c0913024 913024 9515044
>
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
> d0012260 913000 0 0 1 400
>
> Next,
> - vtop won't display PMD
> - physical address is not equal to PTE
> - FLAGS can be handled well
>
> crash> vtop -c 4145 10000000
> VIRTUAL PHYSICAL
> 10000000 ef448000
>
> PAGE DIRECTORY: e85c4000
> PGD: e85c4200 => e873c000
> PTE: e873c000 => ef44824020d
> PAGE: ef448000
>
> PTE PHYSICAL FLAGS
> ef44824020d ef448000 (PRESENT|USER|COHERENT|ACCESSED)
>
> VMA START END FLAGS FILE
> ea1d3960 10000000 10af9000 8001875 /tmp/toshi/crash
>
> However, ... could not read vtop'd physical address data from /dev/mem now.
>
> crash> rd -p ef448000
> rd: read error: physical address: ef448000 type: "32-bit PHYSADDR"
>
> Although my environment tends to set higher PTE value,
> PFN is valid physical scope number, my maximum is 4GB.
>
> crash> log | grep totalpages
> On node 0 totalpages: 1048576
> crash> eval 1048576
> hexadecimal: 100000 (1MB)
> decimal: 1048576
> octal: 4000000
> binary: 00000000000100000000000000000000
>
> Is there any constraint in "rd" or is my "/dev/mem" something wrong?

Yeah, it sounds like the /dev/mem "high_memory" constraint for 32-bit
architectures. At the top of the kernel's read_mem() function, it calls
valid_phys_addr_range():

static ssize_t read_mem(struct file *file, char __user *buf,
size_t count, loff_t *ppos)
{
unsigned long p = *ppos;
ssize_t read, sz;
char *ptr;

if (!valid_phys_addr_range(p, count))
return -EFAULT;
...

which restricts physical memory access above "high_memory":

static inline int valid_phys_addr_range(unsigned long addr, size_t count)
{
return addr + count <= __pa(high_memory);
}

On a 32-bit machine (at least on x86), high_memory is going to be no higher
than (1GB-128MB) or 896MB, because it needs the upper 128MB of kernel
virtual address space for vmalloc() and FIXMAP-type addresses.

You might try using /proc/kcore instead of /dev/mem, although I can't
recall if there would be other issues using it on a 32-bit architecture.
Enter "crash /proc/kcore" and see what happens...

Or try building the crash utility's "memory driver" kernel module that
comes with the crash sources:

$ tar xvzmf crash-6.0.4.tar.gz
...
$ cd crash-6.0.4/memory_driver
$ make
...
$ insmod crash.ko

Then, when invoking the crash utility on the live system, it will check
for the existence of the crash.ko module and use it instead of /dev/mem.
It does not have the high_memory restriction.

Dave


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

Dave Anderson 03-22-2012 07:29 PM
update vtop
 
Toshi,

Your updates for the PPC vtop command are queued for crash-6.0.5.

Thanks,
Dave

----- Original Message -----
>
>
> ----- Original Message -----
> > This patch update ppc32 vtop.
> > - Translate kvaddr for fsl-booke by using TLBCAM setting
> > - Remove PMD from display because virtual address bit is not assigned
> > - Fixup displayed PHYSICAL values of fsl-booke PTE format
> > - Fixup bug for page flags setup which I made previous patch
> >
> > Updated command images are below.
> >
> > - kvaddr can be translated by using TLBCAM
> >
> > crash> sym powerpc_base_platform
> > c0913024 (S) powerpc_base_platform
> > crash> vtop c0913024
> > VIRTUAL PHYSICAL
> > c0913024 913024
> >
> > PAGE DIRECTORY: c08d1000
> > PGD: c08d2810 => 0
> >
> > TLBCAM[0]: MAS0 MAS1 MAS2 MAS3 MAS7
> > 10000001 c0000900 c0000004 15 0
> > VIRTUAL RANGE : c0000000 - cfffffff
> > PHYSICAL RANGE: 0 - fffffff
> > => VIRTUAL PHYSICAL TLBCAM-OFFSET
> > c0913024 913024 9515044
> >
> > PAGE PHYSICAL MAPPING INDEX CNT FLAGS
> > d0012260 913000 0 0 1 400
> >
> > Next,
> > - vtop won't display PMD
> > - physical address is not equal to PTE
> > - FLAGS can be handled well
> >
> > crash> vtop -c 4145 10000000
> > VIRTUAL PHYSICAL
> > 10000000 ef448000
> >
> > PAGE DIRECTORY: e85c4000
> > PGD: e85c4200 => e873c000
> > PTE: e873c000 => ef44824020d
> > PAGE: ef448000
> >
> > PTE PHYSICAL FLAGS
> > ef44824020d ef448000 (PRESENT|USER|COHERENT|ACCESSED)
> >
> > VMA START END FLAGS FILE
> > ea1d3960 10000000 10af9000 8001875 /tmp/toshi/crash

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

Toshikazu Nakayama 03-23-2012 09:11 AM
update vtop
 
(2012/03/22 23:57), Dave Anderson wrote:
>
>
>> However, ... could not read vtop'd physical address data from /dev/mem now.
>>
>> crash> rd -p ef448000
>> rd: read error: physical address: ef448000 type: "32-bit PHYSADDR"
>>
>> Although my environment tends to set higher PTE value,
>> PFN is valid physical scope number, my maximum is 4GB.
>>
>> crash> log | grep totalpages
>> On node 0 totalpages: 1048576
>> crash> eval 1048576
>> hexadecimal: 100000 (1MB)
>> decimal: 1048576
>> octal: 4000000
>> binary: 00000000000100000000000000000000
>>
>> Is there any constraint in "rd" or is my "/dev/mem" something wrong?
>
> Yeah, it sounds like the /dev/mem "high_memory" constraint for 32-bit
> architectures. At the top of the kernel's read_mem() function, it calls
> valid_phys_addr_range():
>
> static ssize_t read_mem(struct file *file, char __user *buf,
> size_t count, loff_t *ppos)
> {
> unsigned long p = *ppos;
> ssize_t read, sz;
> char *ptr;
>
> if (!valid_phys_addr_range(p, count))
> return -EFAULT;
> ...
>
> which restricts physical memory access above "high_memory":
>
> static inline int valid_phys_addr_range(unsigned long addr, size_t count)
> {
> return addr + count<= __pa(high_memory);
> }
>
> On a 32-bit machine (at least on x86), high_memory is going to be no higher
> than (1GB-128MB) or 896MB, because it needs the upper 128MB of kernel
> virtual address space for vmalloc() and FIXMAP-type addresses.

Thanks for explanation, I don't have to worry about it now.

> You might try using /proc/kcore instead of /dev/mem, although I can't
> recall if there would be other issues using it on a 32-bit architecture.
> Enter "crash /proc/kcore" and see what happens...
>
> Or try building the crash utility's "memory driver" kernel module that
> comes with the crash sources:
>
> $ tar xvzmf crash-6.0.4.tar.gz
> ...
> $ cd crash-6.0.4/memory_driver
> $ make
> ...
> $ insmod crash.ko

I tried both ways according to your advises, results are different.
A "memory driver" way definitely got my solution.

[crash /proc/kcore]

crash> vm | grep crash
PID: 1151 TASK: eb31d080 CPU: 6 COMMAND: "crash"
e8a5b3c0 10000000 10af9000 8001875 usr/bin/crash
e8a5b420 10b08000 10b3c000 8101873 usr/bin/crash
crash> vtop -c 1151 10000000
VIRTUAL PHYSICAL
10000000 fdf93000

PAGE DIRECTORY: e8a9c000
PGD: e8a9c200 => ea026000
PTE: ea026000 => fdf9324020d
PAGE: fdf93000

PTE PHYSICAL FLAGS
fdf9324020d fdf93000 (PRESENT|USER|COHERENT|ACCESSED)

VMA START END FLAGS FILE
e8a5b3c0 10000000 10af9000 8001875 usr/bin/crash

PAGE PHYSICAL MAPPING INDEX CNT FLAGS
d1fbf260 fdf93000 ea9a1af4 0 2 8000006c

crash> rd -p fdf93000 4
fdf93000: 00000000 00000000 00000000 00000000 ................

=> I think that while reading /proc/kcore, seek offset base is always
vaddr even if -p option is added to "rd".

- More following up

crash> mod | grep sctp
f99b77fc sctp 208011 (not loaded) [CONFIG_KALLSYMS]
crash> module f99b77fc | head -n 5
struct module {
state = MODULE_STATE_LIVE,
list = {
next = 0xf9b69090,
prev = 0xf99b3a4c

crash> rd -p f99b77fc 4 [using virtual address with -p]
f99b77fc: 00000000 f9b69090 f99b3a4c 73637470 ..........:Lsctp

crash> vtop f99b77fc | head -n 2
VIRTUAL PHYSICAL
f99b77fc ff9937fc

crash> rd -p ff9937fc 4 [using physical address with -p]
ff9937fc: 00000000 00000000 00000000 00000000 ................

[insmod crash.ko, crash /dev/crash]

crash> vm | grep crash
PID: 1238 TASK: ea0fd640 CPU: 2 COMMAND: "crash"
ea5edf60 10000000 10af9000 8001875 usr/bin/crash
ea5ed7e0 10b08000 10b3c000 8101873 usr/bin/crash
crash> vtop -c 1238 10000000
VIRTUAL PHYSICAL
10000000 fdf93000

PAGE DIRECTORY: ea03e000
PGD: ea03e200 => ea6cb000
PTE: ea6cb000 => fdf9324020d
PAGE: fdf93000

PTE PHYSICAL FLAGS
fdf9324020d fdf93000 (PRESENT|USER|COHERENT|ACCESSED)

VMA START END FLAGS FILE
ea5edf60 10000000 10af9000 8001875 usr/bin/crash

PAGE PHYSICAL MAPPING INDEX CNT FLAGS
d1fbf260 fdf93000 ea9a1af4 0 2 8000006c
crash> rd -p fdf93000 4
fdf93000: 7f454c46 01020100 00000000 00000000 .ELF............

=> Looks correct, great!

Thanks,
Toshi.

>
> Then, when invoking the crash utility on the live system, it will check
> for the existence of the crash.ko module and use it instead of /dev/mem.
> It does not have the high_memory restriction.
>
> Dave
>
>
> --
> 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


All times are GMT. The time now is 03:58 AM.

VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.