[ofa-general] ofa_1_3_kernel 20070926-0200 daily build status
This email was generated automatically, please do not reply git_url: git://git.openfabrics.org/ofed_1_3/linux-2.6.git git_branch: ofed_kernel Common build parameters: --with-ipoib-mod --with-sdp-mod --with-srp-mod --with-user_mad-mod --with-user_access-mod --with-mthca-mod --with-mlx4-mod --with-core-mod --with-addr_trans-mod --with-rds-mod --with-cxgb3-mod --with-nes-mod Passed: Passed on i686 with 2.6.15-23-server Passed on i686 with linux-2.6.22 Passed on i686 with linux-2.6.21.1 Passed on i686 with linux-2.6.18 Passed on i686 with linux-2.6.13 Passed on i686 with linux-2.6.17 Passed on i686 with linux-2.6.16 Passed on i686 with linux-2.6.14 Passed on i686 with linux-2.6.15 Passed on i686 with linux-2.6.19 Passed on i686 with linux-2.6.12 Passed on x86_64 with linux-2.6.12 Passed on ppc64 with linux-2.6.12 Passed on ia64 with linux-2.6.19 Passed on ia64 with linux-2.6.13 Passed on powerpc with linux-2.6.13 Passed on ppc64 with linux-2.6.16 Passed on ia64 with linux-2.6.15 Passed on ia64 with linux-2.6.12 Passed on ppc64 with linux-2.6.15 Passed on ia64 with linux-2.6.14 Passed on powerpc with linux-2.6.14 Passed on ia64 with linux-2.6.17 Passed on x86_64 with linux-2.6.16 Passed on ia64 with linux-2.6.16 Passed on powerpc with linux-2.6.15 Passed on x86_64 with linux-2.6.13 Passed on powerpc with linux-2.6.12 Passed on ia64 with linux-2.6.18 Passed on ppc64 with linux-2.6.14 Passed on ppc64 with linux-2.6.19 Passed on x86_64 with linux-2.6.18 Passed on x86_64 with linux-2.6.19 Passed on ppc64 with linux-2.6.18 Passed on x86_64 with linux-2.6.20 Passed on x86_64 with linux-2.6.17 Passed on ppc64 with linux-2.6.13 Passed on x86_64 with linux-2.6.14 Passed on x86_64 with linux-2.6.21.1 Passed on ppc64 with linux-2.6.17 Passed on ia64 with linux-2.6.22 Passed on x86_64 with linux-2.6.16.21-0.8-smp Passed on ia64 with linux-2.6.21.1 Passed on x86_64 with linux-2.6.9-42.ELsmp Passed on x86_64 with linux-2.6.15 Passed on x86_64 with linux-2.6.16.43-0.3-smp Passed on x86_64 with linux-2.6.22 Passed on ia64 with linux-2.6.16.21-0.8-default Passed on x86_64 with linux-2.6.9-22.ELsmp Passed on x86_64 with linux-2.6.9-55.ELsmp Passed on x86_64 with linux-2.6.18-8.el5 Passed on ppc64 with linux-2.6.18-8.el5 Passed on x86_64 with linux-2.6.9-34.ELsmp Passed on x86_64 with linux-2.6.18-1.2798.fc6 Failed: Build failed on powerpc with linux-2.6.18 Log: /home/vlad/tmp/ofa_1_3_kernel-20070926-0200_linux-2.6.18_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.c:936: error: invalid type argument of '-' /home/vlad/tmp/ofa_1_3_kernel-20070926-0200_linux-2.6.18_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.c:939: error: invalid type argument of '-' /home/vlad/tmp/ofa_1_3_kernel-20070926-0200_linux-2.6.18_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.c:940: error: invalid type argument of '-' make[4]: *** [/home/vlad/tmp/ofa_1_3_kernel-20070926-0200_linux-2.6.18_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.o] Error 1 make[3]: *** [/home/vlad/tmp/ofa_1_3_kernel-20070926-0200_linux-2.6.18_powerpc_check/drivers/infiniband/hw/ehca] Error 2 make[2]: *** [/home/vlad/tmp/ofa_1_3_kernel-20070926-0200_linux-2.6.18_powerpc_check/drivers/infiniband] Error 2 make[1]: *** [_module_/home/vlad/tmp/ofa_1_3_kernel-20070926-0200_linux-2.6.18_powerpc_check] Error 2 make[1]: Leaving directory `/home/vlad/kernel.org/powerpc/linux-2.6.18' make: *** [kernel] Error 2 -- Build failed on powerpc with linux-2.6.19 Log: /home/vlad/tmp/ofa_1_3_kernel-20070926-0200_linux-2.6.19_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.c:936: error: invalid type argument of '-' /home/vlad/tmp/ofa_1_3_kernel-20070926-0200_linux-2.6.19_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.c:939: error: invalid type argument of '-' /home/vlad/tmp/ofa_1_3_kernel-20070926-0200_linux-2.6.19_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.c:940: error: invalid type argument of '-' make[4]: *** [/home/vlad/tmp/ofa_1_3_kernel-20070926-0200_linux-2.6.19_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.o] Error 1 make[3]: *** [/home/vlad/tmp/ofa_1_3_kernel-20070926-0200_linux-2.6.19_powerpc_check/drivers/infiniband/hw/ehca] Error 2 make[2]: *** [/home/vlad/tmp/ofa_1_3_kernel-20070926-0200_linux-2.6.19_powerpc_check/drivers/infiniband] Error 2 make[1]: *** [_module_/home/vlad/tmp/ofa_1_3_kernel-20070926-0200_linux-2.6.19_powerpc_check] Error 2 make[1]: Leaving directory `/home/vlad/kernel.org/powerpc/linux-2.6.19' make: *** [kernel] Error 2 -- Build failed on powerpc with linux-2.6.17 Log: /home/vlad/tmp/ofa_1_3_kernel-20070926-0200_linux-2.6.17_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.c:936: error: invalid type argument of '-' /home/vlad/tmp/ofa_1_3_kernel-20070926-0200_linux-2.6.17_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.c:939: error: invalid
[ofa-general] ***SPAM*** list of medical doctors
Only for the week ending Sep 28, you will get a Listing for Nursing Homes,
Hospitals, Dentists and Chiropractors at no additional cost when you order the
Medical Doctor Listing
Licensed Medical Doctors in the USA
788,480 in total 17,400 emails
Many different medical specialties
Many unique fields like 'medical school attended' and 'location of residency
training'
Price for this week only = $382
*** Recieve the 4 medical Lists below without charge when you buy the Medical
Doctor Directory above ***
Directory of US Hospitals
23,000 Admins in more than 7,000 hospitals {a $399 value]
Dentists in the USA
More than half a million listings [worth $299 alone!]
US Nursing Home List
Full data for CFO, Nursing Directors, Senior Admins [ worth $249 alone ]
Chiropractors in the USA
Complete data for all chiropractors in the USA (a $249 value)
reply to: [EMAIL PROTECTED]
by sending us an email with exit in the subject we will know not to contact
you again
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] ofed 1.3 kernel tree updated to 2.6.23-rc8
Hello! I have updated the OFED 1.3 kernel tree at git://git.openfabrics.org/ofed_1_3/linux-2.6.git ofed_kernel to upstream 2.6.23-rc8. I have resolved minor conflicts in libiscsi backports for RHEL4, and everything seems to build fine now. iSER maintainers, please verify that I did the right thing. -- MST ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [ofa-general] SDP memory allocation policy problem?
This would be on my plate. I was travelling and have not gotten a chance to
test the fix. On inspection, I see no problems with
this approach and do not expect to see any testing issues.
If you want to rework the patch to remove the PROPOSED_SDP_FIX and submit it, I
will test it today. Otherwise, I will do the patch
and testing by tomorrow.
Sorry for taking so long.
JIm
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Dauchy
Sent: Tuesday, September 25, 2007 5:50 PM
To: general@lists.openfabrics.org
Subject: Re: [ofa-general] SDP memory allocation policy problem?
Is there anyone among the OFED development team that is looking into
this issue? I believe that it is causing nodes to hang at our site. We
are running ofed-1.2 and the 2.6.9-55.ELsmp kernel.
Workarounds or even untested patches would be appreciated.
Thanks!
-Nathan
Ken Phillips wrote:
Greetings,
Teammates here report the following:
Problem
The method SDP uses to allocate socket buffers may cause the
node to hang under memory pressure.
Details
Each kernel level socket has an allocation flag to specify the
memory allocation policy for socket buffers, the default is GFP_ATOMIC
(or GFP_KERNEL for SDP). If the caller creates a socket with the
policy set to GFP_NOFS or GFP_NOIO this should be the allocation
policy used by the SDP layer.
The problem we are seeing is that if a node is under load, and
a memory allocation fails (say in sock_sendmsg()), the kernel will
use the allocation policy to decide how to proceed with the allocation.
If GFP_KERNEL is specified, then the kernel may attempt to free pages
through the iSCSI block device that is making the socket call, which
would result in a deadlock. Use of GFP_NOIO should prevent the kernel
from using the IO backend to free memory resources.
here is a sample stack trace from Alt-Sysrq during one of these
lockups,
tx_worker D ff0014d14000 0 10195 1 10196 10194
(L-TLB)
0100707e98d8 0046 0004 0212
0212 a018ccae 0246 0246
01007873c7f0 0320
Call Trace:a018ccae{:ib_mthca:mthca_poll_cq+2258}
8030ad5c{schedule_timeout+224}
802a9db7{lock_sock+152}
80135756{autoremove_wake_function+0}
a0538b13{:ib_sdp:sdp_poll_cq+58}
80135756{autoremove_wake_function+0}
802a9dfd{release_sock+16}
a0534b18{:ib_sdp:sdp_sendmsg+33}
802a730f{sock_sendmsg+271}
a05386ad{:ib_sdp:sdp_post_sends+619}
802a9dfd{release_sock+16}
a05353a5{:ib_sdp:sdp_sendmsg+}
80135756{autoremove_wake_function+0}
a057708f{:rs_iscsi:iscsi_sock_msg+1265}
a057708b{:rs_iscsi:iscsi_sock_msg+1261}
80132159{recalc_task_prio+337}
a055bfdb{:rs_iscsi:scsi_command_i+5283}
8030a2c9{thread_return+0}
8030a321{thread_return+88}
8013fdf7{del_timer+107}
8013feb4{del_singleshot_timer_sync+9}
8030adf3{schedule_timeout+375}
a056829e{:rs_iscsi:tx_worker_proc_i+6819}
80110f47{child_rip+8}
a05667fb{:rs_iscsi:tx_worker_proc_i+0}
80110f3f{child_rip+0}
We still don't know the scope of changes to be made, but we think,
at minimum that some of the memory allocation in SDP should be changed,
for example.
diff -Naur old/drivers/infiniband/ulp/sdp/sdp_bcopy.c
new/drivers/infiniband/ulp/sdp/sdp_bcopy.c
--- old/drivers/infiniband/ulp/sdp/sdp_bcopy.c2007-06-21
10:38:47.0 -0400
+++ new/drivers/infiniband/ulp/sdp/sdp_bcopy.c2007-08-31
12:25:58.0 -0400
@@ -224,13 +224,27 @@
/* Now, allocate and repost recv */
/* TODO: allocate from cache */
+
+#if (PROPOSED_SDP_FIX == 1)
+skb = sk_stream_alloc_skb(ssk-isk.sk, SDP_HEAD_SIZE,
+(ssk-isk.sk.sk_allocation == 0) ? (GFP_KERNEL) :
+ssk-isk.sk.sk_allocation);
+#else
skb = sk_stream_alloc_skb(ssk-isk.sk, SDP_HEAD_SIZE,
GFP_KERNEL);
+#endif
/* FIXME */
BUG_ON(!skb);
h = (struct sdp_bsdh *)skb-head;
for (i = 0; i ssk-recv_frags; ++i) {
+#if (PROPOSED_SDP_FIX == 1)
+page = alloc_pages((ssk-isk.sk.sk_allocation == 0)
+? (GFP_HIGHUSER) :
+(ssk-isk.sk.sk_allocation | (__GFP_HIGHMEM)),
+0);
+#else
page = alloc_pages(GFP_HIGHUSER, 0);
+#endif
BUG_ON(!page);
frag = skb_shinfo(skb)-frags[i];
frag-page= page;
@@ -406,10 +420,18 @@
ssk-tx_head - ssk-tx_tail SDP_TX_SIZE) {
struct sdp_chrecvbuf *resp_size;
ssk-recv_request = 0;
+#if (PROPOSED_SDP_FIX == 1)
+skb = sk_stream_alloc_skb(ssk-isk.sk,
+sizeof(struct sdp_bsdh) +
+sizeof(*resp_size),
+(ssk-isk.sk.sk_allocation == 0) ? (GFP_KERNEL) :
+
[ofa-general] MD lists
Only until Sep 28 - When you purchase the Physician Directory at the sale price
you will also get Hospital, Nursing Home, Dentist and Chiropractor data
completely free!
Licensed Physicians in the USA
788,818 in total 17,400 emails
Featuring coverage for more than 30 specialties like Internal Medicine, Family
Practice, Opthalmology, Anesthesiologists, Cardiologists and more
Many unique fields like 'medical school attended' and 'location of residency
training'
Price for this week only = $380
*** FREE OFFER: Get the 4 directories below for FREE with the purchase of the
Doctor data ***
Hospitals in the USA
23,000 Admins in more than 7,000 hospitals {a $399 value]
Database of American Dentists
A complete List or dentists and related services (valued at $299)
US Nursing Home List
Full data for CFO, Nursing Directors, Senior Admins [ worth $249 alone ]
American Chiropractors Database
100k Chiropractors offices with full contact data including email, postal
address, phone and fax
send us an email: [EMAIL PROTECTED]
put cease in the subject of an email to us if you'd rather not be contacted
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Re: [PATCH 1/11] IB/ipoib: high dma support
So, in order to support HIGHMEM, I would need to change the
ipath_dma_*() functions to call kmap()/kunmap() for HIGHMEM pages.
I'm sure there would be all kinds of performance and coding issues
around doing this.
So, we need some kind of HIGHDMA capability flag?
I don't think so. An RDMA adapter that can't handle highmem pages
would be kind of pointless: you wouldn't be able to handle userspace
memory regions, for one thing.
So if ipath ever tries to handle 32-bit kernels then I think handling
highmem will be part of it.
Actually, maybe something like this probably makes sense for IPoIB
while we're at it:
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
index 08b4676..dbc845f 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
@@ -129,7 +129,7 @@ static struct sk_buff *ipoib_cm_alloc_rx_skb(struct
net_device *dev, int id, int
}
for (i = 0; i frags; i++) {
- struct page *page = alloc_page(GFP_ATOMIC);
+ struct page *page = alloc_page(GFP_ATOMIC | GFP_HIGHUSER);
if (!page)
goto partial_error;
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Re: [PATCH 11/11]: mlx4_core use fixed CQ moderation paramters
+static int cq_max_count = 16; +static int cq_period = 10; + +module_param(cq_max_count, int, 0444); +MODULE_PARM_DESC(cq_max_count, number of CQEs to generate event); +module_param(cq_period, int, 0444); +MODULE_PARM_DESC(cq_period, time in usec for CQ event generation); I assume this is just a leftover from some earlier approach? These module parameters are just ignored now, so the patch seems kind of pointless. Anyway I think the approach of having one global setting for all CQs is not a good one -- it seems likely that for example IPoIB and SDP would want different settings, not to mention userspace applications. - R. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: [PATCH 1/11] IB/ipoib: high dma support
+struct page *page = alloc_page(GFP_ATOMIC | GFP_HIGHUSER); actually: + struct page *page = alloc_page(GFP_ATOMIC | __GFP_HIGHMEM); - R. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] [PATCH] IB/core - possible bug in handling link down in ib_sa_join_multicast()
git://git.openfabrics.org/~shefty/rdma-dev.git for-roland Thanks, I queued the Ralph's patch for 2.6.24 ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] [Bug report / partial patch] OFED 1.3 send max_sge lower than reported by ib_query_device
This is a two part bug report. One is a conceptual problem that may just be
a problem of understanding on my part. The other is
what I believe to be a bug in the mlx4 driver.
1) ib_create_qp() fails with max_sge
If you use ib_query_device() to return the device specific
attribute max_sge, it seems reasonable to expect you can create
a QP with max_send_sge=max_sge. The problem is that this often
fails.
The reason is that depending on the QP type (RC, UD, etc.) and
how the QP will be used (send, RDMA, atomic, etc.), there can be
extra segments required in the WQE that eat up SGE entries. So
while some send WQE might have max_sge available SGEs, many will
not.
Normally the difference between max_sge and the actual maximum
value allowed (and checked) for max_send_sge is 1 or 2.
This issue may need API extensions to definitively resolve. In
the short term, it would be very nice if max_sge reported by
ib_query_device() could always return a value that ib_create_qp()
could use. Think of it as the minimum max_send_sge value that
will work for all QP types.
2) mlx4 setting of max send SQEs
The recent patch to support shrinking WQEs introduces a
behavior that creates a big difference between the mlx4
supported send SGEs (checked against 61, should be 59 or 60,
and reported in ib_query_device as 32 to equal receive side
max_rq_sg value).
The patch that follows will allow an MLX4 to support the
number of send SGEs returned by ib_query_devce, and in fact
quite a few more. It probably breaks shrinking WQEs and thus
should not be applied directly.
Note that if ib_query_device() returned max_sge adjusted
for the raddr and atomic segments, this fix would not be
needed. MLX4 would still support more SGEs in hardware than
can be used through the API, but that is a different problem.
--- ofa_1_3_dev_kernel.orig/drivers/infiniband/hw/mlx4/qp.c 2007-09-26
13:27:47.0 -0500
+++ ofa_1_3_dev_kernel/drivers/infiniband/hw/mlx4/qp.c 2007-09-26
13:36:40.0 -0500
@@ -370,7 +370,7 @@ static int set_kernel_sq_size(struct mlx
qp-sq.wqe_shift = ilog2(roundup_pow_of_two(s));
for (;;) {
- if (1 qp-sq.wqe_shift dev-dev-caps.max_sq_desc_sz)
+ if (s dev-dev-caps.max_sq_desc_sz)
return -EINVAL;
qp-sq_max_wqes_per_wr = DIV_ROUND_UP(s, 1 qp-sq.wqe_shift);
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Re: [PATCH] mlx4: display misc device information via sysfs under /sys/class/infiniband/mlx4_x, for ibstat and ibv_devinfo
Thanks, applied with the cleanup suggested by MST. BTW when applying I had to edit the patch, because of: MLX4_MGM_ENTRY_SIZE = 0x100, this context didn't match the upstream kernel (I see 0x40 there). Is there some reason you have a bigger size in your tree? If so should we make the change upstream too? Also I deobfuscated as below: diff --git a/drivers/net/mlx4/main.c b/drivers/net/mlx4/main.c index be3c6fc..9e590e1 100644 --- a/drivers/net/mlx4/main.c +++ b/drivers/net/mlx4/main.c @@ -524,8 +524,8 @@ static int __devinit mlx4_init_hca(struct mlx4_dev *dev) } priv-eq_table.inta_pin = adapter.inta_pin; - priv-dev.rev_id= adapter.revision_id; - memcpy(priv-dev.board_id, adapter.board_id, sizeof priv-dev.board_id); + dev-rev_id = adapter.revision_id; + memcpy(dev-board_id, adapter.board_id, sizeof dev-board_id); return 0; ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] [Bug report / partial patch] OFED 1.3 send max_sge lower than reported by ib_query_device
1) ib_create_qp() fails with max_sge If you use ib_query_device() to return the device specific attribute max_sge, it seems reasonable to expect you can create a QP with max_send_sge=max_sge. The problem is that this often fails. The reason is that depending on the QP type (RC, UD, etc.) and how the QP will be used (send, RDMA, atomic, etc.), there can be extra segments required in the WQE that eat up SGE entries. So while some send WQE might have max_sge available SGEs, many will not. This issue may need API extensions to definitively resolve. In the short term, it would be very nice if max_sge reported by ib_query_device() could always return a value that ib_create_qp() could use. Think of it as the minimum max_send_sge value that will work for all QP types. The intention is that any attempt to create a QP with the maximum number of S/G entries as reported by query device should succeed. However, as you note there may be issues that make this fail, but I would consider them as bugs to be fixed. You mention API extensions to handle this -- do you have any concrete ideas? In the past we've talked a little about this, but I don't think anyone has suggested any changes that would help matters while still keeping the API no more complex than it already is. The recent patch to support shrinking WQEs introduces a behavior that creates a big difference between the mlx4 supported send SGEs (checked against 61, should be 59 or 60, and reported in ib_query_device as 32 to equal receive side max_rq_sg value). I'm not sure I understand this. What's the new behavior? Are you trying to take advantage of the fact that using non-power-of-2 size send WQEs would let you have a send queue with more than 32 S/G entries? I think doing that actually would require a change in the API to allow different values for max_sge_rq and max_sge_sq to be reported from ib_query_device(). Which in turn would break the userspace ABI, etc, etc. and leaves me wondering if it's really worth it. (BTW I hate the shrinking WQE terminology for this, although obviously you weren't the one to introduce it) - R. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Re: [PATCH RFC v2] IB/ipoib: enable IGMP for userpsace multicast IB apps
To support this inter-op for the case where the receiving party resides at
the IB side, there is a need to handle IGMP (reports/queries) else the local
IP router would not forward multicast traffic towards the IB network.
This patch does a lookup on the database used for multicast reference
counting and
enhances IPoIB to ignore mulicast group which is already handled by user
space, all
this under a per device policy flag. That is when the policy flag allows it,
IPoIB
will not join and attach its QP to a multicast group which has an entry on
the database.
I don't really follow this explanation. OK, I see in the first
paragraph that you want to handle IGMP. How does the second paragraph
follow? Why does IGMP mean the kernel IPoIB interface should avoid
joining certain multicast groups? (Which groups?)
+/* ignore group which is directly joined by user space
*/
+if (test_bit(IPOIB_FLAG_ADMIN_UMCAST_ALLOWED,
priv-flags)
+!ib_sa_get_mcmember_rec(priv-ca, priv-port,
mgid, rec))
I don't follow this. Why does ib_sa_get_mcmember_rec() returning 0
imply that userspace has already joined the multicast group?
+module_param_named(umcast_allowed, ipoib_umcast_allowed, int, 0444);
Not sure I understand why you added the module parameter...
+static DEVICE_ATTR(umcast, S_IWUSR | S_IRUGO, show_umcast, set_umcast);
The set_umcast attribute is writable by root anyway so why are there
two ways of setting this?
+if (!strcmp(buf, 1\n)) {
I don't think this is the most robust way of parsing things. for
example it will break in a very confusing way if someone uses echo -n
Could you use simple_strtoul() or something like that to handle
leading/trailing whitespace etc?
- R.
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] [PATCH-2.6.24 2/2] [RFC] ib/cm: add basic performance counters
The userspace IB CM is exported through /sys/class/infiniband_cm. Does anyone object to placing the counters under this same directory? I think that would be fine, with the usual one-value-per-file sysfs rules. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: [PATCH] uDAPL 2.0 mods to co-exist with uDAPL 1.2
On Mon, 24 Sep 2007, Arlin Davis wrote: --- a/test/dtest/dtest.c +++ b/test/dtest/dtest.c @@ -44,7 +44,7 @@ #include inttypes.h #ifndef DAPL_PROVIDER -#define DAPL_PROVIDER OpenIB-cma +#define DAPL_PROVIDER OpenIB-2-cma Should we update OpenIB to ofa? Obviously, this isn't necessary as part of this change I didn't want to change the 1.2 names for compatibility reasons but for 2.0 we could move to ofa names for both libraries and provider names. For example, libdaplcma.so becomes libdaplofa.so, OpenIB-cma becomes ofa. For example dat.conf 2.0 entries would look like this: ofa u2.0 nonthreadsafe default libdaplofa.so dapl.2.0 ib0 0 ofa-1 u2.0 nonthreadsafe default libdaplofa.so dapl.2.0 ib1 0 ofa-2 u2.0 nonthreadsafe default libdaplofa.so dapl.2.0 ib2 0 ofa-3 u2.0 nonthreadsafe default libdaplofa.so dapl.2.0 ib3 0 ofa-bond u2.0 nonthreadsafe default libdaplofa.so dapl.2.0 bond0 0 Is that what you had in mind? Yes. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [ofa-general] [Bug report / partial patch] OFED 1.3 send max_sge lower than reported by ib_query_device
This problem comes about because ib_query_device() has only one field (max_sge) to return all types of SGE maximums. This value must work for receive WQEs, send WQEs, and all the permutations of QP type and hardware. A minimal API change that could help would be to add two new fields to ib_device_attr structure returned by ib_query_device: - delta_sge_sg - delta_sge_rd The behavior would be that in all cases using max_sge for send or receive SGE count in create_qp would always succeed. That means the current value the drivers return there would have to be reduced to fix this bug. All existing codes would continue to run. If an application wanted to better use hardware that supports asymmetric SGE counts, it could add the appropriate delta_sge_xx value to max_sge and get more useful value. It looks like there is some movement in this direction already with the fields: - max_sge_rd (nes, amso1100, ehca, cxgb3 only) - max_srq_sge (amso1100, mthca, mlx4, ehca, ipath only) If we do add any new fields to deal with this problem, we should probably make sure all the drivers support them. I guess that portable applications check max_sge_rd and max_srp_sge for zero and use max_sge if they are? To fully solve the problem and let applications make optimal use of hardware, we probably need a new function that takes the create_qp parameters along with a list of OPCODEs to be used (or excluded?) on this QP and returns the actual send and receive SGE maximums. The issue with the shrinking WQE (sorry) is best shown by example. The MLX4 supports a send WQE that is 1008 bytes long unless you are doing RDMA_READ when you can only use 512 byte send WQEs. A receive WQE can be 512 bytes maximum. Ignore the non-power-of-2 size stuff and just assume that all WQEs are fixed size power-of-2 with maximums of 1024 or 512. This is 63 or 32 segments. One segment for ctrl means that we get max_sge_rq of 31 and a matrix for max_sge_sq: RDMA_READ : 30 (raddr) RDMA_WRITE: 61 (raddr) SEND-RC : 62 SEND-UD : 59 (AV, AV, dest) The problem with: if (1 qp-sq.wqe_shift dev-dev-caps.max_sq_desc_sz) is that since max_sq_desc is 1008 instead of 1024 we are forced to use wqe_shift of 9 instead of 10. That means that even though the hardware supports an RC send with 62 SGEs, the most we can actually ask for is 31. All this brings us back to the original bug. ib_query_device() returned max_sge=32, so we use it in max_send_sge when we create a QP. In mlx4/qp.c, we verify max_send_sge = max_sq_sg (62; 1008-16) in a sanity check at entry to set_kernel_sq_size(). This passes. Then we calculate the size of the WQE based on the QP type: cap-max_send_sge * sizeof (struct mlx4_wqe_data_seg) + send_wqe_overhead(type); The send_wqe_overhead(RC) function returns 3 segments: - ctrl + atomic + raddr So we get a WQE size of 560 bytes (32 SGEs + 3 overhead segments) and this fails the power-of-2 test because 1024 is greater than 1008. Sorry for all the words. -Original Message- From: Roland Dreier [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 26, 2007 3:03 PM To: Jim Mott Cc: general@lists.openfabrics.org Subject: Re: [ofa-general] [Bug report / partial patch] OFED 1.3 send max_sge lower than reported by ib_query_device 1) ib_create_qp() fails with max_sge If you use ib_query_device() to return the device specific attribute max_sge, it seems reasonable to expect you can create a QP with max_send_sge=max_sge. The problem is that this often fails. The reason is that depending on the QP type (RC, UD, etc.) and how the QP will be used (send, RDMA, atomic, etc.), there can be extra segments required in the WQE that eat up SGE entries. So while some send WQE might have max_sge available SGEs, many will not. This issue may need API extensions to definitively resolve. In the short term, it would be very nice if max_sge reported by ib_query_device() could always return a value that ib_create_qp() could use. Think of it as the minimum max_send_sge value that will work for all QP types. The intention is that any attempt to create a QP with the maximum number of S/G entries as reported by query device should succeed. However, as you note there may be issues that make this fail, but I would consider them as bugs to be fixed. You mention API extensions to handle this -- do you have any concrete ideas? In the past we've talked a little about this, but I don't think anyone has suggested any changes that would help matters while still keeping the API no more complex than it already is. The recent patch to support shrinking WQEs introduces a behavior that creates a big difference between the mlx4 supported send SGEs (checked against 61, should be 59 or 60, and reported in ib_query_device as 32 to equal receive side max_rq_sg value). I'm not sure I understand this. What's
Re: [ofa-general] [Bug report / partial patch] OFED 1.3 send max_sge lower than reported by ib_query_device
A minimal API change that could help would be to add two new fields to ib_device_attr structure returned by ib_query_device: - delta_sge_sg - delta_sge_rd Hmm, a cute idea but I'm still left wondering if it's worth the ABI breakage etc just to give a few more S/G entries in some situations. The behavior would be that in all cases using max_sge for send or receive SGE count in create_qp would always succeed. That means the current value the drivers return there would have to be reduced to fix this bug. All existing codes would continue to run. Actually are there any drivers other than patched mlx4 where max_sge doesn't always work? I agree we do want to get this right, but I thought we had fixed all such bugs. (And we should make sure that any shrinking WQE patch for mlx4 doesn't introduce new bugs) (BTW I see a different bug in unpatched mlx4, namely that it might report a too-big number of S/G entries allowed for the SQ) It looks like there is some movement in this direction already with the fields: - max_sge_rd (nes, amso1100, ehca, cxgb3 only) This field is obsolete, since we don't handle RD and almost certainly never will. I'm not sure why anyone is setting a value. - max_srq_sge (amso1100, mthca, mlx4, ehca, ipath only) Any devices that handle SRQ should set this. I think cxgb3 does not support SRQ. - R. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] ibnetdiscover topology output
On Tuesday 25 September 2007 04:30:48 pm Jeff Becker wrote: Hi Sasha. Thanks for the info. I did have the following problem when building against the 1.2 libibmad: cc -Wall -g -fpic -I. -I../include -I/home/becker//include -c -o sim_mad.o sim_mad.c sim_mad.c: In function 'encode_trap144': sim_mad.c:1261: error: 'IB_NOTICE_DATA_144_LID_F' undeclared (first use in this function) sim_mad.c:1261: error: (Each undeclared identifier is reported only once sim_mad.c:1261: error: for each function it appears in.) sim_mad.c:1262: error: 'IB_NOTICE_DATA_144_CAPMASK_F' undeclared (first use in this function) make[1]: *** [sim_mad.o] Error 1 make[1]: Leaving directory `/home/becker/ibrouting/ibsim/ibsim' And indeed those have been introduced by this patch in 1.2.5: http://lists.openfabrics.org/pipermail/general/2007-June/036912.html Cheers, -- Kilian ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] [PATCH-2.6.24 2/2] [RFC] ib/cm: add basic performance counters
The userspace IB CM is exported through /sys/class/infiniband_cm. Does anyone object to placing the counters under this same directory? I think that would be fine, with the usual one-value-per-file sysfs rules. Er, I could use some help here. Is there a preferred way to share /sys/class/infiniband_cm between the ib_cm and ib_user_cm modules? Currently, ib_user_cm registers the infiniband_cm class and registers devices (ucm0, ucm1, ...) on that class. It ends up making use of the infiniband_cm class 'release' callback for this. I want to make sure that I'm not overlooking some simple way of maintaining this while letting the ib_cm module stick statistics under it. - Sean ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [ofa-general] SDP memory allocation policy problem?
I have reworked your patch slightly and run my simple unit tests on it. No
correctness problems detected in latency or bandwidth
paths. No performance regressions either.
If your proposed patch worked for you, then this one ought to work too. Could
you please give it a go and let me know?
Index: ofa_1_3_dev_kernel/drivers/infiniband/ulp/sdp/sdp_bcopy.c
===
--- ofa_1_3_dev_kernel.orig/drivers/infiniband/ulp/sdp/sdp_bcopy.c
2007-09-26 13:27:43.0 -0500
+++ ofa_1_3_dev_kernel/drivers/infiniband/ulp/sdp/sdp_bcopy.c 2007-09-26
17:52:12.0 -0500
@@ -221,16 +221,26 @@ static void sdp_post_recv(struct sdp_soc
skb_frag_t *frag;
struct sdp_bsdh *h;
int id = ssk-rx_head;
+ unsigned int gfp_page;
/* Now, allocate and repost recv */
/* TODO: allocate from cache */
- skb = sk_stream_alloc_skb(ssk-isk.sk, SDP_HEAD_SIZE,
- GFP_KERNEL);
+
+ if (unlikely(ssk-isk.sk.sk_allocation)) {
+ skb = sk_stream_alloc_skb(ssk-isk.sk, SDP_HEAD_SIZE,
+ ssk-isk.sk.sk_allocation);
+ gfp_page = ssk-isk.sk.sk_allocation | __GFP_HIGHMEM;
+ } else {
+ skb = sk_stream_alloc_skb(ssk-isk.sk, SDP_HEAD_SIZE,
+ GFP_KERNEL);
+ gfp_page = GFP_HIGHUSER;
+ }
+
/* FIXME */
BUG_ON(!skb);
h = (struct sdp_bsdh *)skb-head;
for (i = 0; i ssk-recv_frags; ++i) {
- page = alloc_pages(GFP_HIGHUSER, 0);
+ page = alloc_pages(gfp_page, 0);
BUG_ON(!page);
frag = skb_shinfo(skb)-frags[i];
frag-page= page;
@@ -404,6 +414,7 @@ void sdp_post_sends(struct sdp_sock *ssk
/* TODO: nonagle? */
struct sk_buff *skb;
int c;
+ int gfp_page;
if (unlikely(!ssk-id)) {
if (ssk-isk.sk.sk_send_head) {
@@ -415,6 +426,11 @@ void sdp_post_sends(struct sdp_sock *ssk
return;
}
+ if (unlikely(ssk-isk.sk.sk_allocation))
+ gfp_page = ssk-isk.sk.sk_allocation;
+ else
+ gfp_page = GFP_KERNEL;
+
if (ssk-recv_request
ssk-rx_tail = ssk-recv_request_head
ssk-bufs = SDP_MIN_BUFS
@@ -424,7 +440,7 @@ void sdp_post_sends(struct sdp_sock *ssk
skb = sk_stream_alloc_skb(ssk-isk.sk,
sizeof(struct sdp_bsdh) +
sizeof(*resp_size),
- GFP_KERNEL);
+ gfp_page);
/* FIXME */
BUG_ON(!skb);
resp_size = (struct sdp_chrecvbuf *)skb_put(skb, sizeof
*resp_size);
@@ -449,7 +465,7 @@ void sdp_post_sends(struct sdp_sock *ssk
skb = sk_stream_alloc_skb(ssk-isk.sk,
sizeof(struct sdp_bsdh) +
sizeof(*req_size),
- GFP_KERNEL);
+ gfp_page);
/* FIXME */
BUG_ON(!skb);
ssk-sent_request = SDP_MAX_SEND_SKB_FRAGS * PAGE_SIZE;
@@ -480,7 +496,7 @@ void sdp_post_sends(struct sdp_sock *ssk
ssk-bufs) {
skb = sk_stream_alloc_skb(ssk-isk.sk,
sizeof(struct sdp_bsdh),
- GFP_KERNEL);
+ gfp_page);
/* FIXME */
BUG_ON(!skb);
sdp_post_send(ssk, skb, SDP_MID_DISCONN);
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Dauchy
Sent: Tuesday, September 25, 2007 5:50 PM
To: general@lists.openfabrics.org
Subject: Re: [ofa-general] SDP memory allocation policy problem?
Is there anyone among the OFED development team that is looking into
this issue? I believe that it is causing nodes to hang at our site. We
are running ofed-1.2 and the 2.6.9-55.ELsmp kernel.
Workarounds or even untested patches would be appreciated.
Thanks!
-Nathan
Ken Phillips wrote:
Greetings,
Teammates here report the following:
Problem
The method SDP uses to allocate socket buffers may cause the
node to hang under memory pressure.
Details
Each kernel level socket has an allocation flag to specify the
memory allocation policy for socket buffers, the default is GFP_ATOMIC
(or GFP_KERNEL for SDP). If the caller creates a socket with the
policy set to GFP_NOFS or GFP_NOIO this should be the allocation
policy used by the SDP layer.
The problem we are seeing is that if a node is under load, and
a memory allocation fails (say in sock_sendmsg()), the kernel will
RE: [ofa-general] [Bug report / partial patch] OFED 1.3 send max_sge lower than reported by ib_query_device
The same bug exists with mthca. I saw it originally in the kernel doing RDS work, but I just put together a short user space test. ibv_query_device(MT25204) returns max_sge=30 - ibv_create_qp with qp_attr.cap.max_send_sge = dev_attr.max_sge fails - ibv_create_qp with qp_attr.cap.max_send_sge = dev_attr.max_sge-1 works I only have the two types of adapters to test with. -Original Message- From: Roland Dreier [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 26, 2007 5:32 PM To: Jim Mott Cc: general@lists.openfabrics.org Subject: Re: [ofa-general] [Bug report / partial patch] OFED 1.3 send max_sge lower than reported by ib_query_device A minimal API change that could help would be to add two new fields to ib_device_attr structure returned by ib_query_device: - delta_sge_sg - delta_sge_rd Hmm, a cute idea but I'm still left wondering if it's worth the ABI breakage etc just to give a few more S/G entries in some situations. The behavior would be that in all cases using max_sge for send or receive SGE count in create_qp would always succeed. That means the current value the drivers return there would have to be reduced to fix this bug. All existing codes would continue to run. Actually are there any drivers other than patched mlx4 where max_sge doesn't always work? I agree we do want to get this right, but I thought we had fixed all such bugs. (And we should make sure that any shrinking WQE patch for mlx4 doesn't introduce new bugs) (BTW I see a different bug in unpatched mlx4, namely that it might report a too-big number of S/G entries allowed for the SQ) It looks like there is some movement in this direction already with the fields: - max_sge_rd (nes, amso1100, ehca, cxgb3 only) This field is obsolete, since we don't handle RD and almost certainly never will. I'm not sure why anyone is setting a value. - max_srq_sge (amso1100, mthca, mlx4, ehca, ipath only) Any devices that handle SRQ should set this. I think cxgb3 does not support SRQ. - R. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] [Bug report / partial patch] OFED 1.3 send max_sge lower than reported by ib_query_device
The same bug exists with mthca. I saw it originally in the kernel doing RDS work, but I just put together a short user space test. ibv_query_device(MT25204) returns max_sge=30 - ibv_create_qp with qp_attr.cap.max_send_sge = dev_attr.max_sge fails - ibv_create_qp with qp_attr.cap.max_send_sge = dev_attr.max_sge-1 works Which transport type? - R. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [ofa-general] [Bug report / partial patch] OFED 1.3 send max_sge lower than reported by ib_query_device
FWIW, I have code in my apps that retries QP creation with reduced values when the allocation with max fails. There was also an earlier e-mail thread on this exact same issue, but the solution bantered about was to use special values in the qp_attr structure ala QP_MAX_SEND_SGE (-1?). The provider would recognize this value and allocate the max for that attribute that would succeed given the current resource situation. The qp_attr structure would then be updated by the provider with the values given. This approach extends, but doesn't break the API, allows existing apps to work as usual, and avoids the retry logic that I've added to my apps. Just a thought, Tom On Wed, 2007-09-26 at 20:41 -0500, Jim Mott wrote: The same bug exists with mthca. I saw it originally in the kernel doing RDS work, but I just put together a short user space test. ibv_query_device(MT25204) returns max_sge=30 - ibv_create_qp with qp_attr.cap.max_send_sge = dev_attr.max_sge fails - ibv_create_qp with qp_attr.cap.max_send_sge = dev_attr.max_sge-1 works I only have the two types of adapters to test with. -Original Message- From: Roland Dreier [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 26, 2007 5:32 PM To: Jim Mott Cc: general@lists.openfabrics.org Subject: Re: [ofa-general] [Bug report / partial patch] OFED 1.3 send max_sge lower than reported by ib_query_device A minimal API change that could help would be to add two new fields to ib_device_attr structure returned by ib_query_device: - delta_sge_sg - delta_sge_rd Hmm, a cute idea but I'm still left wondering if it's worth the ABI breakage etc just to give a few more S/G entries in some situations. The behavior would be that in all cases using max_sge for send or receive SGE count in create_qp would always succeed. That means the current value the drivers return there would have to be reduced to fix this bug. All existing codes would continue to run. Actually are there any drivers other than patched mlx4 where max_sge doesn't always work? I agree we do want to get this right, but I thought we had fixed all such bugs. (And we should make sure that any shrinking WQE patch for mlx4 doesn't introduce new bugs) (BTW I see a different bug in unpatched mlx4, namely that it might report a too-big number of S/G entries allowed for the SQ) It looks like there is some movement in this direction already with the fields: - max_sge_rd (nes, amso1100, ehca, cxgb3 only) This field is obsolete, since we don't handle RD and almost certainly never will. I'm not sure why anyone is setting a value. - max_srq_sge (amso1100, mthca, mlx4, ehca, ipath only) Any devices that handle SRQ should set this. I think cxgb3 does not support SRQ. - R. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [ofa-general] [Bug report / partial patch] OFED 1.3 send max_sge lower than reported by ib_query_device
IBV_QPT_RC -Original Message- From: Roland Dreier [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 26, 2007 8:57 PM To: Jim Mott Cc: general@lists.openfabrics.org Subject: Re: [ofa-general] [Bug report / partial patch] OFED 1.3 send max_sge lower than reported by ib_query_device The same bug exists with mthca. I saw it originally in the kernel doing RDS work, but I just put together a short user space test. ibv_query_device(MT25204) returns max_sge=30 - ibv_create_qp with qp_attr.cap.max_send_sge = dev_attr.max_sge fails - ibv_create_qp with qp_attr.cap.max_send_sge = dev_attr.max_sge-1 works Which transport type? - R. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] nightly osm_sim report 2007-09-27:normal completion
OSM Simulation Regression Summary [Generated mail - please do NOT reply] OpenSM binary date = 2007-09-26 OpenSM git rev = Tue_Sep_25_00:30:00_2007 [2c547953885809a8026e20af7809be08b42c3865] ibutils git rev = Tue_Sep_4_17:57:34_2007 [4bf283f6a0d7c0264c3a1d2de92745e457585fdb] Total=520 Pass=520 Fail=0 Pass: 39 Stability IS1-16.topo 39 Pkey IS1-16.topo 39 OsmTest IS1-16.topo 39 OsmStress IS1-16.topo 39 Multicast IS1-16.topo 39 LidMgr IS1-16.topo 13 Stability IS3-loop.topo 13 Stability IS3-128.topo 13 Pkey IS3-128.topo 13 OsmTest IS3-loop.topo 13 OsmTest IS3-128.topo 13 OsmStress IS3-128.topo 13 Multicast IS3-loop.topo 13 Multicast IS3-128.topo 13 LidMgr IS3-128.topo 13 FatTree merge-roots-4-ary-2-tree.topo 13 FatTree merge-root-4-ary-3-tree.topo 13 FatTree gnu-stallion-64.topo 13 FatTree blend-4-ary-2-tree.topo 13 FatTree RhinoDDR.topo 13 FatTree FullGnu.topo 13 FatTree 4-ary-2-tree.topo 13 FatTree 2-ary-4-tree.topo 13 FatTree 12-node-spaced.topo 13 FTreeFail 4-ary-2-tree-missing-sw-link.topo 13 FTreeFail 4-ary-2-tree-links-at-same-rank-2.topo 13 FTreeFail 4-ary-2-tree-links-at-same-rank-1.topo 13 FTreeFail 4-ary-2-tree-diff-num-pgroups.topo Failures: ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] OFA Kernel for XenIB
Hi, I have been working with the xen-smartio source tree from the xensource site and wanted to whether this kernel is a different implementation for XenIB. Also does this kernel be used in place of the xen0 kernel? Does anyone have pointers on how kernel can be used.. there doesnt seem to be any readme on the install process? Thanks, Adit -- Adit Ranadive MS CS Candidate Georgia Institute of Technology, Atlanta, GA ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
