Re: [openib-general] RE: [PATCH][iWARP] IW CM Verbs
On Fri, Aug 26, 2005 at 12:01:09PM -0700, Sean Hefty wrote:
> >Please comment, and if it looks good, I'll commit this to the
> >iWARP branch tonight.
>
> Looks fine. See one minor comment below.
>
>
> >+/* This is provided in the event generated by a remote
> >+ * connect request to a listening endpoint
> >+ */
> >+struct iw_conn_request {
> >+int cr_id;
> >+struct iw_conn_attr conn_attr;
> >+u8 *private_data;
> >+int private_data_len;
> >+};
>
> Should cr_id be an int or something more along the lines of struct iw_cm_id *?
"unsigned int" if possible please.
thanks,
grant
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] RDMA connection and address translation API
> -Original Message- > From: Guy German [mailto:[EMAIL PROTECTED] > Sent: Friday, August 26, 2005 12:28 PM > To: Caitlin Bestler; Sean Hefty; James Lentini > Cc: openib-general@openib.org > Subject: RE: [openib-general] RDMA connection and address > translation API > > > What do you think about this flow ? > > 1. resolve device and port from ip address - synchronous operation > >(like at.c resolve_ip) > > 2. rdma_create_qp (device+port) - modifies qp to init with default > > pkey index 3. ib_post_recvs(...); 4. cma_connect - > asynchronous at, > > modify qp with correct pkey index, cm_connect > > Caitlin wrote: > >At least with iWARP a QP is not bound to a specific port, or > even to an > >IP Address. It is only bound to the RDMA Device (RNIC) and > Protection > >Domain. The same QP can be re-used for a new connection with > a new IP > >address. Indeed, that is exactly what would happen with > >application-layer controlled failover (such as iSER). > > In ib, in order to post receive the QP need to be in init. > In order to modify qp to init, you need port and pkey_index. > If iWARP can post receive without it, the iwarp > implementation of "rdma_create_qp" can ignore the port attribute. > The closest equivalent of a pkey_index would be the VLAN ID, which is at L2 and totally transparent to an iWARP QP. You can definitely post receive buffers before knowing anything about the TCP connection (or SCTP association/stream) that will provide the LLP service. > The other option, that was suggested to solve the sync > problem (need of post receive before connect) is to retrieve > the path synchronically, which will require an unnecessary > upcall handling for iwarp consumers. > The generic requirement is that the QP passed to the connect method is ready to be moved to a connected state as soon as the connection establishment exchanges have finished. If I follow what you are proposing, you are trying to find a way to do this for IB automatically as a by-product of determining what device to use. I don't see any problem with this, as long as the "port" being returned from the first call is defined in such a way that it can have a void value when the transport does not need this refinement. Avoiding transport-dependent steps is good for encouraging development of RDMA-aware applications. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH] IBAT resolve_ats_route
Hi Hal,
I was reading through the IBAT sources when I noticed that in
resolve_ats_route() you set req->pend.sa_query to null on line 1127
and then check to see if it is null a few lines later. I don't think
you need to do that.
Signed-off-by: James Lentini <[EMAIL PROTECTED]>
Index: at.c
===
--- at.c(revision 3204)
+++ at.c(working copy)
@@ -1134,10 +1134,6 @@ static int resolve_ats_route(struct rout
}
if (!rec) { /* new query */
- if (req->pend.sa_query) {
- DEBUG("req %p (%s) already pending", req, netdev->name);
- return -1;
- }
build_ats_req(&sa_rec, NULL, req->src.pkey, req->dst_ip);
rec = &sa_rec;
}
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] RDMA connection and address translation API
>What do you think about this flow ? >1. resolve device and port from ip address - synchronous operation > (like at.c resolve_ip) >2. rdma_create_qp (device+port) - modifies qp to init with default pkey index >3. ib_post_recvs(...); >4. cma_connect - asynchronous at, modify qp with correct pkey index, cm_connect >>It looks like this would work. If a client wanted to create multiple >>connections to the same remote service (for example, to separate control and >>data), then it seems more efficient to move the asynchronous at outside of the >>connect call. >>- Sean Thats a good point. What I had in mind was mainly simplicity for the consumer - save him dealing with another upcall. Maybe caching in at module would make things better, but I agree that for multiple connections to the same remote service, the asynchronous at aproach, seems more appropriate. So ... Does everyone else thinks that we should change the API of a cm abstraction to asynchronous at before connection ? (This should concern mostly the iWAPR guys - Caitlin,Tom etc..) Thanks, Guy ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] RDMA connection and address translation API
>What do you think about this flow ? >1. resolve device and port from ip address - synchronous operation > (like at.c resolve_ip) >2. rdma_create_qp (device+port) - modifies qp to init with default pkey index >3. ib_post_recvs(...); >4. cma_connect - asynchronous at, modify qp with correct pkey index, cm_connect It looks like this would work. If a client wanted to create multiple connections to the same remote service (for example, to separate control and data), then it seems more efficient to move the asynchronous at outside of the connect call. - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH][iWARP] IW CM Verbs
On 26.08.2005 [14:44:25 -0400], Tom Tucker wrote: > > This is a cleaned up version of the iWARP CM verbs based > on feedback from Roland and Sean. I've added a new file to > contain the iw specific types and changed the iw specific > type prefix to iw_. > > Please comment, and if it looks good, I'll commit this to the > iWARP branch tonight. Just a small nit about your mailer perhaps :) > int(*query_device)(struct ib_device > *device, Seems like lines are getting wrapped? Any chance to get around this? Makes it a bit hard to read the patches... Thanks, Nish ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] RDMA connection and address translation API
> What do you think about this flow ? > 1. resolve device and port from ip address - synchronous operation >(like at.c resolve_ip) > 2. rdma_create_qp (device+port) - modifies qp to init with > default pkey index > 3. ib_post_recvs(...); > 4. cma_connect - asynchronous at, modify qp with correct > pkey index, cm_connect Caitlin wrote: >At least with iWARP a QP is not bound to a specific port, or even >to an IP Address. It is only bound to the RDMA Device (RNIC) and >Protection Domain. The same QP can be re-used for a new connection >with a new IP address. Indeed, that is exactly what would happen >with application-layer controlled failover (such as iSER). In ib, in order to post receive the QP need to be in init. In order to modify qp to init, you need port and pkey_index. If iWARP can post receive without it, the iwarp implementation of "rdma_create_qp" can ignore the port attribute. The other option, that was suggested to solve the sync problem (need of post receive before connect) is to retrieve the path synchronically, which will require an unnecessary upcall handling for iwarp consumers. Guy ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] Re: [PATCH][iWARP] Another CM Verbs Approach
I believe it would be safe to state that all hardware has one or more methods for transitioning an established TCP connection to RDMA mode. What will vary is what restrictions there are, and how easily that can be expanded. When the RNIC also provides TCP offload services the current firmware may only support transition from offloaded connections. However, accepting an upload of the TCP state from the driver is probably within the capability of most hardware. For one thing it is needed for failover and is quite useful for testing. So right now it may be common for existing firmware/drivers to only know how to extract the TCP state from a partner stack. There is no reason why the Linux stack could not be a partner stack, but kind of by definition no device vendor can just decide to make the linux stack a partner. The linux stack has some say in the matter. Nobody is going to eagerly write firmware that relies on extracting state information based on unpublished data structures that are subject to change without notice. Inter-module dependencies need to be planned, not just assumed by add-on software. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Roland Dreier > Sent: Friday, August 26, 2005 11:03 AM > To: Tom Tucker > Cc: openib-general@openib.org > Subject: [openib-general] Re: [PATCH][iWARP] Another CM Verbs Approach > > Roland> I'd like to understand that last bit above about devices > Roland> that establish connections internally. Does that mean > Roland> that there are RNICs that cannot support the iWARP verbs' > Roland> notion of migrating a connection? > > Tom> Yes, that's what it means and the reason is that Linux does > Tom> not (yet) provide a means to do so. > > Now I'm confused. Is the problem that the Linux network > stack does not have an interface for transferring TCP state, > or is it that some RNIC hardware does not support taking > control of an existing TCP connection? The first problem we > can fix, but the second one we can't. > > - R. > ___ > openib-general mailing list > openib-general@openib.org > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit > http://openib.org/mailman/listinfo/openib-general > > ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] kernel oops
>1. I rebooted both the machines, started opensm, after LID assignment >killed opensm. >Next started the ucmpost client/server, killing it panics the system This definitely shouldn't crash the systems, so there's a bug that needs to be fixed. But the tests will not work unless an SM is running somewhere on the fabric. - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] kernel oops
Still see the issue 1. I rebooted both the machines, started opensm, after LID assignment killed opensm. Next started the ucmpost client/server, killing it panics the system -Viswa Unable to handle kernel NULL pointer dereference at virtual address 0068 printing eip: c02f2635 *pde = 3661e001 Oops: [#1] SMP Modules linked in: nfsd exportfs lockd autofs4 sunrpc uhci_hcd ehci_hcd hw_random e1000 ext3 jbd sd_mod CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010086 (2.6.12.5) EIP is at _spin_lock_irqsave+0xa/0x51 eax: 0064 ebx: 0286 ecx: f689be6c edx: c036cbcc esi: 0064 edi: 0064 ebp: esp: f689be00 ds: 007b es: 007b ss: 0068 Process lt-ucmpost (pid: 3993, threadinfo=f689a000 task=f6ef9540) Stack: c013e3f0 c036cbcc c0267667 00d0 f689beac f66a9e80 c027393f c0350d00 f689be6c 0c30 0064 f689beac f66a9e80 c027955f 0c30 0064 00d0 c0279022 f66a9e80 Call Trace: [] __alloc_pages+0x166/0x3b6 [] ib_get_client_data+0x14/0x54 [] ib_sa_path_rec_get+0x1b/0x13e [] resolve_path+0x8c/0x15b [] path_req_complete+0x0/0xf7 [] rtnetlink_dump_all+0x0/0x9e [] rtnetlink_done+0x0/0x3 [] ib_at_paths_by_route+0xc4/0xd9 [] same_path_req+0x0/0x95 Sean Hefty wrote: I downloaded the latest openib gen2 stack and ran into kernel panic when I run the cmpost/ucmpost example. I modified the program to continously send and receive data in an infinite loop and killed the application with ctrl-c. The kernel panics pretty consistently. I am currently running 2.6.12 version of the kernel . Log attached. I will try upgrading to newer kernel and see if I can reproduce it. I have gotten something similar to this in my own testing, but haven't had the time to track it down. It seems to be related to how the IB AT code interacts with the SM, and if the SM has been restarted. Can you try resetting the SM node, then rebooting your other systems? - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] RE: [PATCH][iWARP] IW CM Verbs
>Please comment, and if it looks good, I'll commit this to the
>iWARP branch tonight.
Looks fine. See one minor comment below.
>+/* This is provided in the event generated by a remote
>+ * connect request to a listening endpoint
>+ */
>+struct iw_conn_request {
>+ int cr_id;
>+ struct iw_conn_attr conn_attr;
>+u8*private_data;
>+ int private_data_len;
>+};
Should cr_id be an int or something more along the lines of struct iw_cm_id *?
- Sean
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH][iWARP] IW CM Verbs
This is a cleaned up version of the iWARP CM verbs based
on feedback from Roland and Sean. I've added a new file to
contain the iw specific types and changed the iw specific
type prefix to iw_.
Please comment, and if it looks good, I'll commit this to the
iWARP branch tonight.
Signed-off-by: Tom Tucker < [EMAIL PROTECTED]>
Index: ib_verbs.h
===
--- ib_verbs.h (revision 3120)
+++ ib_verbs.h (working copy)
@@ -59,7 +59,8 @@
enum ib_node_type {
IB_NODE_CA = 1,
IB_NODE_SWITCH,
- IB_NODE_ROUTER
+ IB_NODE_ROUTER,
+ IB_NODE_RNIC
};
enum ib_device_cap_flags {
@@ -78,6 +79,7 @@
IB_DEVICE_RC_RNR_NAK_GEN= (1<<12),
IB_DEVICE_SRQ_RESIZE= (1<<13),
IB_DEVICE_N_NOTIFY_CQ = (1<<14),
+ IB_DEVICE_IWCM = (1<<15)
};
enum ib_atomic_cap {
@@ -804,6 +806,7 @@
struct ib_gid_cache **gid_cache;
};
+struct iw_cm;
struct ib_device {
struct device*dma_device;
@@ -820,6 +823,8 @@
u32 flags;
+ struct iw_cm *iwcm;
+
int(*query_device)(struct ib_device
*device,
struct ib_device_attr
*device_attr);
int(*query_port)(struct ib_device
*device,
Index: iw_cm.h
===
--- iw_cm.h (revision 0)
+++ iw_cm.h (revision 0)
@@ -0,0 +1,127 @@
+/*
+ * Copyright (c) 2005 Ammasso, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+#if !defined(IW_CM_H)
+#define IW_CM_H
+
+#include
+
+/* iWARP connection attributes. */
+struct iw_conn_attr {
+ struct in_addr local_addr;
+ struct in_addr remote_addr;
+ u16 local_port;
+ u16 remote_port;
+};
+
+/* This is provided in the event generated when
+ * a remote peer accepts our connect request
+ */
+struct iw_conn_results {
+ int errno;
+ struct iw_conn_attr conn_attr;
+u8 *private_data;
+ int private_data_len;
+};
+
+/* This is provided in the event generated by a remote
+ * connect request to a listening endpoint
+ */
+struct iw_conn_request {
+ int cr_id;
+ struct iw_conn_attr conn_attr;
+u8 *private_data;
+ int private_data_len;
+};
+
+/* Connection events. */
+enum iw_cm_event_type {
+ IW_EVENT_ACTIVE_CONNECT_RESULTS,
+ IW_EVENT_CONNECT_REQUEST
+};
+
+struct iw_cm_event {
+ struct iw_device*device;
+ union {
+ struct iw_conn_results active_results;
+ struct iw_conn_request conn_request;
+ } element;
+ enum iw_cm_event_type event;
+};
+
+/* Listening endpoint. */
+struct iw_listen_ep_attr {
+ void(*event_handler)(struct iw_cm_event *, void *);
+ void*listen_context;
+ struct in_addr addr;
+ u16 port;
+ int backlog;
+};
+
+struct iw_listen_ep {
+ struct iw_device*device;
+ void(*event_handler)(struct iw_cm_event *,
void *);
+ void*listen_context;
+ struct in_addr addr;
+ u16 port;
+ int backlog;
+};
+
+struct iw_cm {
+
+ int
[openib-general] RE: [PATCH][iWARP] Another CM Verbs Approach
> -Original Message- > From: Roland Dreier [mailto:[EMAIL PROTECTED] > Sent: Friday, August 26, 2005 1:03 PM > To: Tom Tucker > Cc: Roland Dreier; Sean Hefty; openib-general@openib.org > Subject: Re: [PATCH][iWARP] Another CM Verbs Approach > > Roland> I'd like to understand that last bit above about devices > Roland> that establish connections internally. Does that mean > Roland> that there are RNICs that cannot support the iWARP verbs' > Roland> notion of migrating a connection? > > Tom> Yes, that's what it means and the reason is that Linux does > Tom> not (yet) provide a means to do so. > > Now I'm confused. Is the problem that the Linux network stack does > not have an interface for transferring TCP state, or is it that some > RNIC hardware does not support taking control of an existing TCP > connection? The first problem we can fix, but the second one > we can't. Sorry for the confusion. Our current product does not currently support migrating connections. Our next device does. > > - R. > ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH][iWARP] Another CM Verbs Approach
Roland> I'd like to understand that last bit above about devices Roland> that establish connections internally. Does that mean Roland> that there are RNICs that cannot support the iWARP verbs' Roland> notion of migrating a connection? Tom> Yes, that's what it means and the reason is that Linux does Tom> not (yet) provide a means to do so. Now I'm confused. Is the problem that the Linux network stack does not have an interface for transferring TCP state, or is it that some RNIC hardware does not support taking control of an existing TCP connection? The first problem we can fix, but the second one we can't. - R. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] [PATCH][iWARP] Added provider CMverbsandqueryprovider methods
>I believe that what you are advocating is having a mini-TCP-stack >in Linux. This mini-TCP-stack knows how to establish connections >which are then passed down to the adpater. This mini-stack would >comprise the iWARP side of a unified connection manager. I not advocating this, but I believe that it is better than having mini-TCP stacks in each driver. This is why I'm trying to determine if the connection establishment done in iWarp is done in software or hardware. What you've done for your hardware seems correct. - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] RE: [PATCH][iWARP] Another CM Verbs Approach
> -Original Message- > From: Roland Dreier [mailto:[EMAIL PROTECTED] > Sent: Friday, August 26, 2005 12:53 PM > To: Tom Tucker > Cc: Sean Hefty; Roland Dreier; openib-general@openib.org > Subject: Re: [PATCH][iWARP] Another CM Verbs Approach > > Tom> I think there is general concensus that having CM verbs in > Tom> the ib_device structure is disgusting. This patch moves these > Tom> verbs to the ib_cm.h file and adds a device capabilities flag > Tom> that indicates whether or not the device has CM verbs. > > Tom> I know this is not exactly what everyone is looking for, but > Tom> I hope it is workable given the practical realities we face > Tom> relative to host stack integration and the need to support > Tom> devices that establish connections internally. > > How about creating an iwarp_cm.h file instead of using ib_cm.h? That > way it's clear that these new methods are for iWARP devices. good suggestion. > > I'd like to understand that last bit above about devices that > establish connections internally. Does that mean that there are RNICs > that cannot support the iWARP verbs' notion of migrating a connection? > Yes, that's what it means and the reason is that Linux does not (yet) provide a means to do so. > - R. > ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] Re: RMPP Message Format Errors
>The 220 byte payload length is for SA. That's mostly right but assumes >the last segment will be full (and accounted for by the paylen in the >last segment). I believe that the 220 byte payload length is for all RMPP MADs. Only the common and RMPP header lengths are ignored. >Doesn't it need to account for a "partial" rather than full last segment >transferred data in the first segment length ? What I couldn't easily tell from the spec is whether a partial last segment is included in the initial payload length or not. I read it as: "PayloadLength counts all the bytes in the TransferredData field of the DATA packet format." In my interpretation, partial data is indicated by the PayloadLength field in the last segment only. It's quite possible that my interpretation is incorrect, in which case the calculation in the RMPP code is off. - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH][iWARP] Another CM Verbs Approach
Tom> I think there is general concensus that having CM verbs in Tom> the ib_device structure is disgusting. This patch moves these Tom> verbs to the ib_cm.h file and adds a device capabilities flag Tom> that indicates whether or not the device has CM verbs. Tom> I know this is not exactly what everyone is looking for, but Tom> I hope it is workable given the practical realities we face Tom> relative to host stack integration and the need to support Tom> devices that establish connections internally. How about creating an iwarp_cm.h file instead of using ib_cm.h? That way it's clear that these new methods are for iWARP devices. I'd like to understand that last bit above about devices that establish connections internally. Does that mean that there are RNICs that cannot support the iWARP verbs' notion of migrating a connection? - R. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH][iWARP] Another CM Verbs Approach
Sean/Roland:
I think there is general concensus that having CM verbs
in the ib_device structure is disgusting. This patch moves
these verbs to the ib_cm.h file and adds a device
capabilities flag that indicates whether or not
the device has CM verbs.
I know this is not exactly what everyone is looking for,
but I hope it is workable given the practical realities
we face relative to host stack integration and the need to
support devices that establish connections internally.
I know Roland has said we can "go wild" in our own branch,
but I really don't want to do something that is not
going to be acceptable to the community at large.
So here's another shot, please tell me what you think.
This patch is to the include directory of the iWARP
branch.
Signed-off-by: Tom Tucker <[EMAIL PROTECTED]>
Index: ib_cm.h
===
--- ib_cm.h (revision 3120)
+++ ib_cm.h (working copy)
@@ -39,6 +39,7 @@
#include
#include
+#include
enum ib_cm_state {
IB_CM_IDLE,
@@ -555,6 +556,96 @@
u8 private_data_len;
};
+/* iWARP connection attributes. */
+struct ib_conn_attr {
+ struct in_addr local_addr;
+ struct in_addr remote_addr;
+ u16 local_port;
+ u16 remote_port;
+};
+
+/* This is provided in the event generated when
+ * a remote peer accepts our connect request
+ */
+struct ib_conn_results {
+ int errno;
+ struct ib_conn_attr conn_attr;
+u8 *private_data;
+ int private_data_len;
+};
+
+/* This is provided in the event generated by a remote
+ * connect request to a listening endpoint
+ */
+struct ib_conn_request {
+ int cr_id;
+ struct ib_conn_attr conn_attr;
+u8 *private_data;
+ int private_data_len;
+};
+
+/* Connection events. */
+enum ib_cmv_event_type {
+ IB_EVENT_ACTIVE_CONNECT_RESULTS,
+ IB_EVENT_CONNECT_REQUEST
+};
+
+struct ib_cmv_event {
+ struct ib_device*device;
+ union {
+ struct ib_conn_results active_results;
+ struct ib_conn_request conn_request;
+ } element;
+ enum ib_cmv_event_type event;
+};
+
+/* Listening endpoint. */
+struct ib_listen_ep_attr {
+ void(*event_handler)(struct ib_cmv_event *, void *);
+ void*listen_context;
+ struct in_addr addr;
+ u16 port;
+ int backlog;
+};
+
+struct ib_listen_ep {
+ struct ib_device*device;
+ void(*event_handler)(struct ib_cmv_event *,
void *);
+ void*listen_context;
+ struct in_addr addr;
+ u16 port;
+ int backlog;
+};
+
+struct ib_cmv {
+
+ int(*connect_qp)(struct ib_qp *qp,
+struct ib_conn_attr*
attr,
+void
(*event_handler)(struct ib_cmv_event*, void*),
+void* context,
+u8 *pdata,
+int pdata_len
+);
+
+ int(*accept_cr)(int cr_id,
+ struct ib_qp *qp,
+ u8 *pdata,
+ int pdata_len);
+
+ int(*reject_cr)(int cr_id,
+ struct ib_qp *qp,
+ u8 *pdata,
+ int pdata_len);
+
+ int(*query_cr)(int cr_id,
+ struct ib_conn_request*
req);
+
+ struct ib_listen_ep * (*create_listen_ep)(struct
ib_listen_ep_attr *);
+
+ int(*destroy_listen_ep)(struct
ib_listen_ep *ep);
+
+};
+
/**
* ib_send_cm_sidr_rep - Sends a service ID resolution request to the
* remote node.
@@ -565,4 +656,5 @@
int ib_send_cm_sidr_rep(struct ib_cm_id *cm_id,
struct ib_cm_sidr_rep_param *param);
+
#endif /* IB_CM_H */
Index: ib_verbs.h
===
--- ib_verbs.h (revision 3120)
+++ ib_verbs.h (working copy)
@@ -59,7 +59,8 @@
enum ib_node_type {
IB_NODE_CA = 1,
IB_NODE_SWITCH,
- IB_NODE_ROUTER
+ IB_NODE_ROUTER,
+ IB_NODE_RNIC
};
enum ib_device_cap_flags {
@@ -78,6 +79,7 @@
IB_DEVICE_RC_RNR_NAK_GEN= (1<<12),
IB_DEVICE_SRQ_
RE: [openib-general] kernel oops
>I downloaded the latest openib gen2 stack and ran into kernel panic when >I run the cmpost/ucmpost example. I modified the program to continously >send and receive data in an infinite loop and killed the application >with ctrl-c. >The kernel panics pretty consistently. > >I am currently running 2.6.12 version of the kernel . Log attached. I >will try >upgrading to newer kernel and see if I can reproduce it. I have gotten something similar to this in my own testing, but haven't had the time to track it down. It seems to be related to how the IB AT code interacts with the SM, and if the SM has been restarted. Can you try resetting the SM node, then rebooting your other systems? - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] OSM vendor layer: In umad_receiver, handle allocating RMPP large MADs from OSM MAD pool
On Fri, Aug 26, 2005 at 12:34:58PM -0400, Hal Rosenstock wrote:
> - MAD_BLOCK_SIZE, &osm_addr))) {
> + length > MAD_BLOCK_SIZE ?
> + length :
> MAD_BLOCK_SIZE,
> + &osm_addr))) {
Can "max(length, MAD_BLOCK_SIZE)" be used instead?
thanks,
grant
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] kernel oops
I downloaded the latest openib gen2 stack and ran into kernel panic when
I run the cmpost/ucmpost example. I modified the program to continously
send and receive data in an infinite loop and killed the application
with ctrl-c.
The kernel panics pretty consistently.
I am currently running 2.6.12 version of the kernel . Log attached. I
will try
upgrading to newer kernel and see if I can reproduce it.
-Viswa
[EMAIL PROTECTED] examples]# uname -a
Linux subnetmgr4 2.6.12 #7 SMP Thu Aug 25 22:33:36 PDT 2005 i686 i686 i386
GNU/Linux
# svn info
Path: .
URL: https://openib.org/svn/gen2/trunk/src/linux-kernel
Repository UUID: 21a7a0b7-18d7-0310-8e21-e8b31bdbf5cd
Revision: 3197
Node Kind: directory
Schedule: normal
Last Changed Author: roland
Last Changed Rev: 3197
Last Changed Date: 2005-08-25 18:07:09 -0700 (Thu, 25 Aug 2005)
mgr4 login: Unable to handle kernel NULL pointer dereference at virtual address
0068
printing eip:
c02f35c5
*pde = 365b6001
Oops: [#1]
SMP
Modules linked in: nfsd exportfs lockd autofs4 sunrpc uhci_hcd ehci_hcd
hw_random e1000 ext3 jbd sd_mod
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00010086 (2.6.12)
EIP is at _spin_lock_irqsave+0xa/0x51
eax: 0064 ebx: 0286 ecx: f6607e6c edx: c036dbcc
esi: 0064 edi: 0064 ebp: esp: f6607e00
ds: 007b es: 007b ss: 0068
Process lt-ucmpost (pid: 3837, threadinfo=f6606000 task=f6feb020)
Stack: c013e410 c036dbcc c0267637 0073 00d0 f6607eac
f6504e80 c027390f c0351d00 f6607e6c 0c30 0064 f6607eac
f6504e80 c027952f 0c30 0064 00d0 c0278ff2 f6504e80
Call Trace:
[] __alloc_pages+0x166/0x3b6
[] ib_get_client_data+0x14/0x54
[] ib_sa_path_rec_get+0x1b/0x13e
[] resolve_path+0x8c/0x15b
[] path_req_complete+0x0/0xf7
[] rtnetlink_dump_all+0x0/0x9e
[] rtnetlink_done+0x0/0x3
[] ib_at_paths_by_route+0xc4/0xd9
[] same_path_req+0x0/0x95
[] ib_uat_paths_by_route+0xef/0x1c4
[] rtnetlink_dump_all+0x0/0x9e
[] rtnetlink_done+0x0/0x3
[] ib_uat_write+0x96/0xa2
[] vfs_write+0x108/0x10a
[] sys_write+0x41/0x6a
[] sysenter_past_esp+0x54/0x75
Code: c8 c3 81 78 04 ed 1e af de 75 0c f0 83 28 01 79 05 e8 94 e5 ff ff c3 0f
0b d7 00 56 60 30 c0 eb ea 56 89 c6 53 83 ec 08 9c 5b fa <81> 78 04 ad 4e ad de
75 20 f0 fe 0e 79 13 f7 c3 00 02 00 00 74
<7>ib_mthca :05:00.0: Unmapping 1 pages at 8 from ICM.
ib_mthca :05:00.0: Unmapping 1 pages at bf000 from ICM.
Unable to handle kernel NULL pointer dereference at virtual address 0005
printing eip:
c027a160
*pde = 37e01001
Oops: 0002 [#2]
SMP
Modules linked in: nfsd exportfs lockd autofs4 sunrpc uhci_hcd ehci_hcd
hw_random e1000 ext3 jbd sd_mod
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010286 (2.6.12)
EIP is at ib_uat_create_event+0x4e/0xb4
eax: 0246 ebx: 0005 ecx: edx: 0066
esi: c19fa180 edi: c19fa1b4 ebp: f72f5f00 esp: f7f4def4
ds: 007b es: 007b ss: 0068
Process ib_at_wq/0 (pid: 309, threadinfo=f7f4c000 task=f7cfca60)
Stack: 0096 f72f5f00 0001 f6504ed4 c027a219 0002
ff92 f6504eb0 f6504ed4 0292 c027a291 f72f5f00 ff92
ff92 c0278913 ff92 f6504eb0 c1a12000 c0129aad 000f41fd
Call Trace:
[] ib_uat_callback+0x53/0x6d
[] ib_uat_path_callback+0x1a/0x1f
[] req_comp_work+0x19/0x25
[] worker_thread+0x1b0/0x23a
[] req_comp_work+0x0/0x25
[] default_wake_function+0x0/0xc
[] default_wake_function+0x0/0xc
[] worker_thread+0x0/0x23a
[] kthread+0x8a/0xb2
[] kthread+0x0/0xb2
[] kernel_thread_helper+0x5/0xb
Code: 84 82 00 00 00 89 c7 b9 0d 00 00 00 89 d8 f3 ab 89 6e 04 ba 66 00 00 00
8b 44 24 04 89 06 b8 fa 44 30 c0 8b 5d 08 e8 84 ea e9 ff ff 0b 0f 88 27 0d
00 00 8b 45 08 8d 56 08 83 c0 24 8b 48 04
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] RDMA connection and address translation API
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Guy German > Sent: Friday, August 26, 2005 1:27 AM > To: Sean Hefty; James Lentini > Cc: openib-general@openib.org > Subject: RE: [openib-general] RDMA connection and address > translation API > > >> We need to insert in here: > >> > >> ib_modify_qp(...); /* somehow uses address resolution... */ > >> ib_post_recvs(...); > >> > > > >or add a new call to create the qp and modify it to init (an > analog to > >the socket(2) function). > > Sean> This approach seems reasonable to me. Maybe something like: > Sean> rdma_create_qp(rdma_addr_info); > > Sean> Uses the output from the address resolution to create the QP on > Sean> the correct device and transitions it to the INIT > state. The user > Sean> can now post any work requests that they want. For > example, with > Sean> iWarp, I believe that even send work requests can be > posted in the INIT state. > > What do you think about this flow ? > 1. resolve device and port from ip address - synchronous operation >(like at.c resolve_ip) > 2. rdma_create_qp (device+port) - modifies qp to init with > default pkey index 3. ib_post_recvs(...); 4. cma_connect - > asynchronous at, modify qp with correct pkey index, cm_connect > At least with iWARP a QP is not bound to a specific port, or even to an IP Address. It is only bound to the RDMA Device (RNIC) and Protection Domain. The same QP can be re-used for a new connection with a new IP address. Indeed, that is exactly what would happen with application-layer controlled failover (such as iSER). ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] avoid segv in libibverbs/examples
thanks, I finally applied this patch. - R. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Header reorganization heads up
On Thu, 25 Aug 2005, Grant Grundler wrote: > On Thu, Aug 25, 2005 at 01:56:20PM -0400, James Lentini wrote: > ... > > If you remove the include/rdma directory, won't that break code > > outside the OpenIB subversion tree that is using this location? > > What code outside of drivers/infiniband is using include/rdma? None that I know of at the moment. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] RMPP Message Format Errors (Short Term Plan)
Hi, I will finish with RMPP and then embark on the 1.8.0 merge. I hope and expect to start the latter early next week. -- Hal ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] RDMA connection and address translation API
On Thu, 25 Aug 2005, Sean Hefty wrote: > >> Any way providing src/dst IPs in the CM Private data is simple, > >> and we can come with IBTA extension blessing that data structure > >> as a general way to map IP oriented protocols over IB (a 1-2 page > >> draft at the most) This way it can also address Caitlin concerns > >> regarding NFS & IETF (since now it's a transport specific issue) > > > >How long do you estimate it would take to standardize an IP<->GID > >mechanism (ATS, CM embedded, ...) in the IBTA? 3 months? 6 months? > >A year? > > > >Let's assume that everyone on this list is in agreement. > > Does anyone in the IB world disagree with adding IP addresses in the > CM private data area? Would we want to extend this concept to SIDR > as well? I think we should focus on providing a mechanism to allow ULPs to use IP addresses on InfiniBand networks. Service discovery (SIDR) seems like a separate issue. The ability to ask "What UD QPN is this service using?" seems useful on its own. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH] OSM vendor layer: In umad_receiver, handle allocating RMPP large MADs from OSM MAD pool
OSM vendor layer: In umad_receiver, handle allocating RMPP large MADs
from OSM MAD pool
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
Index: osm_vendor_ibumad.c
===
--- osm_vendor_ibumad.c (revision 3198)
+++ osm_vendor_ibumad.c (working copy)
@@ -271,7 +271,9 @@
if (!(madw_p = osm_mad_pool_get(p_bind->p_mad_pool,
(osm_bind_handle_t)p_bind,
- MAD_BLOCK_SIZE, &osm_addr))) {
+ length > MAD_BLOCK_SIZE ?
+ length : MAD_BLOCK_SIZE,
+ &osm_addr))) {
osm_log( p_vend->p_log, OSM_LOG_ERROR, "umad_receiver: "
"request for a new madw failed -- dropping
packet\n" );
continue;
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Shubha Mudgal In Concert One Night Only!
Update Profile | Unsubscribe | Confirm | Complain ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] cma header - change some things according to the list feedback
On Thu, 25 Aug 2005, Guy German wrote: > > typedef void (*ib_cma_event_handler)(enum ib_cma_event event, void *context, > > void *private_data); > >>Would ib_cma_conn_handler be more appropriate? > > Maybe, but it is actually the active side event cb (also for discon etc.) > I don't mind changing it, though... In that case, I would not change it. > > int ib_cma_connect(struct ib_cma_conn *cma_conn, > >union ib_cma_id *cma_id); > > > >> Should there be a way to cancel an ib_cma_connect() call? > > It is possible to add it. Not sure how much it will be used by > consumers, though. The additional synchonization needed in consumers isn't worth it. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH] OSM vendor layer: Fix length when sending RMPP for SA class in osm_vendor_send
OSM vendor layer: Fix length when sending RMPP for SA class in
osm_vendor_send
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
Index: osm_vendor_ibumad.c
===
--- osm_vendor_ibumad.c (revision 3197)
+++ osm_vendor_ibumad.c (working copy)
@@ -942,7 +942,8 @@
put_madw(p_vend, p_madw, &p_mad->trans_id);
if ((ret = umad_send(p_bind->port_id, p_bind->agent_id, p_vw->umad,
-p_madw->mad_size,
+is_rmpp ? p_madw->mad_size - IB_SA_MAD_HDR_SIZE :
+ p_madw->mad_size,
resp_expected ? p_vend->timeout : 0,
p_vend->max_retries)) < 0) {
if (resp_expected)
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] [PATCH][iWARP] Added provider CMverbsandqueryprovider methods
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Sean Hefty > Sent: Friday, August 26, 2005 12:34 AM > To: 'Bob Sharp'; Caitlin Bestler; openib-general@openib.org > Subject: RE: [openib-general] [PATCH][iWARP] Added provider > CMverbsandqueryprovider methods > > >>From NetEffect's perspective, the per device approach is simple to > >implement and I do not see it as an Ammasso specific > approach. As Caitlin > >described, existing code needs to be reorganized but this > aspect of our port > >is not a major effort. > > I agree that connection setup code could be duplicated in all > iWarp drivers to > make such an interface work, but that doesn't necessarily > make it the best > approach. Personally, I would rather see a single iWarp > connection manager > establish the connections, and then hand those as the LLP > handle to the modify > QP verb. > > Based on comments, the iWarp vendors would prefer the host > TCP stack establish > connections. If this is the case, then why isn't having a > single iWarp CM that > resides above verbs preferred to duplicating that > functionality in each driver? > > To me, this does sound like an Ammasso specific approach, in that they > implemented TCP connections in hardware. Responses from > NetEffect and Broadcom > mentioned software solutions. I believe that what you are advocating is having a mini-TCP-stack in Linux. This mini-TCP-stack knows how to establish connections which are then passed down to the adpater. This mini-stack would comprise the iWARP side of a unified connection manager. This is all fine and good, but for the fact that not all adapters work this way. In fact, to date, *MOST* TOE engines including Chelsio, Adaptec, Emulex, and others establish connections themselves. Admittedly, I don't know how the Broadcom and NetEffect RDMA adapters plan on doing it. That said, there needs to be a device attribute that indicates whether the host establishes the connection on the adapter or takes existing connection state from the host. If the adapter establishes the connection, it must export functions to do so. I proposed yesterday that we have a separate structure for this purpose that is hung off the ib_device. This structure will be present and populated for adapters that establish connections themselves. As far as the host-mini-TCP stack goes...I find it almost impossible to believe that it has a better chance of getting pushed upstream than does host-stack integration. We should clearly articulate the host-adapter split stack model, why it is necessary for RDMA devices, and attempt to convince the netdev/stack community that this is the right thing to do. A mini-TCP stack in the host is a separate piece of logic that duplicates existing functionality that serves no other purpose than to delay an inevitable argument about upstream integration. > > - Sean > > ___ > openib-general mailing list > openib-general@openib.org > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit > http://openib.org/mailman/listinfo/openib-general > ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] Re: RMPP Message Format Errors
On Fri, 2005-08-26 at 01:16, Sean Hefty wrote: > >In any case, doesn't the initial payload length need to be the number of > >segments times (hdr_len - offsetof(struct ib_rmpp_mad, data)) + data_len > >? If so, that's part of the problem. > > I believe that the payload is being calculated correctly. It should be the > number of segments * 220 bytes per packet, or at least that was my > interpretation of the spec. The 220 byte payload length is for SA. That's mostly right but assumes the last segment will be full (and accounted for by the paylen in the last segment). Doesn't it need to account for a "partial" rather than full last segment transferred data in the first segment length ? -- Hal ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: RMPP Message Format Errors
Hi Eitan, On Fri, 2005-08-26 at 06:15, Eitan Zahavi wrote: > I am trying to figure out how a client will figure out the number of > records provided in the mad it gets back from umad. > > Can you describe this? A client would use the received length returned from umad_recv and either the attribute offset in the RMPP header (or expected attribute offset for record type) to calculate this (in the case of an SA client). For other classes, it is class specific. I think there is a problem in osm_vendor_ibumad_sa.c::__osmv_sa_mad_rcv_cb which I will be working on as soon as I sort through the send side issues. -- Hal ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: RMPP Message Format Errors
Hi Hal, I am trying to figure out how a client will figure out the number of records provided in the mad it gets back from umad. Can you describe this? Thanks Eitan Hal Rosenstock wrote: On Mon, 2005-08-22 at 10:34, Eitan Zahavi wrote: It gets a "real" received length provided it supplies a buffer large enough. So I guess the "real receive length" is truncated to the last data record even if the packet sent was 256 bytes? The receive buffer is not truncated. An error is returned if the buffer supplied is too small for a receive is too small and it includes the size of the buffer needed. I don't understand what you mean by "even if the packet sent was 256 bytes". -- Hal ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] RE: Do we care about pre-emption?
Hi Paul, Thanks for pointing out your OS preemeption needs. > Your (current?) design minimizing the work in interrupt context > seems a good starting point. Why do you want to do more of that > work in an ISR? Is the extra complexity putting it outside an > ISR significant? Is the performance much worse? iSER, today, is going into the trouble of staying in the kernel thread context as long as possible, after receiving it's completion upcall. I was just a pondering - is it really necessary ? in light of the SRPs different approach. Any way, there isnt any immediate intention of changing this - there are other issues the iSER code is dealing with, right now. Thanks, Guy ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] RDMA connection and address translation API
>> We need to insert in here: >> >> ib_modify_qp(...); /* somehow uses address resolution... */ >> ib_post_recvs(...); >> > >or add a new call to create the qp and modify it to init (an analog to >the socket(2) function). Sean> This approach seems reasonable to me. Maybe something like: Sean> rdma_create_qp(rdma_addr_info); Sean> Uses the output from the address resolution to create the QP on the Sean> correct device and transitions it to the INIT state. The user can Sean> now post any work requests that they want. For example, with iWarp, Sean> I believe that even send work requests can be posted in the INIT state. What do you think about this flow ? 1. resolve device and port from ip address - synchronous operation (like at.c resolve_ip) 2. rdma_create_qp (device+port) - modifies qp to init with default pkey index 3. ib_post_recvs(...); 4. cma_connect - asynchronous at, modify qp with correct pkey index, cm_connect Guy ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: crash solved! (was: [openib-general] kernel crashes while using mvapich-gen2 over ib_uverbs)
Roland, On Thu, 2005-08-25 at 17:52 -0700, Roland Dreier wrote: > I finally got to the bottom of this. It's a pretty simple > use-after-free bug. I didn't see it because the only machines I > routinely test CONFIG_DEBUG_SLAB=y kernels on are i386 machines, and > the implementation of dma_unmap_sg() for i386 doesn't expose this > bug. As soon as I tested CONFIG_DEBUG_SLAB=y on x86_64, I saw the > same failure. The patch below should fix this for you. > > Please let me know if you still have problems after applying this patch. thanks for your several replies. I am sorry for not being available for feedback immedeately. To summarize, your patch works well (although I had to trim it manually). To answer your previous questions, CONFIG_DEBUG_SLAB=y and CONFIG_HUGETLB_PAGE=y were set. (I guess you won't need objdump of uverbs_mem.o anymore, do you?) Now, together with a fresh checkout of mvapich-gen2 I have been able to run simple mpi programs. thanks for your help && keep up the good work, cheers. - Christian ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
