5:11 a.m.
(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(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility