[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 stdarg.h. 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 kernel source root dir/include/subdir/... 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 stdarg.h. 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 kernel source root dir/include/subdir/... 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
[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] 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] 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] 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 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] 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
[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
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
[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] 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
[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
[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 BLOCKED::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] 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.htmlBLOCKED::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
