[Crash-utility] [PATCH 0/5] [ppc32] update vtop

[Toshikazu Nakayama]

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