Re: [Crash-utility] [PATCH 0/5] [ppc32] 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