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