Hi all,
No one replied the the original post. The one I am most curious about
is (3). Is FlowBufferSizeBytes available to the BMI implementations?
I am thinking about how to handle BMI_mx_memalloc(). I might be able
to assist the reg cache in MX if I do things a certain way.
Scott
On
I was able to get the client finally built and mounted this morning for
2.6.0-cvs, and ran across this
problem whenever trying to write/read through the vfs to the mount:
*I'm running a biarch debian-ppc64 setup on the client, which has worked
in the past on 2.5-cvs.
On Nov 30, 2006, at 9:27 AM, Scott Atchley wrote:
Hi all,
No one replied the the original post. The one I am most curious
about is (3). Is FlowBufferSizeBytes available to the BMI
implementations?
Hi Scott,
Sorry for not responding. I've included responses to your questions
Hi Kyle,
I don't have a fix for your problem yet, but I think the message
about Please make sure that the pvfs2-client is running is
erroneous. The real error is the pvfs_bufmap_copy_iovec_from_user
error.
Also, did you pull from CVS using the pvfs-2-6-0 release tag? If
not, the
Hi guys,
drat..there have been so many bugs in the bufmap.c code lately.
This must be some data type overflow or something..
Can you try the attached patch and see if it helps..
As an aside,
how do we make gcc complain if types don't match perfectly?
I am surprised how a size_t* and a ssize_t *
On Nov 30, 2006, at 11:40 AM, Sam Lang wrote:
Hi Kyle,
I don't have a fix for your problem yet, but I think the message
about Please make sure that the pvfs2-client is running is
erroneous. The real error is the pvfs_bufmap_copy_iovec_from_user
error.
I'll look at this tomorrow and
On Nov 30, 2006, at 2:30 PM, Sam Lang wrote:
I mention this below, on the server we always call BMI_memalloc
to allocate buffers and post them to BMI_post_send/
BMI_post_recv. On the client that's not always the case, the
user buffer is usually passed directly to BMI_post_send/
Hi Murali,
I think you're on the right track, it looks like its a casting
problem from int to long, but the bug appears to be in the nr_segs
parameter passed to wait_for_io and then copy_iovec_from_user. The
attached patch fixes the error, as well as changes all the unsigned
long
woops. Sorry about that.
-sam
ppc64-slang-fixes.patch
Description: Binary data
On Nov 30, 2006, at 5:52 PM, Sam Lang wrote:
Hi Murali,
I think you're on the right track, it looks like its a casting
problem from int to long, but the bug appears to be in the nr_segs
parameter
