[ewg] RE: [ofa-general] [ANNOUCE] dapl 2.0.5 release
Arlin: I have not had a chance to look at uDAPL 2.0, can you give a brief summary the changes from 1.2 to 2.0, I am interested from the applications perspective, don't care the internal details. Thanks. --CQ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arlin Davis Sent: Tuesday, January 29, 2008 6:58 PM To: OpenFabrics General; EWG Cc: Lentini, James; 'Vladimir Sokolovsky' Subject: [ofa-general] [ANNOUCE] dapl 2.0.5 release There is new release for dapl 2.0 available on the OFA download page and in my git tree. Changes to allow both v1 and v2 development packages to be installed on the same system. v2 libdat.so has been renamed to libdat2.so. md5sum: 010459e421a5c194438d58b1ccf1c6d0 dapl-2.0.5.tar.gz Vlad, please pull new v2 release into OFED 1.3 RC3 and install the following packages: Note: please make sure dapl-1.2.4-devel is added to list. dapl-1.2.4-1 dapl-devel-1.2.4-1 dapl-2.0.5-1 dapl-utils-2.0.5-1 dapl-devel-2.0.5-1 dapl-debuginfo-2.0.5-1 See http://www.openfabrics.org/downloads/dapl/README.htmlhttp://www.openfabrics.org/downloads/dapl/README.html> for details. -arlin ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [ANNOUCE] dapl 2.0.5 release
There is new release for dapl 2.0 available on the OFA download page and in my git tree. Changes to allow both v1 and v2 development packages to be installed on the same system. v2 libdat.so has been renamed to libdat2.so. md5sum: 010459e421a5c194438d58b1ccf1c6d0 dapl-2.0.5.tar.gz Vlad, please pull new v2 release into OFED 1.3 RC3 and install the following packages: Note: please make sure dapl-1.2.4-devel is added to list. dapl-1.2.4-1 dapl-devel-1.2.4-1 dapl-2.0.5-1 dapl-utils-2.0.5-1 dapl-devel-2.0.5-1 dapl-debuginfo-2.0.5-1 See http://www.openfabrics.org/downloads/dapl/README.html> http://www.openfabrics.org/downloads/dapl/README.html for details. -arlin ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Chatting online
Hello! I am tired today. I am nice girl that would like to chat with you. Email me at [EMAIL PROTECTED] only, because I am using my friend's email to write this. I will show you some great pictures of me. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3 readiness
On Tue, 2008-01-29 at 14:21 +0200, Tziporet Koren wrote: > OFED Jan 28 meeting summary on RC3 readiness: > = > > 1. OFED 1.3 readiness toward RC3 this week > > * RC3 is based on the official 2.6.24 release > * RC3 is expected on Wed > * RC4 is planned for Feb 13 > > > 2. All companies update: > > * IBM - ready for RC3 > * Voltaire - ready for RC3 > * Qlogic - ready for RC3; will work on bug 874 > * Intel - things looks good. Need some uDAPL update from > Arlin > * Chelsio - ready for RC3 > * NetEffect - ready for RC3 > * Cisco - reported all issues in bugzilla > * Mellanox - ready for RC3 > * MPI - all packages are ready > > > 3. Request to change IPoIB to support CM without SRQ and 4K MTU > > Decided that we cannot insert such enhancements at this stage > (RC3 built today) without delaying the release since IPoIB is > a critical ULP used by all customers. > > Since we do not want to delay the release and we wish to have > a solution for the new IPoIB enhancements we plan to have > 1.3.1 release Hmmm...I'd like to put my $.02 in here. I don't have any visibility into what drives the OFED schedule, so I have no clue as to why people don't want to slip the schedule for this change. I'm sure you guys have your reasons. However, I also happen to be a consumer of this code, and I know for a fact that no one has gotten my input on this issue. So, the deal is that I'm currently integrating OFED 1.3 into what will be RHEL5.2. The RHEL5.2 freeze date has already passed, but in order to keep what finally goes out from being too stale, I'm being allowed to submit the OFED-1.3-rc1 code prior to freeze, and then update to OFED-1.3 final during our beta test process. What this means, is that anything you punt from 1.3 to 1.3.1, you are also punting out of RHEL5.2 and RHEL4.7. So, that being said, there's a whole trickle down effect with various groups that would really like to be able to use 5.2 out of the box that may prefer a slip in 1.3 so that this can be part of it instead of punting to 1.3.1. I'm not saying this will change your mind, but I'm sure it wasn't part of the decision process before, so I'm bringing it up. > AIs: > Tziporet to define the 1.3.1 release (scope of changes, > schedule etc.) > Vlad: open 1_3_1 branch so people will have a place to commit > changes. We will not start any daily build before 1.3 release > > > 3. Review high priority bugs: > 846 critical[EMAIL PROTECTED]SDP crash on RHEL5 > ppc64 running netserver - will be debugged > > 859 critical[EMAIL PROTECTED] Bonding configuration > on Sles10 sp1 is not loaded consistently - fixed > 863 critical[EMAIL PROTECTED] ib-bonding won't > compile for RHEL4 U6 - fixed > 874 critical[EMAIL PROTECTED] Intel MPI (IMB test) > hangs intermittently on the qlogic HCA - will be debugged by > Qlogic > > 760 major [EMAIL PROTECTED] UDP performance on Rx is lower > than Tx - for 1.3.1 > 761 major [EMAIL PROTECTED] Poor and jittery UDP > performance at small messages - for 1.3.1 Ditto for requesting these two be in 1.3. We've already had customers bring up the UDP performance issue in our previous releases. > 869 major [EMAIL PROTECTED]mstflint won't build > on SLES10 x86 - fixed > 736 major [EMAIL PROTECTED] IBV_WC_RETRY_EXC_ERR errors > with local rdma_reads - seems a FW issue (Mellanox to > debug) > > 767 major [EMAIL PROTECTED] Non backport Kernels > that don't build in genalloc cause compile errors for cxgb3 - no fix > (document) And we still need to get actual downloads for a number of the srpms in OFED-1.3. The various spec files list fictitious tarballs that aren't actually available on the download server. While that works for the rcs, they really need to have a tarball up there for final. -- Doug Ledford <[EMAIL PROTECTED]> GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband signature.asc Description: This is a digitally signed message part ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Ibutils does not compile in todays daily build
Woody, On Tue, 2008-01-29 at 11:52 -0800, Woodruff, Robert J wrote: > I get the following compile error on Redhat EL 5.1 > compiling ibutils on today's daily build. > > woody > > gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include > -I/usr/include/infiniband -I/usr/include -DOSM_VENDOR_INTF_OPENIB > -DOSM_BUILD_OPENIB -D_XOPEN_SOURCE=600 -D_BSD_SOURCE=1 -O2 -Wall > -fno-strict-aliasing -fPIC -DIBIS_VERSION=\"1.2\" -O2 -g -pipe -Wall > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -MT ibbbm.lo -MD -MP -MF .deps/ibbbm.Tpo -c > ibbbm.c -fPIC -DPIC -o .libs/ibbbm.o > ibbbm.c: In function '__ibbbm_vpd': > ibbbm.c:229: error: 'struct _gsi' has no member named 'pkey' > make[3]: *** [ibbbm.lo] Error 1 > make[3]: Leaving directory > `/var/tmp/OFED_topdir/BUILD/ibutils-1.2/ibis/src' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/var/tmp/OFED_topdir/BUILD/ibutils-1.2/ibis' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/var/tmp/OFED_topdir/BUILD/ibutils-1.2/ibis' > make: *** [all-recursive] Error 1 > error: Bad exit status from /var/tmp/rpm-tmp.99447 (%build) There're a couple of outstanding patches Sasha has supplied to Oren for this which have not been integrated as yet. -- Hal > > > RPM build errors: > user vlad does not exist - using root > ___ > ewg mailing list > ewg@lists.openfabrics.org > 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] Ibutils does not compile in todays daily build
I get the following compile error on Redhat EL 5.1 compiling ibutils on today's daily build. woody gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include -I/usr/include/infiniband -I/usr/include -DOSM_VENDOR_INTF_OPENIB -DOSM_BUILD_OPENIB -D_XOPEN_SOURCE=600 -D_BSD_SOURCE=1 -O2 -Wall -fno-strict-aliasing -fPIC -DIBIS_VERSION=\"1.2\" -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -MT ibbbm.lo -MD -MP -MF .deps/ibbbm.Tpo -c ibbbm.c -fPIC -DPIC -o .libs/ibbbm.o ibbbm.c: In function '__ibbbm_vpd': ibbbm.c:229: error: 'struct _gsi' has no member named 'pkey' make[3]: *** [ibbbm.lo] Error 1 make[3]: Leaving directory `/var/tmp/OFED_topdir/BUILD/ibutils-1.2/ibis/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/OFED_topdir/BUILD/ibutils-1.2/ibis' make[1]: *** [all] Error 2 make[1]: Leaving directory `/var/tmp/OFED_topdir/BUILD/ibutils-1.2/ibis' make: *** [all-recursive] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.99447 (%build) RPM build errors: user vlad does not exist - using root ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] IB/IPoIB Check if grat. ARP changed had arrived when working in connected mode
Moni Shoua wrote: move a little up the code that checks for a situation where the remote GID stored in the ipoib_neigh is different than the one present in the neighbour (handle Gratuitous ARP) or that a bonding fail over has happened but the neighbour still has a pointer to an ipoib_neigh created not by the current slave. This will cause the driver to apply the check also for connected mode neighbours. This patch was tested against upstream kernel and ofed_kernel. Signed-off-by: Or Gerlitz <[EMAIL PROTECTED]> Signed-off-by: Moni Shoua <[EMAIL PROTECTED]> Applied, Regards, Vladimir ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [Scst-devel] [ofa-general] OFED 1.3 RC2 release is available
Bart Van Assche wrote: On Jan 28, 2008 12:47 PM, Vladislav Bolkhovitin <[EMAIL PROTECTED]> wrote: Bart Van Assche wrote: Apparently OFED 1.3 includes SRP target support ? Although I consider SRP target support as a very valuable contribution, it should not be included in the OFED distribution but in the SCST distribution. The reason is that the SRP target relies on SCST interfaces that can potentially change with each new SCST release. Consider e.g. the scsi_tgt.h header file, which defines the interface between SCST core and SCST mid-level modules. The version of this file included with git://git.openfabrics.org/~vu/ofed_1_3.git (0.9.6-pre3) is incompatible with the latest scsi_tgt.h file from the SCST project (0.9.6-rc1). This may cause kernel crashes for OFED 1.3 SRP target users who combine OFED 1.3 with the latest SCST version. No it won't crash, it will refuse to run. I've recently added in SCST protection against attempts running mixed SCST and target driver versions. BTW, there is a *!!* *!! !!* *!! BIG FAT WARNING ABOUT MIXED VERSIONS PROBLEM !!* *!! !!* *!!* Hello Vladislav, I did not test the above scenario -- what I wrote was the result of source reading. It is very good that interface versions are checked inside SCST before mid-level drivers are used. Even with interface version checking in place, my opinion is that the SRP target code should be included in the SCST project and not in the OFED project. Bart. Hi Bart, On srpt readme file, the prerequisite is install SCST BEFORE ofed-1.3 or like Vlad warning "recompiling ofed" if you install scst after install ofed. here is one of the reason srpt is part of ofed not scst: SCST is GPL ofed + srpt is GPL or BSD -vu ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Trivial patch to fix compile error for OFED 1.3
This is a trivial fix to fix a compile error when Connected Mode is
not defined. This patch is upstream:
http://lkml.org/lkml/2008/1/16/287
Please include this in OFED 1.3
Signed-off-by: Pradeep Satyanarayana <[EMAIL PROTECTED]>
---
--- a/drivers/infiniband/ulp/ipoib/ipoib.h 2008-01-23 16:29:06.0
-0500
+++ b/drivers/infiniband/ulp/ipoib/ipoib.h 2008-01-29 11:03:32.0
-0500
@@ -493,6 +493,12 @@ static inline void ipoib_cm_set(struct i
neigh->cm = tx;
}
+static inline unsigned int ipoib_cm_max_mtu(struct net_device *dev)
+{
+ struct ipoib_dev_priv *priv = netdev_priv(dev);
+ return priv->cm.max_cm_mtu;
+}
+
void ipoib_cm_send(struct net_device *dev, struct sk_buff *skb, struct
ipoib_cm_tx *tx);
int ipoib_cm_dev_open(struct net_device *dev);
void ipoib_cm_dev_stop(struct net_device *dev);
@@ -535,6 +541,11 @@ static inline void ipoib_cm_set(struct i
{
}
+static inline unsigned int ipoib_cm_max_mtu(struct net_device *dev)
+{
+ return 0;
+}
+
static inline
void ipoib_cm_send(struct net_device *dev, struct sk_buff *skb, struct
ipoib_cm_tx *tx)
{
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c 2008-01-23 16:29:06.0
-0500
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c 2008-01-29 11:04:00.0
-0500
@@ -183,7 +183,7 @@ static int ipoib_change_mtu(struct net_d
/* dev->mtu > 2K ==> connected mode */
if (ipoib_cm_admin_enabled(dev)) {
- if (new_mtu > priv->cm.max_cm_mtu)
+ if (new_mtu > ipoib_cm_max_mtu(dev))
return -EINVAL;
if (new_mtu > priv->mcast_mtu)
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] cxgb3 release note changes for ofed-1.3.
Steve Wise wrote: From: Steve Wise <[EMAIL PROTECTED]> Signed-off-by: Steve Wise <[EMAIL PROTECTED]> applied Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] All patches that should go to OFED 1.3 RC3 should be posted today
Steve Wise wrote: BTW: The HOWTO.build_ofed file is still based on 1.2. Thanks - fixed Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH/ docs ofed-1.3 ] Add ib-bonding documentation
Moni Shoua wrote: * Move ib-bonding.txt from ib-bonding RPM to here. * Add more notes for the ib-bonding section in ipoib_release_notes.txt applied Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] OFED 1.2.5.5 is ready on the ofa server
OFED-1.2.5.5 is ready: http://www.openfabrics.org/downloads/OFED/ofed-1.2.5/OFED-1.2.5.5.tgz Supported Platforms and Operating Systems = o CPU architectures: - x86_64 - x86 - ppc64 - ia64 o Linux Operating Systems: - RedHat EL4 up3: 2.6.9-34.ELsmp - RedHat EL4 up4: 2.6.9-42.ELsmp - RedHat EL4 up5: 2.6.9-55.ELsmp - RedHat EL4 up6: 2.6.9-67.ELsmp * - RedHat EL5: 2.6.18-8.el5 - RedHat EL5 up1: 2.6.18-53.el5 - Fedora C6:2.6.18-8.fc6 * - SLES9 SP3:2.6.5-7.244-smp * - SLES9 SP4:2.6.5-7.305-smp * - SLES10: 2.6.16.21-0.8-smp - SLES10 SP1: 2.6.16.46-0.12-smp - SLES10 SP1 up1: 2.6.16.46-0.12-smp - SUSE Pro 10.0:2.6.13-16-smp * - kernel.org: 2.6.20.x and 2.6.22.x * OSes that are partially tested Fixed Bugs and Enhancements Since OFED 1.2.5.4 == - OSes support: - added support for RHEL5 up1 - Added support for RHEL4 up6 - Added support for SLES9 SP4 on PPC64 - Low level drivers update: - cxgb3: - Flush the receive queue when closing - Fix page shift calculation in build_phys_page_list() - Mark QP as privileged based on user capabilities - Fix the T3A workaround checks - Pull in latest fixes. - mlx4: - For write-combining copies, a tight "for" loop instead of memcpy. - Fix the value of the pkey_index in the completion to get a valid value for GSI QPs. - Changed mlx4 driver default to be MSI-X - IPoIB: - Fix issue when RC QP is closed (due to RNR NAK) - CMA: - Bug fix on connection tear-down (enables RDS to download when removing low level driver) - RDS: - Fixed a bug of uninitialized variable in RDS-tools. - OpenSM: - Fixed coredump that might occur when switch ports are disconnecting and reconnecting quickly. Fixed Bugs and Enhancements OFED 1.2.5: === - OSes support: - Added support for SLES9 SP4 - Low level drivers update: - cxgb3: Pull in latest fixes. - ipath: Pull in latest fixes. - RDS: - Performance enhancements - Relax the header consistency check on fragment reassembly - GA for Oracle 11 - IPoIB: - Use NAPI by default - For small received packets, allocate a new, smaller SKB to relief accounting on the socket. - mlx4: - Enable changing default max HCA resource limits using module options. - Support opening of more resources then the default by increasing command timeout for INIT_HCA to 10 seconds - PPC64 support: - Fixed compilation problems on SLES10 SP1 Tziporet & Vlad ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] IB/IPoIB Check if grat. ARP changed had arrived when working in connected mode
> > This patch resolves a critical bug: > https://bugs.openfabrics.org/show_bug.cgi?id=878 > Eli, If you have no objection to the patch, could we add it before rc3 is out? thanks ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] IB/IPoIB Check if grat. ARP changed had arrived when working in connected mode
Moni Shoua wrote: > move a little up the code that checks for a situation where the remote > GID stored in the ipoib_neigh is > different than the one present in the neighbour (handle Gratuitous ARP) > or that a bonding fail over has > happened but the neighbour still has a pointer to an ipoib_neigh created > not by the current slave. This > will cause the driver to apply the check also for connected mode > neighbours. > This patch was tested against upstream kernel and ofed_kernel. > > Signed-off-by: Or Gerlitz <[EMAIL PROTECTED]> > Signed-off-by: Moni Shoua <[EMAIL PROTECTED]> > This patch resolves a critical bug: https://bugs.openfabrics.org/show_bug.cgi?id=878 ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] [PATCH] IB/IPoIB Check if grat. ARP changed had arrived when working in connected mode
On Tue, 2008-01-29 at 16:17 +0200, Moni Shoua wrote: > Eli Cohen wrote: > > Now you may call ipoib_put_ah(neigh->ah) for a CM neighbor and this > > could cause de-reference of a NULL pointer. > > > If I understand you right, I don't see how this can happen. > The code block that calls ipoib_put_ah(neigh->ah) starts with if > (neigh->ah)... > > Am I right? > Oh I see. I missed that. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] [PATCH] IB/IPoIB Check if grat. ARP changed had arrived when working in connected mode
Eli Cohen wrote: > Now you may call ipoib_put_ah(neigh->ah) for a CM neighbor and this > could cause de-reference of a NULL pointer. > If I understand you right, I don't see how this can happen. The code block that calls ipoib_put_ah(neigh->ah) starts with if (neigh->ah)... Am I right? ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: non SRQ patch for OFED 1.3
Pradeep Satyanarayana wrote: Some HCAs like ehca do not natively support srq. This patch would enable IPoIB CM for such HCAs. This patch has been accepted into Roland's for-2.6.25 git tree for about 3 months now. Please consider including this patch into OFED 1.3. As decided in OFED meeting yesterday - we will have a point release 1.3.1 that will include few IPoIB enhancements including this one Vlad will open a branch in git soon Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] [PATCH] IB/IPoIB Check if grat. ARP changed had arrived when working in connected mode
Now you may call ipoib_put_ah(neigh->ah) for a CM neighbor and this
could cause de-reference of a NULL pointer.
On Tue, 2008-01-29 at 12:44 +0200, Moni Shoua wrote:
> move a little up the code that checks for a situation where the remote GID
> stored in the ipoib_neigh is
> different than the one present in the neighbour (handle Gratuitous ARP)
> or that a bonding fail over has
> happened but the neighbour still has a pointer to an ipoib_neigh created
> not by the current slave. This
> will cause the driver to apply the check also for connected mode
> neighbours.
> This patch was tested against upstream kernel and ofed_kernel.
>
> Signed-off-by: Or Gerlitz <[EMAIL PROTECTED]>
> Signed-off-by: Moni Shoua <[EMAIL PROTECTED]>
>
> diff --git a/kernel_patches/fixes/ipoib_0120_check_grat_arp_with_cm.patch
> b/kernel_patches/fixes/ipoib_0120_check_grat_arp_with_cm.patch
> new file mode 100644
> index 000..8b2c32e
> --- /dev/null
> +++ b/kernel_patches/fixes/ipoib_0120_check_grat_arp_with_cm.patch
> @@ -0,0 +1,34 @@
> +Index: ofa_kernel-1.3/drivers/infiniband/ulp/ipoib/ipoib_main.c
> +===
> +--- ofa_kernel-1.3.orig/drivers/infiniband/ulp/ipoib/ipoib_main.c
> 2008-01-29 08:55:33.0 -0500
> ofa_kernel-1.3/drivers/infiniband/ulp/ipoib/ipoib_main.c 2008-01-29
> 09:17:30.0 -0500
> +@@ -716,12 +716,7 @@
> +
> + neigh = *to_ipoib_neigh(skb->dst->neighbour);
> +
> +-if (ipoib_cm_get(neigh)) {
> +-if (ipoib_cm_up(neigh)) {
> +-ipoib_cm_send(dev, skb, ipoib_cm_get(neigh));
> +-goto out;
> +-}
> +-} else if (neigh->ah) {
> ++if (neigh->ah)
> + if (unlikely((memcmp(&neigh->dgid.raw,
> + skb->dst->neighbour->ha + 4,
> + sizeof(union ib_gid))) ||
> +@@ -742,9 +737,14 @@
> + goto out;
> + }
> +
> ++if (ipoib_cm_get(neigh)) {
> ++if (ipoib_cm_up(neigh)) {
> ++ipoib_cm_send(dev, skb, ipoib_cm_get(neigh));
> ++goto out;
> ++}
> ++} else if (neigh->ah) {
> + ipoib_send(dev, skb, neigh->ah,
> +IPOIB_QPN(skb->dst->neighbour->ha));
> +-
> + goto out;
> + }
> +
>
> ___
> general mailing list
> [EMAIL PROTECTED]
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
>
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] OFED Jan 28 meeting summary on RC3 readiness
OFED Jan 28 meeting summary on RC3 readiness: = 1. OFED 1.3 readiness toward RC3 this week * RC3 is based on the official 2.6.24 release * RC3 is expected on Wed * RC4 is planned for Feb 13 2. All companies update: * IBM - ready for RC3 * Voltaire - ready for RC3 * Qlogic - ready for RC3; will work on bug 874 * Intel - things looks good. Need some uDAPL update from Arlin * Chelsio - ready for RC3 * NetEffect - ready for RC3 * Cisco - reported all issues in bugzilla * Mellanox - ready for RC3 * MPI - all packages are ready 3. Request to change IPoIB to support CM without SRQ and 4K MTU Decided that we cannot insert such enhancements at this stage (RC3 built today) without delaying the release since IPoIB is a critical ULP used by all customers. Since we do not want to delay the release and we wish to have a solution for the new IPoIB enhancements we plan to have 1.3.1 release AIs: Tziporet to define the 1.3.1 release (scope of changes, schedule etc.) Vlad: open 1_3_1 branch so people will have a place to commit changes. We will not start any daily build before 1.3 release 3. Review high priority bugs: 846 critical[EMAIL PROTECTED] SDP crash on RHEL5 ppc64 running netserver - will be debugged 859 critical[EMAIL PROTECTED] Bonding configuration on Sles10 sp1 is not loaded consistently - fixed 863 critical[EMAIL PROTECTED] ib-bonding won't compile for RHEL4 U6- fixed 874 critical[EMAIL PROTECTED] Intel MPI (IMB test) hangs intermittently on the qlogic HCA - will be debugged by Qlogic 760 major [EMAIL PROTECTED] UDP performance on Rx is lower than Tx - for 1.3.1 761 major [EMAIL PROTECTED] Poor and jittery UDP performance at small messages - for 1.3.1 869 major [EMAIL PROTECTED] mstflint won't build on SLES10 x86 - fixed 736 major [EMAIL PROTECTED] IBV_WC_RETRY_EXC_ERR errors with local rdma_reads- seems a FW issue (Mellanox to debug) 767 major [EMAIL PROTECTED] Non backport Kernels that don't build in genalloc cause compile errors for cxgb3 - no fix (document) Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Is it possible to upgrage memory in the OFA hosting server
Johann George wrote: I can arrange for the disk space and memory to be upgraded. I'm not sure how disruptive it is and am wondering if we should wait until after this OFED release is out? Johann OK - lets do this after 1.3 release Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: Distributing the SRP target source code
On Jan 29, 2008 11:09 AM, Vu Pham <[EMAIL PROTECTED]> wrote: > Bart Van Assche wrote: > > Please remove drivers/infiniband/ulp/srpt/scsi_tgt.h and scst_const.h > > from the OFED distribution. It's better that the SRP target doesn't > > build if SCST was not yet installed instead of having to experience a > > kernel crash when OFED was built before SCST. > > It's clear from both ofed/srpt readme and Vlad's SCST bit > fat warning. You either build scst before ofed or > rebuild ofed After having installed SCST and OFED 1.3 on a system there will be two incompatible versions present on that system of SCST's header file scsi_tgt.h. This is confusing and questionable. Furthermore, the SRP target will only build correctly if /usr/local/include is in the include path before . (current directory). Relying on the order of directories in the include path is a very questionable practice too. Bart. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] IB/IPoIB Check if grat. ARP changed had arrived when working in connected mode
move a little up the code that checks for a situation where the remote GID
stored in the ipoib_neigh is
different than the one present in the neighbour (handle Gratuitous ARP) or
that a bonding fail over has
happened but the neighbour still has a pointer to an ipoib_neigh created
not by the current slave. This
will cause the driver to apply the check also for connected mode neighbours.
This patch was tested against upstream kernel and ofed_kernel.
Signed-off-by: Or Gerlitz <[EMAIL PROTECTED]>
Signed-off-by: Moni Shoua <[EMAIL PROTECTED]>
diff --git a/kernel_patches/fixes/ipoib_0120_check_grat_arp_with_cm.patch
b/kernel_patches/fixes/ipoib_0120_check_grat_arp_with_cm.patch
new file mode 100644
index 000..8b2c32e
--- /dev/null
+++ b/kernel_patches/fixes/ipoib_0120_check_grat_arp_with_cm.patch
@@ -0,0 +1,34 @@
+Index: ofa_kernel-1.3/drivers/infiniband/ulp/ipoib/ipoib_main.c
+===
+--- ofa_kernel-1.3.orig/drivers/infiniband/ulp/ipoib/ipoib_main.c
2008-01-29 08:55:33.0 -0500
ofa_kernel-1.3/drivers/infiniband/ulp/ipoib/ipoib_main.c 2008-01-29
09:17:30.0 -0500
+@@ -716,12 +716,7 @@
+
+ neigh = *to_ipoib_neigh(skb->dst->neighbour);
+
+- if (ipoib_cm_get(neigh)) {
+- if (ipoib_cm_up(neigh)) {
+- ipoib_cm_send(dev, skb, ipoib_cm_get(neigh));
+- goto out;
+- }
+- } else if (neigh->ah) {
++ if (neigh->ah)
+ if (unlikely((memcmp(&neigh->dgid.raw,
+ skb->dst->neighbour->ha + 4,
+ sizeof(union ib_gid))) ||
+@@ -742,9 +737,14 @@
+ goto out;
+ }
+
++ if (ipoib_cm_get(neigh)) {
++ if (ipoib_cm_up(neigh)) {
++ ipoib_cm_send(dev, skb, ipoib_cm_get(neigh));
++ goto out;
++ }
++ } else if (neigh->ah) {
+ ipoib_send(dev, skb, neigh->ah,
+ IPOIB_QPN(skb->dst->neighbour->ha));
+-
+ goto out;
+ }
+
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH/ docs ofed-1.3 ] Add ib-bonding documentation
* Move ib-bonding.txt from ib-bonding RPM to here. * Add more notes for the ib-bonding section in ipoib_release_notes.txt Signed-off-by: Moni Shoua --- diff --git a/ib-bonding.txt b/ib-bonding.txt new file mode 100644 index 000..03e280e --- /dev/null +++ b/ib-bonding.txt @@ -0,0 +1,159 @@ +IB Bonding +=== + +1. Introduction +2. How to work with ib-bond +3. How to work with interface configuration scripts +3.1 Configuration with initscripts support +3.1.1 Writing network scripts under Redhat-AS4 (Update 4, 5 or 6) +3.1.2 Writing network scripts under Redhhat-EL5 +3.2 Configuration with sysconfig support +3.2.1 Writing network scripts under SLES-10 + +1. Introduction +--- +ib-bonding is a High Availability solution for IPoIB interfaces. It is based +on the Linux Ethernet Bonding Driver and was adopted to work with IPoIB. +ib-bonding package contains a bonding driver and a utility called ib-bond to +manage and control the driver operation. + +2. How to work with ib-bond +--- + +* Creating a bonding network interface + --bond-name: sets the name of the bonding network interface. Default is bond0 + --bond-ip : sets the IP address of bond0. If MASK is not given it + is set to 255.255.255.0 (24 bits). Note that MASK should be the number of 1 + bits in the netmask. + --slaves: a comma separated list of slave ib devices. If not given ib0 and + ib1 will be used as slaves. Child interfaces are allowed. + --miimon: the MII monitoring interval in mSec. Default is 100 +* Deleting a bonding network interface + --stop: unenslave slaves and delete a specific bonding network interface (use with --bond-name) + --stop-all: unenslave slaves and delete all bonding network interfaces +* Querying a bonding network interface + --status: show the status of a specific bonding network interface (use with --bond-name) + --status-all: show the status of all bonding network interfaces + +Examples: + +* To bring up bond0 with ib0 and ib2 as slaves (assumes 2 HCAs) + ib-bond --bond-ip 192.186.10.100 --slaves ib0,ib2 +* To bring up bond1 with ib0.f1f1 1and ib1.f1f1 as slaves with non default + netmask + ib-bond --bond-name bond1 --bond-ip 192.186.10.100/25 --slaves ib0.f1f1,ib1.f1f1 +* To query the status of bond1 + ib-bond --bond-name bond1 --status +* To query the status of all bonding interfaces + ib-bond --status-all +* To stop bond1 + ib-bond --bond-name bond1 --stop +* To stop all bonding interfaces + ib-bond --stop-all + +3. How to work with interface configuration scripts +--- +Using ib-bond to configure interfaces doesn't save the configuration anywhere, +so whenever the master or one of the slaves is destroyed the configuration +should be restored by running ib-bond again (e.g. after system reboot). +It is possible to avoid that if you create an interface configuration script for +the ibX and bondX interfaces. To do that, you should use the standard syntax to +create the bonding configuration (depending on your OS). + +3.1 Configuration with initscripts support +-- +Note: This feature is available only for Redhat-AS4 (Update 4, Update 5 or +Update 6) and + for Redhat-EL5 and above. + +3.1.1 Writing network scripts under Redhat-AS4 (Update 4, 5 or 6) +-- +* In the master (bond) interface script add the line: +TYPE=Bonding + +Exmaple: for bond0 (master) the file is named /etc/sysconfig/network-scripts/ifcfg-bond0 +with the following text in the file: + +DEVICE=bond0 +IPADDR=192.168.1.1 +NETMASK=255.255.255.0 +NETWORK=192.168.1.0 +BROADCAST=192.168.1.255 +ONBOOT=yes +BOOTPROTO=none +USERCTL=no +TYPE=Bonding + +* In the slave (ib) interface script put the following lines: +SLAVE=yes +MASTER= +TYPE=InfiniBand + +Example: the script for ib0 (slave) would be named /etc/sysconfig/network-scripts/ifcfg-ib0 +with the following text in the file: + +DEVICE=ib0 +USERCTL=no +ONBOOT=yes +MASTER=bond0 +SLAVE=yes +BOOTPROTO=none +TYPE=InfiniBand + +After the configuration is saved, restart the network service by running: +/etc/init.d/network restart + +3.1.2 Writing network scripts under Redhhat-EL5 +--- +Follow the instructions in 3.1.1 (Writing network scripts under Redhat-AS4) +with the following changes: +* In the bondX (master) script - the line TYPE=Bonding is not needed. +* in the ibX (slave) script - the line TYPE=InfiniBand is not needed. +* in /etc/modprobe.conf add the following lines +alias bond0 bonding +options bond0 miimon=100 mode=1 max_bonds=1 + +If you want more than one bonding interface, name them bond1, bond2... and +j
[ewg] Re: Distributing the SRP target source code
Bart Van Assche wrote: On Jan 29, 2008 9:20 AM, Vu Pham <[EMAIL PROTECTED]> wrote: There are two include paths. The first one is /usr/local/include/scst and the second one are drivers/infiniband/ulp/srpt. Therefore, building srpt in ofed will always use the /usr/local/include/scst path first and if you already install scst then there won't be any problem As you already know /usr/local/include/scst/scsi_tgt.h is not userspace header. SCST is not part of kernel yet; srpt is also not part of kernel Please remove drivers/infiniband/ulp/srpt/scsi_tgt.h and scst_const.h from the OFED distribution. It's better that the SRP target doesn't build if SCST was not yet installed instead of having to experience a kernel crash when OFED was built before SCST. It's clear from both ofed/srpt readme and Vlad's SCST bit fat warning You either build scst before ofed or rebuild ofed All this trouble can be avoided by distributing the SRP target code with SCST instead of with OFED. The same problem would appear if someone use different ofed versions Personally I never use OFED kernel modules built from the OFED source distribution but instead I use the InfiniBand kernel modules included with the Linux distribution in use. This guarantees consistence between the kernel core and the InfiniBand kernel modules. And whenever I use the SRP target code, I copy it to the kernel source tree and build it from there instead of relying on the OFED kernel build process. And if you have never build ofed and only use IB drivers/modules in kernel tree then you should not use the srpt source in ofed distribution. You should srpt driver from this git tree git://git.openfabrics.org/~vu/srpt.git This srpt git tree does not have scsi_tgt.h in it ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Let's chat
Hello! I am tired this afternoon. I am nice girl that would like to chat with you. Email me at [EMAIL PROTECTED] only, because I am using my friend's email to write this. I would like to share some of my pics. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: Distributing the SRP target source code
On Jan 29, 2008 9:20 AM, Vu Pham <[EMAIL PROTECTED]> wrote: > There are two include paths. The first one is > /usr/local/include/scst and the second one are > drivers/infiniband/ulp/srpt. Therefore, building srpt in > ofed will always use the /usr/local/include/scst path first > and if you already install scst then there won't be any problem > > As you already know /usr/local/include/scst/scsi_tgt.h is > not userspace header. SCST is not part of kernel yet; srpt > is also not part of kernel Please remove drivers/infiniband/ulp/srpt/scsi_tgt.h and scst_const.h from the OFED distribution. It's better that the SRP target doesn't build if SCST was not yet installed instead of having to experience a kernel crash when OFED was built before SCST. > > All this trouble can be avoided by distributing the SRP target code > > with SCST instead of with OFED. > > The same problem would appear if someone use different ofed > versions Personally I never use OFED kernel modules built from the OFED source distribution but instead I use the InfiniBand kernel modules included with the Linux distribution in use. This guarantees consistence between the kernel core and the InfiniBand kernel modules. And whenever I use the SRP target code, I copy it to the kernel source tree and build it from there instead of relying on the OFED kernel build process. Bart. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Ado6e FontFolio 11 for MAC\XP\Vlsta 189, Retail 2599 (save 2409)
cakewalk sonar 6 producer edition - 69 intuit quicken home and business 2008 - 39 roxio digitalmedia studio deluxe suite 7.0 - 49 office professional xp - 49 autodesk architectural studio 3.0 - 39 luxology modo 301 for mac - 129 symantec norton 360 - 29 acronis true image workstation 9.1.3887 - 29 office professional xp - 49 v!slt >microsoft2008sale. com< in your |nternet Explorer 4 5 6 ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [GIT PULL] ~sashak/management.git
Sasha Khapyorsky wrote: Hi Vlad, Please pull recent ofed_1_3 branch of ~sashak/management.git. The changes are: Hal Rosenstock (2): infiniband-diags: Add missing COPYING file management: Update License: field in management spec files Sasha Khapyorsky (2): opensm: rename field pkey to pkey_ix in gsi part of mad address opensm: remove osm_physp_get_mod_pkey_tbl() Yevgeny Kliteynik (3): opensm/QoS: fixing RDS handling in QoS policy opensm/osm_ucast_ftree.c: ignore port 0 and loopbacks on swithces opensm: osm_version.h not found Thanks, Sasha Done, Regards, Vladimir ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] MVAPICH1 1.0.0 SRPM available
New srpm for MVAPICH1 was uploaded. Please check ~pasha/ofed_1_3/ (see latest.txt for the build number) New build include documentation and tuning fixes. -- Pavel Shamis (Pasha) Mellanox Technologies ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: Distributing the SRP target source code
Bart Van Assche wrote: On Jan 28, 2008 6:07 PM, Vu Pham <[EMAIL PROTECTED]> wrote: On srpt readme file, the prerequisite is install SCST BEFORE ofed-1.3 or like Vlad warning "recompiling ofed" if you install scst after install ofed. This is what will happen if someone installs Linux kernel headers + SCST + OFED in this order: 1. Linux kernel headers matching the running kernel are installed in /usr/src/linux-.../include or equivalent, and a symbolic link to the kernel headers is created in /lib/modules/$(uname -r)/build/include. 2. By building and installing SCST, SCST modules are installed in /lib/modules/$(uname -r)/extra and SCST kernel headers are installed in /usr/local/include, a.o. SCST's scsi_tgt.h header file, the interface between SCST and mid-level SCSI drivers. 3. Next, OFED kernel modules are being built. During this process the SRP target module is compiled with the header file drivers/infiniband/ulp/srpt/scsi_tgt.h. The version of this file distributed with OFED 1.3 is incompatible with the one distributed with the latest version of SCST. Or: the kernel will probably crash as soon as one starts using the SRP target module, even if he or she followed the above outlined "official" build procedure. Including /usr/local/include/scsi_tgt.h in the SRP target module is not an option -- kernel modules must not include userspace headers, except for the well known exceptions like . There are two include paths. The first one is /usr/local/include/scst and the second one are drivers/infiniband/ulp/srpt. Therefore, building srpt in ofed will always use the /usr/local/include/scst path first and if you already install scst then there won't be any problem As you already know /usr/local/include/scst/scsi_tgt.h is not userspace header. SCST is not part of kernel yet; srpt is also not part of kernel All this trouble can be avoided by distributing the SRP target code with SCST instead of with OFED. The same problem would appear if someone use different ofed versions Furthermore, all kernel headers that define inter-module interfaces should reside in /include//... The SRP target breaks this convention by having a private copy of an inter-module interface in a local directory (drivers/infiniband/ulp/srpt/scsi_tgt.h). Once again srpt is not part of kernel; therefore, it breaks certain kernel rule. We'll fix it if scst is official part of kernel here is one of the reason srpt is part of ofed not scst: SCST is GPL ofed + srpt is GPL or BSD This is not an issue -- if you have a look at the Linux kernel, you will see that all source files are licensed under at least the GPLv2 and some source files are licensed under GPLv2 + one or more other licenses, e.g. BSD. I know that; however, I don't know if SCST has ok with double license or not -vu ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: Distributing the SRP target source code
On Jan 28, 2008 6:07 PM, Vu Pham <[EMAIL PROTECTED]> wrote: > > On srpt readme file, the prerequisite is install SCST BEFORE > ofed-1.3 or like Vlad warning "recompiling ofed" if you > install scst after install ofed. This is what will happen if someone installs Linux kernel headers + SCST + OFED in this order: 1. Linux kernel headers matching the running kernel are installed in /usr/src/linux-.../include or equivalent, and a symbolic link to the kernel headers is created in /lib/modules/$(uname -r)/build/include. 2. By building and installing SCST, SCST modules are installed in /lib/modules/$(uname -r)/extra and SCST kernel headers are installed in /usr/local/include, a.o. SCST's scsi_tgt.h header file, the interface between SCST and mid-level SCSI drivers. 3. Next, OFED kernel modules are being built. During this process the SRP target module is compiled with the header file drivers/infiniband/ulp/srpt/scsi_tgt.h. The version of this file distributed with OFED 1.3 is incompatible with the one distributed with the latest version of SCST. Or: the kernel will probably crash as soon as one starts using the SRP target module, even if he or she followed the above outlined "official" build procedure. Including /usr/local/include/scsi_tgt.h in the SRP target module is not an option -- kernel modules must not include userspace headers, except for the well known exceptions like . All this trouble can be avoided by distributing the SRP target code with SCST instead of with OFED. Furthermore, all kernel headers that define inter-module interfaces should reside in /include//... The SRP target breaks this convention by having a private copy of an inter-module interface in a local directory (drivers/infiniband/ulp/srpt/scsi_tgt.h). > here is one of the reason srpt is part of ofed not scst: > > SCST is GPL > ofed + srpt is GPL or BSD This is not an issue -- if you have a look at the Linux kernel, you will see that all source files are licensed under at least the GPLv2 and some source files are licensed under GPLv2 + one or more other licenses, e.g. BSD. Bart. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
