[ewg] [ANNOUNCE] open iSCSI over iSER target RPM is available
stgt (SCSI target) is an open-source framework for storage target drivers. It supports iSCSI over iSER among other storage target drivers. Voltaire added a git tree for stgt that will be added to OFED 1.4: http://www2.openfabrics.org/git/?p=~dorons/tgt.git;a=summary Until OFED 1.4 gets released, it is possible to install the stgt RPM on top of OFED 1.3. For more details about how to install and use stgt, please refer to https://wiki.openfabrics.org/tiki-index.php?page=ISER-target Some performance numbers that were measured by OSC (using SDR cards): * READ: 920 MB/sec * WRITE: 850 MB/sec We hope to have DDR measurements numbers soon. -- Erez Zilber | 972-9-971-7689 Software Engineer, Storage Solutions Voltaire – _The Grid Backbone_ www.voltaire.com http://www.voltaire.com/ ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [Stgt-devel] [ANNOUNCE] open iSCSI over iSER target RPM is available
On Feb 5, 2008 3:41 PM, Erez Zilber [EMAIL PROTECTED] wrote: stgt (SCSI target) is an open-source framework for storage target drivers. It supports iSCSI over iSER among other storage target drivers. Voltaire added a git tree for stgt that will be added to OFED 1.4: http://www2.openfabrics.org/git/?p=~dorons/tgt.git;a=summary Until OFED 1.4 gets released, it is possible to install the stgt RPM on top of OFED 1.3. For more details about how to install and use stgt, please refer to https://wiki.openfabrics.org/tiki-index.php?page=ISER-target Some performance numbers that were measured by OSC (using SDR cards): * READ: 920 MB/sec * WRITE: 850 MB/sec We hope to have DDR measurements numbers soon. Hello Erez, Can you please post more information about how these numbers were obtained (test program and configuration parameters) ? Bart Van Assche. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v2] rdma_lat: Add -m --max-inline option to support devices with different
Ignore this patch. Its bad.
Stay tuned for v3...
:(
Steve Wise wrote:
From: Steve Wise [EMAIL PROTECTED]
inline max values.
Currently the max inline value is hard-coded and too big for the
chelsio device. This patch allows specifying the max inline as a
command line param.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
rdma_lat.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/rdma_lat.c b/rdma_lat.c
index 68c9120..f2ef8e2 100755
--- a/rdma_lat.c
+++ b/rdma_lat.c
@@ -60,6 +60,7 @@
#define PINGPONG_RDMA_WRID 3
#define MAX_INLINE 400
+static int inline_size = MAX_INLINE;
static int page_size;
static pid_t pid;
@@ -603,7 +604,7 @@ static struct pingpong_context *pp_init_ctx(void *ptr, struct pp_data *data)
.max_recv_wr = 1,
.max_send_sge = 1,
.max_recv_sge = 1,
- .max_inline_data = MAX_INLINE
+ .max_inline_data = inline_size,
},
.qp_type = IBV_QPT_RC
};
@@ -915,6 +916,7 @@ static void usage(const char *argv0)
printf( -s, --size=size size of message to exchange (default
1)\n);
printf( -t, --tx-depth=dep size of tx queue (default 50)\n);
printf( -n, --iters=itersnumber of exchanges (at least 2, default
1000)\n);
+ printf( -I, --inline_size=size max size of message to be sent in inline
mode (default 400)\n);
printf( -C, --report-cyclesreport times in cpu cycle units (default
microseconds)\n);
printf( -H, --report-histogram print out all results (default print
summary only)\n);
printf( -U, --report-unsorted (implies -H) print out unsorted results
(default sorted)\n);
@@ -1036,6 +1038,7 @@ int main(int argc, char *argv[])
{ .name = size, .has_arg = 1, .val = 's' },
{ .name = iters, .has_arg = 1, .val = 'n' },
{ .name = tx-depth, .has_arg = 1, .val = 't' },
+ { .name = max-inline, .has_arg = 1, .val = 'm' },
{ .name = report-cycles, .has_arg = 0, .val = 'C' },
{ .name = report-histogram,.has_arg = 0, .val = 'H' },
{ .name = report-unsorted,.has_arg = 0, .val = 'U' },
@@ -1043,7 +1046,7 @@ int main(int argc, char *argv[])
{ 0 }
};
- c = getopt_long(argc, argv, p:d:i:s:n:t:CHUc, long_options, NULL);
+ c = getopt_long(argc, argv, p:d:i:s:n:t:I:CHUc, long_options,
NULL);
if (c == -1)
break;
@@ -1087,6 +1090,10 @@ int main(int argc, char *argv[])
break;
+ case 'I':
+ inline_size = strtol(optarg, NULL, 0);
+ break;
+
case 'C':
report.cycles = 1;
break;
@@ -1192,7 +1199,7 @@ int main(int argc, char *argv[])
ctx-wr.sg_list= ctx-list;
ctx-wr.num_sge= 1;
ctx-wr.opcode = IBV_WR_RDMA_WRITE;
- if (ctx-size MAX_INLINE || ctx-size == 0) {
+ if (ctx-size inline_size || ctx-size == 0) {
ctx-wr.send_flags = IBV_SEND_SIGNALED;
} else {
ctx-wr.send_flags = IBV_SEND_SIGNALED | IBV_SEND_INLINE;
___
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] [PATCH v2] rdma_lat: Add -m --max-inline option to support devices with different
From: Steve Wise [EMAIL PROTECTED]
inline max values.
Currently the max inline value is hard-coded and too big for the
chelsio device. This patch allows specifying the max inline as a
command line param.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
rdma_lat.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/rdma_lat.c b/rdma_lat.c
index 68c9120..f2ef8e2 100755
--- a/rdma_lat.c
+++ b/rdma_lat.c
@@ -60,6 +60,7 @@
#define PINGPONG_RDMA_WRID 3
#define MAX_INLINE 400
+static int inline_size = MAX_INLINE;
static int page_size;
static pid_t pid;
@@ -603,7 +604,7 @@ static struct pingpong_context *pp_init_ctx(void *ptr,
struct pp_data *data)
.max_recv_wr = 1,
.max_send_sge = 1,
.max_recv_sge = 1,
- .max_inline_data = MAX_INLINE
+ .max_inline_data = inline_size,
},
.qp_type = IBV_QPT_RC
};
@@ -915,6 +916,7 @@ static void usage(const char *argv0)
printf( -s, --size=size size of message to exchange (default
1)\n);
printf( -t, --tx-depth=dep size of tx queue (default 50)\n);
printf( -n, --iters=itersnumber of exchanges (at least 2,
default 1000)\n);
+ printf( -I, --inline_size=size max size of message to be sent in
inline mode (default 400)\n);
printf( -C, --report-cyclesreport times in cpu cycle units
(default microseconds)\n);
printf( -H, --report-histogram print out all results (default print
summary only)\n);
printf( -U, --report-unsorted (implies -H) print out unsorted
results (default sorted)\n);
@@ -1036,6 +1038,7 @@ int main(int argc, char *argv[])
{ .name = size, .has_arg = 1, .val = 's' },
{ .name = iters, .has_arg = 1, .val = 'n' },
{ .name = tx-depth, .has_arg = 1, .val = 't' },
+ { .name = max-inline, .has_arg = 1, .val = 'm' },
{ .name = report-cycles, .has_arg = 0, .val = 'C' },
{ .name = report-histogram,.has_arg = 0, .val = 'H' },
{ .name = report-unsorted,.has_arg = 0, .val = 'U' },
@@ -1043,7 +1046,7 @@ int main(int argc, char *argv[])
{ 0 }
};
- c = getopt_long(argc, argv, p:d:i:s:n:t:CHUc, long_options,
NULL);
+ c = getopt_long(argc, argv, p:d:i:s:n:t:I:CHUc, long_options,
NULL);
if (c == -1)
break;
@@ -1087,6 +1090,10 @@ int main(int argc, char *argv[])
break;
+ case 'I':
+ inline_size = strtol(optarg, NULL, 0);
+ break;
+
case 'C':
report.cycles = 1;
break;
@@ -1192,7 +1199,7 @@ int main(int argc, char *argv[])
ctx-wr.sg_list= ctx-list;
ctx-wr.num_sge= 1;
ctx-wr.opcode = IBV_WR_RDMA_WRITE;
- if (ctx-size MAX_INLINE || ctx-size == 0) {
+ if (ctx-size inline_size || ctx-size == 0) {
ctx-wr.send_flags = IBV_SEND_SIGNALED;
} else {
ctx-wr.send_flags = IBV_SEND_SIGNALED | IBV_SEND_INLINE;
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [UPDATE][PATCH] IPoIB-UD 4K MTU patch against 2.6.24 ofed-1.3-git tree
Shirley Ma wrote: I found one one line was out side for loop when merging this patch with current git-tree. This caused UD_POST_RCV_COUNT = 16 wrong. I have fixed it. This is the updated patch. Thanks Shirley Hi Shirley, Its seems to me that 4K MTU patch is not cooked enough for RC4. I appreciate your hard work to push it but so many changes, possible leaks and not enough time for review and testing means too high risk for now Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH v3 ofed-1.3] rdma_lat: Add option to support devices with different inline max values.
rdma_lat: Add option to support devices with different inline max values.
Currently the max inline value is hard-coded and too big for the
chelsio device. This patch allows specifying the max inline as a
command line param.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
rdma_lat.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/rdma_lat.c b/rdma_lat.c
index 68c9120..30cb4a3 100755
--- a/rdma_lat.c
+++ b/rdma_lat.c
@@ -60,6 +60,7 @@
#define PINGPONG_RDMA_WRID 3
#define MAX_INLINE 400
+static int inline_size = MAX_INLINE;
static int page_size;
static pid_t pid;
@@ -603,7 +604,7 @@ static struct pingpong_context *pp_init_ctx(void *ptr,
struct pp_data *data)
.max_recv_wr = 1,
.max_send_sge = 1,
.max_recv_sge = 1,
- .max_inline_data = MAX_INLINE
+ .max_inline_data = inline_size,
},
.qp_type = IBV_QPT_RC
};
@@ -915,6 +916,7 @@ static void usage(const char *argv0)
printf( -s, --size=size size of message to exchange (default
1)\n);
printf( -t, --tx-depth=dep size of tx queue (default 50)\n);
printf( -n, --iters=itersnumber of exchanges (at least 2,
default 1000)\n);
+ printf( -I, --inline_size=size max size of message to be sent in
inline mode (default 400)\n);
printf( -C, --report-cyclesreport times in cpu cycle units
(default microseconds)\n);
printf( -H, --report-histogram print out all results (default print
summary only)\n);
printf( -U, --report-unsorted (implies -H) print out unsorted
results (default sorted)\n);
@@ -1036,6 +1038,7 @@ int main(int argc, char *argv[])
{ .name = size, .has_arg = 1, .val = 's' },
{ .name = iters, .has_arg = 1, .val = 'n' },
{ .name = tx-depth, .has_arg = 1, .val = 't' },
+ { .name = inline_size, .has_arg = 1, .val = 'I' },
{ .name = report-cycles, .has_arg = 0, .val = 'C' },
{ .name = report-histogram,.has_arg = 0, .val = 'H' },
{ .name = report-unsorted,.has_arg = 0, .val = 'U' },
@@ -1043,7 +1046,7 @@ int main(int argc, char *argv[])
{ 0 }
};
- c = getopt_long(argc, argv, p:d:i:s:n:t:CHUc, long_options,
NULL);
+ c = getopt_long(argc, argv, p:d:i:s:n:t:I:CHUc, long_options,
NULL);
if (c == -1)
break;
@@ -1087,6 +1090,10 @@ int main(int argc, char *argv[])
break;
+ case 'I':
+ inline_size = strtol(optarg, NULL, 0);
+ break;
+
case 'C':
report.cycles = 1;
break;
@@ -1192,7 +1199,7 @@ int main(int argc, char *argv[])
ctx-wr.sg_list= ctx-list;
ctx-wr.num_sge= 1;
ctx-wr.opcode = IBV_WR_RDMA_WRITE;
- if (ctx-size MAX_INLINE || ctx-size == 0) {
+ if (ctx-size inline_size || ctx-size == 0) {
ctx-wr.send_flags = IBV_SEND_SIGNALED;
} else {
ctx-wr.send_flags = IBV_SEND_SIGNALED | IBV_SEND_INLINE;
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ofa-general] Re: [ewg] [UPDATE][PATCH] IPoIB-UD 4K MTU patch against 2.6.24 ofed-1.3-git tree
Hello Tziporet, The problem was because of the last check in of small UDP performance patch. It changed the receiving path completely. And I only got less than one day to merge/test the patch with that patch on both intel and PPC platform. The patch was in good/stable shape before this patch. It has passed stress test for both intel and PPC platform. I have tested the whole night of the new patch yesterday night. It works well and passes the stress test without any problem. Regarding Eli's comments, I have sent out. I am sorry for the minor mistake because of the rushing, but I don't see any risk from my test results. Please reconsider this patch to be in OFED-1.3. thanks Shirley Tziporet Koren tziporet To @dev.mell [EMAIL PROTECTED] anox.co.i cc lEli Cohen [EMAIL PROTECTED], Sent by: ewg@lists.openfabrics.org, OpenFabrics general-b General [EMAIL PROTECTED] [EMAIL PROTECTED] Subject sts.openf [ofa-general] Re: [ewg] [UPDATE][PATCH] abrics.or IPoIB-UD 4K MTU patch against 2.6.24 g ofed-1.3-git tree 02/05/08 08:19 AM Shirley Ma wrote: I found one one line was out side for loop when merging this patch with current git-tree. This caused UD_POST_RCV_COUNT = 16 wrong. I have fixed it. This is the updated patch. Thanks Shirley Hi Shirley, Its seems to me that 4K MTU patch is not cooked enough for RC4. I appreciate your hard work to push it but so many changes, possible leaks and not enough time for review and testing means too high risk for now Tziporet ___ 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 inline: graycol.gifinline: pic23340.gifinline: ecblank.gif___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ofa-general] Re: [ewg] [UPDATE][PATCH] IPoIB-UD 4K MTU patch against 2.6.24 ofed-1.3-git tree
Hello Tziporet, On Tue, 2008-02-05 at 18:56 +0200, Tziporet Koren wrote: Shirley Ma wrote: Hello Tziporet, The problem was because of the last check in of small UDP performance patch. It changed the receiving path completely. And I only got less than one day to merge/test the patch with that patch on both intel and PPC platform. The patch was in good/stable shape before this patch. It has passed stress test for both intel and PPC platform. I have tested the whole night of the new patch yesterday night. It works well and passes the stress test without any problem. Which OS have you tested? 2.6.24 kernel, and I am going to test SLES10SP2 kernel. It has passed stress test the whole night for 2K MTU test suites. Regarding Eli's comments, I have sent out. I am sorry for the minor mistake because of the rushing, but I don't see any risk from my test results. Please reconsider this patch to be in OFED-1.3. OK - we will do this - we will run one set of our regression with your patch now, and also check that it pass compilation on all kernels. If both will be OK we will take it. I cross fingers for you :-) ziporet Appreciate you, Vlad and Eli's help here! There is one line change needed for backporting ++priv-stats and ++dev-stats. I didn't create the backport patch for this. thanks Shirley ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] new releases of libibcm and librdmacm libraries
I've pushed out new releases: libibcm 1.0.2 librdmacm 1.0.6 to my git tree, and the OFA download pages. Please pull both packages into OFED 1.3. Major changes from previous release: libibcm - removes obsolete simple.c test program librdmacm - updates to build, fix setting QP attributes for RDMA reads - Sean ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] new releases of libibcm and librdmacm libraries
Sean Hefty wrote: I've pushed out new releases: libibcm 1.0.2 librdmacm 1.0.6 to my git tree, and the OFA download pages. Please pull both packages into OFED 1.3. Major changes from previous release: libibcm - removes obsolete simple.c test program librdmacm - updates to build, fix setting QP attributes for RDMA reads Can you put a tag with the name ofed_1_3 on these git trees too Thanks Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] new releases of libibcm and librdmacm libraries
Can you put a tag with the name ofed_1_3 on these git trees too I have tags of v1.0.2 and v1.0.6. Can these just be used instead? ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] Oops with today's OFED 1.3
Pradeep,
Can you check if this is resolved?
On 2/4/08, Pradeep Satyanarayana [EMAIL PROTECTED] wrote:
I pulled today's (Feb 4th) OFED build and saw the following Oops while touch
testing
on ehca1 on a 2.6.24 kernel.
Modules linked in: ib_ipoib ib_cm ib_sa ib_uverbs ib_umad ib_ehca ib_mthca
ib_mad ib_core joydev st ide_cd ipv6 sg pdc202xx_new e1000 ibmveth dm_mod ipr
libata firmware_class sr_mod cdrom sd_mod scsi_mod
NIP: d0299ca8 LR: d0299a70 CTR: d015ec04
REGS: c001cc85f3b0 TRAP: 0300 Not tainted (2.6.23-ppc64)
MSR: 80009032 EE,ME,IR,DR CR: 24022424 XER: 0020
DAR: 002c, DSISR: 4200
TASK = c001d883d4a0[17052] 'modprobe' THREAD: c001cc85c000 CPU: 2
GPR00: c001cc85f630 d02b5cf0 ffda
GPR04: c001cc85f760 ffda d02a7eb0
GPR08: 0001 001b4800
GPR12: d029ef30 c05a8280 c001d895aa20
GPR16: 0008 d040f27e
GPR20: 0211 c001cd1e
GPR24: d02ad9d8 d02a7eb0 0001
GPR28: c001cc85f760 d02b4ce0 c001cd1e0780
NIP [d0299ca8] .ipoib_cm_dev_init+0x440/0x63c [ib_ipoib]
LR [d0299a70] .ipoib_cm_dev_init+0x208/0x63c [ib_ipoib]
Call Trace:
[c001cc85f630] [d0299a70] .ipoib_cm_dev_init+0x208/0x63c
[ib_ipoib] (unreliable)
[c001cc85f7d0] [d0297f4c] .ipoib_transport_dev_init+0x120/0x458
[ib_ipoib]
[c001cc85f930] [d029463c] .ipoib_ib_dev_init+0x44/0xb8 [ib_ipoib]
[c001cc85f9c0] [d02902ec] .ipoib_dev_init+0xe0/0x138 [ib_ipoib]
[c001cc85fa60] [d0290544] .ipoib_add_one+0x200/0x424 [ib_ipoib]
[c001cc85fb20] [d01610e4] .ib_register_client+0x94/0xf4 [ib_core]
[c001cc85fbb0] [d029dcac] .ipoib_init_module+0x1f8/0x246c
[ib_ipoib]
[c001cc85fc70] [c00905f0] .sys_init_module+0x176c/0x187c
[c001cc85fe30] [c000852c] syscall_exit+0x0/0x40
Instruction dump:
801f0f20 3b60 2f80 409d0040 e81f0f30 e97f04f0 7b6926e4 395b0001
7d5b07b4 7c080214 816b0018 7d290214 9169002c 6000 6000 6000
I tracked this down to the following area of code:
+ for (j = 0; j ipoib_recvq_size; ++j) {
+ for (i = 0; i priv-cm.num_frags; ++i)
+ priv-cm.rx_wr_arr[j].rx_sge[i].lkey = priv-mr-lkey;
in ipoib_0230_srq_post_n.patch.
Touch tested after removing this patch seems to solve the problem.
Pradeep
___
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
Re: [ofa-general] Re: [ewg] [UPDATE][PATCH] IPoIB-UD 4K MTU patch against 2.6.24 ofed-1.3-git tree
Tziporet Koren [EMAIL PROTECTED] wrote on 02/05/2008 12:07:28 PM: Please test on RHREL 5 too What are your stress tests? Ok. The stress test is similar to netperf/netserver. But it's bi-directional multiple streams. I have stressed the stream to 150, duplex running overnight. Please send this backport patch and specify to which kernels its needed Tziporet Ok. It might be out tonight. Thanks Shirley___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] new releases of libibcm and librdmacm libraries
Sean Hefty wrote: Can you put a tag with the name ofed_1_3 on these git trees too I have tags of v1.0.2 and v1.0.6. Can these just be used instead? Its just easier for us when we do diffs to have also the ofed_1_3 as all other git trees After some time pass its hard to remember which version was part of which release :-( Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] new releases of libibcm and librdmacm libraries
Its just easier for us when we do diffs to have also the ofed_1_3 as all other git trees After some time pass its hard to remember which version was part of which release :-( I've added ofed_1_3 tags. Note that if there's a need to update the libraries again, the tag will need to be deleted and re-created to move it forward. I don't anticipate other changes for OFED 1.3 however. - Sean ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] new releases of libibcm and librdmacm libraries
FWIW, I've updated the packages in my Ubuntu PPA; if you're using it, you should get the packages automatically with a normal update once the builds complete. I've also updated the packages I've proposed for inclusion in Debian. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] Oops with today's OFED 1.3
Pradeep Satyanarayana wrote: Eli Cohen wrote: Pradeep, Can you check if this is resolved? On 2/4/08, Pradeep Satyanarayana [EMAIL PROTECTED] wrote: I pulled today's (Feb 4th) OFED build and saw the following Oops while touch testing on ehca1 on a 2.6.24 kernel. snip NIP [d0299ca8] .ipoib_cm_dev_init+0x440/0x63c [ib_ipoib] LR [d0299a70] .ipoib_cm_dev_init+0x208/0x63c [ib_ipoib] Call Trace: [c001cc85f630] [d0299a70] .ipoib_cm_dev_init+0x208/0x63c [ib_ipoib] (unreliable) [c001cc85f7d0] [d0297f4c] .ipoib_transport_dev_init+0x120/0x458 [ib_ipoib] [c001cc85f930] [d029463c] .ipoib_ib_dev_init+0x44/0xb8 [ib_ipoib] [c001cc85f9c0] [d02902ec] .ipoib_dev_init+0xe0/0x138 [ib_ipoib] [c001cc85fa60] [d0290544] .ipoib_add_one+0x200/0x424 [ib_ipoib] [c001cc85fb20] [d01610e4] .ib_register_client+0x94/0xf4 [ib_core] [c001cc85fbb0] [d029dcac] .ipoib_init_module+0x1f8/0x246c [ib_ipoib] [c001cc85fc70] [c00905f0] .sys_init_module+0x176c/0x187c [c001cc85fe30] [c000852c] syscall_exit+0x0/0x40 Instruction dump: 801f0f20 3b60 2f80 409d0040 e81f0f30 e97f04f0 7b6926e4 395b0001 7d5b07b4 7c080214 816b0018 7d290214 9169002c 6000 6000 6000 Hello Eli, Yes, this particular issue has been solved. However, I do see some other issues. I seeing some new messages (not seen previously) in dmesg relating to ib_cq_destroy() (on ehca): ib0: ib_cq_destroy failed ib_destroy_srq failed: -16 ib_dealloc_pd failed This happens after some network tests and an rmmod of ib_ehca. At this point my guess is that this has to do with the split CQ patch. I have not had enough cycles to state that with absolute certainty. Can you please take a look too? Pradeep I looked at this some more. This error occurs because ib_cq_destroy() for rcq failed. After that there are a series of cascading failures. Pradeep ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
