[PVFS2-developers] return of 64 bit and request encode/decode

[Robert Latham]

Hi
The terrasoft guys reported a problem with pvfs2 on their ppc64
systems, so they gave me an account.  

I built a 64 bit version of pvfs2-server and pvfs2-cp and the server
segfaults when trying to copy Changelog from unix-land to pvfs2 land.
The segfault looks eeriliy similar to Brian's opteron bug:


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 549756086192 (LWP 23652)]
0x0000000010066c40 in PINT_Process_request (req=0x1011d840, mem=0x0,
    rfdata=0x1011e780, result=0x101401c8, mode=1)
    at src/io/description/pint-request.c:215

So we print out the usual suspects:

(gdb) p  req->cur[req->lvl].rq
$3 = (PINT_Request *) 0x1011d090
(gdb) p * req->cur[req->lvl].rq
$4 = {offset = 0, num_ereqs = 1, num_blocks = 0, stride = 1, ub = 1, lb = 0, 
  aggregate_size = 1, num_contig_chunks = 1, depth = 1, num_nested_req = 0, 
  committed = -1, refcount = -1, ereq = 0xffffffa81011d090, 
  sreq = 0xffffffa81011d090}

It looks like ereq and sreq are getting ... i dunno... sign extended?
We already, thanks to Pete's suggestion, zero ereq and sreq before
calling decode_uint32_t.  On a whim I tried zeroing it out with '0L'
instead of plain 0 but with no effect.  

Here's a theory: decode_uint32_t calls bmitoh32, which calls htobmi32,
which on WORDS_BIGENDIAN architectures (like ppc64) calls __bswap_32.
Except we have to in this case worry about all 64 bits, not just 32.

I tried making {en,de}code_PVFS_Request call {en,de}code_uint64_t, but
that didn't help anything.  still get what seem to be these
sign-extended (and invalid) pointers.

==rob

-- 
Rob Latham
Mathematics and Computer Science Division    A215 0178 EA2D B059 8CDF
Argonne National Labs, IL USA                B29D F333 664A 4280 315B