[ewg] [PATCH] rdma_cm: Use rate from ipoib broadcast when joining ipoib multicast
When joining IPoIB multicast group, use the same rate as in the broadcast group. Otherwise, if rdma_cm creates this group before IPoIB does, it might get a different rate. This will cause IPoIB to fail joining to the same group later on, because IPoIB has a strict rate selection. Signed-off-by: Yossi Etigin --- Vlad, this was accepted by Roland, please add it to OFED as well. Index: b/drivers/infiniband/core/cma.c === --- a/drivers/infiniband/core/cma.c 2009-03-30 19:53:19.0 +0300 +++ b/drivers/infiniband/core/cma.c 2009-03-30 21:38:02.0 +0300 @@ -2726,6 +2726,10 @@ static int cma_join_ib_multicast(struct IB_SA_MCMEMBER_REC_FLOW_LABEL | IB_SA_MCMEMBER_REC_TRAFFIC_CLASS; + if (id_priv->id.ps == RDMA_PS_IPOIB) + comp_mask |= IB_SA_MCMEMBER_REC_RATE | +IB_SA_MCMEMBER_REC_RATE_SELECTOR; + mc->multicast.ib = ib_sa_join_multicast(&sa_client, id_priv->id.device, id_priv->id.port_num, &rec, comp_mask, GFP_KERNEL, ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [PATCH v3] mlx4_ib: Optimize hugetlab pages support
Hi Eli,
I've placed a printk in the new hugetlb function to print n and j.
While running the mckey test (attached in bugzilla), I got j=0, n=1.
Why do you say that the number of pages must cover HUGE_PAGES?
In ib_umem_get, hugetlb is set to 0 only if any of the pages is
not-hugetlb - otherwise it's 1. Am I missing something?
--Yossi
On Thu, 2 Apr 2009, Eli Cohen wrote:
On Mon, Mar 30, 2009 at 06:49:37PM +0300, Yossi Etigin wrote:
Yossi,
I wouldn't expect this to matter since handle_hugetlb_user_mr() only
gets called when the memory is huge pages which means the number of
PAGE_SIZE pages cover full HUGE_PAGES. You mention in Bugzilla an
"mckey" test but I don't know this test. Can you send how to obatain
the test and instructions how to build it and run it?
+
+ if (cur_size) {
+ arr[j++] = cur_addr;
+ }
+
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] NFS-RDMA: Fix page leak
In the conversion from splice_direct_to_actor to sendfile, the callback
routine was converted to the previous version without reference to the
new changes to the callback route that calls the put_page. Previously,
it had been called in svc_release_buffer, but due to significant changes
in the logic of that function it cannot be done there (and this more
closely matches what is in 2.6.28).
This fixes Bugzilla Bug 1574
Signed-Off-By: Jon Mason
diff --git a/kernel_patches/backport/2.6.18-EL5.1/rnfs_fs.patch
b/kernel_patches/backport/2.6.18-EL5.1/rnfs_fs.patch
index 6176bed..5bcc84c 100644
--- a/kernel_patches/backport/2.6.18-EL5.1/rnfs_fs.patch
+++ b/kernel_patches/backport/2.6.18-EL5.1/rnfs_fs.patch
@@ -1660,7 +1660,7 @@ index 80292ff..47eb160 100644
+
+MODULE_LICENSE("Dual BSD/GPL");
diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
-index 18060be..c08b4dc 100644
+index 18060be..becacce 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -23,7 +23,6 @@
@@ -1685,7 +1685,7 @@ index 18060be..c08b4dc 100644
mutex_unlock(&inode->i_mutex);
return err;
-@@ -828,53 +827,33 @@ found:
+@@ -828,53 +827,39 @@ found:
return ra;
}
@@ -1700,17 +1700,17 @@ index 18060be..c08b4dc 100644
+nfsd_read_actor(read_descriptor_t *desc, struct page *page, unsigned long
offset , unsigned long size)
{
- struct svc_rqst *rqstp = sd->u.data;
-- struct page **pp = rqstp->rq_respages + rqstp->rq_resused;
++ unsigned long count = desc->count;
++ struct svc_rqst *rqstp = desc->arg.data;
+ struct page **pp = rqstp->rq_respages + rqstp->rq_resused;
- struct page *page = buf->page;
- size_t size;
- int ret;
-+ unsigned long count = desc->count;
-+ struct svc_rqst *rqstp = desc->arg.data;
-
+-
- ret = buf->ops->confirm(pipe, buf);
- if (unlikely(ret))
- return ret;
--
+
- size = sd->len;
+ if (size > count)
+ size = count;
@@ -1721,15 +1721,17 @@ index 18060be..c08b4dc 100644
- *pp = page;
- rqstp->rq_resused++;
- rqstp->rq_res.page_base = buf->offset;
++ if (*pp)
++ put_page(*pp);
+ rqstp->rq_respages[rqstp->rq_resused++] = page;
+ rqstp->rq_res.page_base = offset;
rqstp->rq_res.page_len = size;
- } else if (page != pp[-1]) {
+ } else if (page != rqstp->rq_respages[rqstp->rq_resused-1]) {
get_page(page);
-- if (*pp)
-- put_page(*pp);
-- *pp = page;
+ if (*pp)
+ put_page(*pp);
+ *pp = page;
- rqstp->rq_resused++;
+ rqstp->rq_respages[rqstp->rq_resused++] = page;
rqstp->rq_res.page_len += size;
@@ -1752,7 +1754,7 @@ index 18060be..c08b4dc 100644
static inline int svc_msnfs(struct svc_fh *ffhp)
{
#ifdef MSNFS
-@@ -895,7 +874,7 @@ nfsd_vfs_read(struct svc_rqst *rqstp, struct svc_fh *fhp,
struct file *file,
+@@ -895,7 +880,7 @@ nfsd_vfs_read(struct svc_rqst *rqstp, struct svc_fh *fhp,
struct file *file,
int host_err;
err = nfserr_perm;
@@ -1761,7 +1763,7 @@ index 18060be..c08b4dc 100644
if (svc_msnfs(fhp) && !lock_may_read(inode, offset, *count))
goto out;
-@@ -906,16 +885,9 @@ nfsd_vfs_read(struct svc_rqst *rqstp, struct svc_fh *fhp,
struct file *file,
+@@ -906,16 +891,9 @@ nfsd_vfs_read(struct svc_rqst *rqstp, struct svc_fh *fhp,
struct file *file,
if (ra && ra->p_set)
file->f_ra = ra->p_ra;
@@ -1780,7 +1782,7 @@ index 18060be..c08b4dc 100644
} else {
oldfs = get_fs();
set_fs(KERNEL_DS);
-@@ -937,7 +909,7 @@ nfsd_vfs_read(struct svc_rqst *rqstp, struct svc_fh *fhp,
struct file *file,
+@@ -937,7 +915,7 @@ nfsd_vfs_read(struct svc_rqst *rqstp, struct svc_fh *fhp,
struct file *file,
nfsdstats.io_read += host_err;
*count = host_err;
err = 0;
@@ -1789,7 +1791,7 @@ index 18060be..c08b4dc 100644
} else
err = nfserrno(host_err);
out:
-@@ -971,11 +943,11 @@ nfsd_vfs_write(struct svc_rqst *rqstp, struct svc_fh
*fhp, struct file *file,
+@@ -971,11 +949,11 @@ nfsd_vfs_write(struct svc_rqst *rqstp, struct svc_fh
*fhp, struct file *file,
err = nfserr_perm;
if ((fhp->fh_export->ex_flags & NFSEXP_MSNFS) &&
@@ -1803,7 +1805,7 @@ index 18060be..c08b4dc 100644
inode = dentry->d_inode;
exp = fhp->fh_export;
-@@ -1004,7 +976,7 @@ nfsd_vfs_write(struct svc_rqst *rqstp, struct svc_fh
*fhp, struct file *file,
+@@ -1004,7 +982,7 @@ nfsd_vfs_write(struct svc_rqst *rqstp, struct svc_fh
*fhp, struct file *file,
set_fs(oldfs);
if (host_err >= 0) {
nfsdstats.io_write += cnt;
diff --git a/kernel_patches/backport/2.6.18-EL5.2/rnfs_fs.patch
b/kernel_patches/backport/
[ewg] compile failure on SLES11 in NFS
Hi everybody, with the latest daily build (OFED-1.4.1-20090402-0600) I'm getting the compile problem below. I'm running SLES11 on a powerpc box. Could someone take a look at this? Appreciate your help! Alex -Iarch/powerpc -I/var/tmp/OFED_topdir/BUILD/ofa_kernel-1.4.1/fs/nfs -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Os -msoft-float -pipe -I/usr/src/linux-2.6.27.19-5/arch/powerpc -Iarch/powerpc -mminimal-toc -mtraceback=none -mcall-aixdesc -mcpu=power4 -mtune=cell -mno-altivec -mno-spe -funit-at-a-time -mno-string -Wa,-maltivec -fno-stack-protector -fomit-frame-pointer -g -Wdeclaration-after-statement -Wno-pointer-sign -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(file)" -D"KBUILD_MODNAME=KBUILD_STR(nfs)" -D"DEBUG_HASH=3" -D"DEBUG_HASH2=61" -c -o /var/tmp/OFED_topdir/BUILD/ofa_kernel-1.4.1/fs/nfs/.tmp_file.o /var/tmp/OFED_topdir/BUILD/ofa_kernel-1.4.1/fs/nfs/file.c /var/tmp/OFED_topdir/BUILD/ofa_kernel-1.4.1/fs/nfs/file.c: In function ‘nfs_write_begin’: /var/tmp/OFED_topdir/BUILD/ofa_kernel-1.4.1/fs/nfs/file.c:354: error: implicit declaration of function ‘__grab_cache_page’ /var/tmp/OFED_topdir/BUILD/ofa_kernel-1.4.1/fs/nfs/file.c:354: warning: assignment makes pointer from integer without a cast make[5]: *** [/var/tmp/OFED_topdir/BUILD/ofa_kernel-1.4.1/fs/nfs/file.o] Error 1 make[4]: *** [/var/tmp/OFED_topdir/BUILD/ofa_kernel-1.4.1/fs/nfs] Error 2 make[3]: *** [_module_/var/tmp/OFED_topdir/BUILD/ofa_kernel-1.4.1] Error 2 make[2]: *** [sub-make] Error 2 make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.27.19-5-obj/ppc64/ppc64' make: *** [kernel] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.24575 (%build) ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] OFED 1.4.1-rc3 is delayed for next Monday - Apr 4
Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [PATCH] ofed_1_4_scripts: Fix ppc64 building of rnfs-utils
On Wed, 1 Apr 2009 11:02:03 -0500 Jon Mason wrote: > On Wed, Apr 01, 2009 at 10:39:30AM +0200, Alexander Schmidt wrote: > > On Mon, 30 Mar 2009 17:35:58 -0500 > > Jon Mason wrote: > > > > > On Mon, Mar 30, 2009 at 11:25:53AM +0200, Alexander Schmidt wrote: > > > > On Fri, 27 Mar 2009 14:52:27 -0500 > > > > Jon Mason wrote: > > > > > > > > > rnfs-utils will not build on ppc64 without a 32bit version of > > > > > e2fsprogs-devel. The 32bit version is needed due to logic previously > > > > > added to install.pl to force the compile to be 32bit. Another way to > > > > > fix this issue would be to allow 64bit version of the rnfs-utils by > > > > > removing the logic which forces it to be 32bit. > > > > > > > > > > With the added dependency, rnfs-utils compiles on RHEL5.2 on ppc64 > > > > > without issue. > > > > > > > > > > Thanks, > > > > > Jon > > > > > > > > Hi Jon, > > > > > > > > thanks for the patch, it also works fine on RHEL5.3 now. > > > > > > > > I've also tried to install the rnfs-utils package on SLES11, and there > > > > I run > > > > into another problem. The SRPM has the following dependencies: > > > > > > Thanks for testing this on non-RHEL installs. > > > > > > > > > > > [alexs...@bl3d1974 SRPMS]$ rpm -qpR rnfs-utils-1.1.5-rc1.OFED.src.rpm > > > > krb5-devel >= 1.3.1 > > > > autoconf >= 2.57 > > > > automake > > > > krb5-devel > > > > libtool > > > > krb5-libs > > > > rpmlib(CompressedFileNames) <= 3.0.4-1 > > > > > > > > I've created the patch below for teaching the installer that rnfs-utils > > > > needs > > > > the krb5 packages. But on SLES10 & 11, there is no krb5-libs package, > > > > so it's > > > > not possible to install rnfs-utils. Could you try to fix this? > > > > > > I think the name of the package on SuSE is krb5 or krb5-server. I've > > > attached a SRPM to this e-mail without the krb5-libs dependency. See if > > > the package fixes any configure issues you could/will hit when trying to > > > compile rnfs-utils. You should be able to copy the SRPM over the one in > > > the OFED tree and it will build as it would normally. > > > > > > > Hi Jon, > > > > after installing the tcpd-devel (for libwrap) and krb5 packages I was able > > to > > build an RPM from the SRPM you attached. This RPM has a dependency on > > nfs-utils, > > which does not exist on SLES11... Seems like they have split the package > > up?! > > > > Could you take care of this so that we get a clean install on SLES11? > > I removed the distro specific dependencies from the SRPM and added them > to the install.pl for OFED. I will submit the relevant patch to > install.pl shortly. > > You can get the SRPM of rnfs-utils without the nfs-utils dependency at: > http://www.openfabrics.org/~swise/ofed_1_4/rnfs-utils/ > > Thanks for the testing and let me know if you hit anymore problems. On SLES11 with the rnfs-utils-1.1.5-1.OFED.src.rpm rpm I now get Installation finished successfully. Thanks, Alex ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Moving to new server
On Sun, 29 Mar 2009 21:38:54 -0500 Steve Wise wrote: > Jeff Becker wrote: > > Hi Sasha > > > > Sasha Khapyorsky wrote: > >> Hi Jeff, > >> > >> On 16:24 Fri 27 Mar , Jeff Becker wrote: > >> > >>> Just thought this would be a good chance to clean up. > >>> > >> > >> Thanks for your work. > >> > >> I copied my trees and basically it works. Few things are missing: > >> > >> 1. ~username symbolic links under /pub/scm. So things like: > >> > >> git clone git://69.55.231.68/~sashak/management > >> > >> , don't work yet. > >> > >> 2. Mail server (guess postfix) is not configured and mailx is not > >> installed - both can be useful (and was used on current server) for > >> git commit notification. > >> > >> 3. No gitweb yet. > >> > > > > I plan on setting these up after a good number of developers have > > moved their git trees - just a handful right now. Thanks. > > > Can you setup the /pub/scm/~username links now so we can use the new > server now that we've moved our git trees over? I would also like to get one of these links so that I can test a remote checkout of the tree, the libehca git has now been moved to /home/alexschm/scm/libehca.git In addition, could someone set my default shell to /bin/bash? /bin/sh is a bit limited and I don't want to execute bash everytime I log in ;) Thanks, Alex ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [PATCH v3] mlx4_ib: Optimize hugetlab pages support
On Thu, Apr 02, 2009 at 11:47:26AM +0300, Or Gerlitz wrote: > mckey is installed with librdmac-utils, has man page, etc. Its source is > under the examples directory of the librdmacm src tree, you can clone > Sean's librdmacm git from ofa to get it - OK? > Thanks Or. I will check this. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [PATCH v3] mlx4_ib: Optimize hugetlab pages support
Eli Cohen wrote: You mention in Bugzilla an "mckey" test but I don't know this test. Can you send how to obatain the test and instructions how to build it and run it? Eli, mckey is installed with librdmac-utils, has man page, etc. Its source is under the examples directory of the librdmacm src tree, you can clone Sean's librdmacm git from ofa to get it - OK? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [PATCH v3] mlx4_ib: Optimize hugetlab pages support
On Mon, Mar 30, 2009 at 06:49:37PM +0300, Yossi Etigin wrote:
Yossi,
I wouldn't expect this to matter since handle_hugetlb_user_mr() only
gets called when the memory is huge pages which means the number of
PAGE_SIZE pages cover full HUGE_PAGES. You mention in Bugzilla an
"mckey" test but I don't know this test. Can you send how to obatain
the test and instructions how to build it and run it?
> +
> + if (cur_size) {
> + arr[j++] = cur_addr;
> + }
> +
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
