[Crash-utility] is_page_ptr vs. x86_64_kvtop

Bruce Korb bruce.korb at gmail.com
Thu Mar 14 23:38:13 UTC 2013


Hi Dave, et al.,

I have this little problem.  I am trying to get a lustre file system
extension working again.  It used to work, but does no more.
It first calls is_page_ptr(kvaddr, &kpaddr) to convert a virtual
address into a physical address, and then calls:

>    readmem(kpaddr, PHYSADDR, buf, used,
> 	   "trace page data", RETURN_ON_ERROR)

to fetch the bytes.  Updating the release to SLES-11 SP2 causes
this to now fail.  In my debugging of crash/gdb, this:

>   is_page_ptr (addr=18446719884937843744, phys=0x7fffffffd370) at memory.c:11448
>   11448           if (IS_SPARSEMEM()) {
>   (gdb) p/x addr
>   $8 = 0xffffea001cdad420

is about to fail.  However, this:

> crash> gdb x/4xg 0xffffea001cdad420

works just fine.  I've stepped through x_command until it gets to
x86_64_kvtop() where I'm finding the logic a little twisty.
But it pretty clearly does not rely on section_mem_map_addr() stuff.

So, here's my point: this is confusing.  What should I look for
to determine why "is_page_ptr()" is saying 0xffffea001cdad420
is invalid while "x86_64_kvtop()" is saying that it is and its
physical address is 0x87afad420?

> 878             return(readmem(addr, memtype, buf, len,
> (gdb) s
> readmem (addr=0xffffea001cdad420, memtype=0x1, buffer=0x5d85d10, size=0x8, 
>     type=0x945f0a "gdb_readmem_callback", error_handle=0x2) at memory.c:1991
> 
> 0xffffea001cdad420:     PML4 DIRECTORY: ffffffff81623000
> PAGE DIRECTORY: 87fff7067
>    PUD: 87fff7000 => 87fff6067
>    PMD: 87fff6730 => 800000087ae001e3
>   PAGE: 87ae00000  (2MB)
>       PTE         PHYSICAL   FLAGS
> 800000087ae001e3  87ae00000  (PRESENT|RW|ACCESSED|DIRTY|PSE|GLOBAL|NX)
> (gdb) p physpage
> $34 = 0x87afad420

0xffffea001cdad420:     0x0200000000000000      0xffffffff00000001
0xffffea001cdad430:     0x0000000000000000      0x0000000000000000

Help, please?  Thank you!




More information about the Crash-utility mailing list