----- 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility