[openib-general] Re: problem with memory registration-RDMA kernel utliity
Quoting r. keshetti mahesh <[EMAIL PROTECTED]>: > addr_array[0] = virt_to_phys(test->mem) ; Not related to your problem, but you really should be using the DMA API to get the DMA address and pass that to memory registration verbs. -- MST ___ 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] problem with memory registration-RDMA kernel utliity
Hi. > All these operations are not generating any errors > But when i pass this address (addr_array[0]) as the remote address, the > RDMA_READ operation on this address is generating IB_WC_REM_ACCESS_ERROR > completion. > > am i missing anything in the process of registering the memory? 1) Did you enable the RDMA_READ + RDMA_WRITE in the modify QP (qp_access_flags) in the responder side? 2) Do you have more than one PD (QP and MR PD should be the same)? 3) you should check that the address + rkey that the requestor sides uses are the right values .. Dotan ___ 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] problem with memory registration-RDMA kernel utliity
i am trying to develop a kernel utility to perform RDMA read/write operationsi am facing a problem with memory regiatration in it.my code looks like.u64 *addr_array;addr_array = kmalloc(sizeof(u64),GFP_KERNEL); //i am using only one page buffertest->mem = kmalloc(4096,GFP_KERNEL); // buffer on which RDMA_READ is to be performedtest->fmr = ib_alloc_fmr(test->pd,IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_READ | IB_ACCESS_REMOTE_WRITE, fmr_attr); //fmr_attr is intialised properlyaddr_array[0] = virt_to_phys(test->mem) ;ret = ib_map_phys_fmr(test->fmr,addr_array[0],1,(u64)test->mem);All these operations are not generating any errorsBut when i pass this address (addr_array[0]) as the remote address, the RDMA_READ operation on this address is generating IB_WC_REM_ACCESS_ERROR completion.am i missing anything in the process of registering the memory?Thanks n regardsK.Mahesh Send instant messages to your online friends http://in.messenger.yahoo.com Stay connected with your friends even when away from PC. Link: http://in.mobile.yahoo.com/new/messenger/ ___ 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] [ANNOUNCE] New iWARP Branch
Hi Steve, We are trying the new iwarp branch on ammasso adapters. The installation has gone fine. However, on running rping there is a error during disconnect phase. $ rping -c -vV -C4 -S4 -a 150.10.108.100 -p libibverbs: Warning: no userspace device-specific driver found for uverbs1 driver search path: /usr/local/lib/infiniband libibverbs: Warning: no userspace device-specific driver found for uverbs0 driver search path: /usr/local/lib/infiniband ping data: rdm ping data: rdm ping data: rdm ping data: rdm cq completion failed status 5 DISCONNECT EVENT... *** glibc detected *** free(): invalid next size (fast): 0x0804ea80 *** Aborted There are no apparent errors showing up in dmesg. Is this error currently expected? Thanks, --Sundeep. On Fri, 2 Jun 2006, Steve Wise wrote: Hello, The gen2 iwarp branch has been merged up to the main trunk revision 7626.The iwarp branch can be found at gen2/branches/iwarp and contains the Ammasso 1100 and Chelsio T3 drivers and user libs. If you are working on iwarp, please test out this new branch and lemme know if there are any problems. Thanks, Steve. ___ 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: [PATCH]Repost: IPoIB skb panic
Ohmm. That's a myth. So this problem is hardware independent, right? It's not easy to reproduce it. ifconfig up and down stress test could hit this problem occasionally. thanks Shirley Ma IBM Linux Technology Center 15300 SW Koll Parkway Beaverton, OR 97006-6063 Phone(Fax): (503) 578-7638___ 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] Removing mpi subtree from ofed branch
> I would like to remove the userspace mpi subtree from the ofed branch > (https://openib.org/svn/gen2/branches/1.0/src/userspace). > > MPI is supplied in ofed as a separate package, which is not > taken from the > ofed branch. The presence of the mpi directory in the ofed branch is > therefore misleading. So why don't we put the OFED MVAPICH MPI source in the branch then? It is also kinda confusing that the OFED MVAPICH is a tarball and not in subversion, given that it is based off the code that is in suvbersion. Scott Weitzenkamp SQA and Release Manager Server Virtualization Business Unit Cisco Systems ___ 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]Repost: IPoIB skb panic
> More clarification: we saw two races here: > 1. path_free() was called by both unicast_arp_send() and > ipoib_flush_paths() in the same time. It is not possible to call path_free() on the same object from both unicast_arp_send() and ipoib_flush_paths(). This becasue unicast_arp_send() calls it only for newly created objects for which path_rec_create() failed, in which case the object was never inserted into the list or the rb_tree. > 2. during unicast arp skb retransmission, unicast_arp_send() appended > the skb on the list, while ipoib_flush_paths() calling path_free() to > free the same skb from the list. I don't see any issue here as well. Can you reproduce the crash? If you do, can you send how? ___ 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] Removing mpi subtree from ofed branch
I would like to remove the userspace mpi subtree from the ofed branch (https://openib.org/svn/gen2/branches/1.0/src/userspace). MPI is supplied in ofed as a separate package, which is not taken from the ofed branch. The presence of the mpi directory in the ofed branch is therefore misleading. If no one objects, I'll delete the mpi subtree from the ofed branch in a week (June 11). - Jack ___ 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] ipoib: fix ah leak at interface down
Quoting r. Roland Dreier <[EMAIL PROTECTED]>: > Subject: Re: [PATCH] ipoib: fix ah leak at interface down > > Michael> If this makes sense, please push into 2.6.17. > > Yes, looks OK for 2.6.17. Out of curiousity: > > Michael> This might result in leaks (we see ah leaks which we > Michael> think can be attributed to this bug) as new packets get > Michael> posted while the interface is going down. > > with this patch applied, do the leaks go away? We've just got a confirmation from customer that this patch really fixes the AH leak. Please ask Linus to pull it into 2.6.17. -- MST ___ 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] SRP: [PATCH] Misc cleanups in ib_srp
Hi,
Misc cleanups in ib_srp. Please consider for 2.6.18.
1) I think that it is more efficient to move the req entries from req_list
to free_list in srp_reconnect_target (rather than rebuild the free_list).
(In any case this code is shorter).
2) This allows us to reuse code in srp_reset_device and srp_reconnect_target
and call a new function srp_reset_req.
3) We can use list_move_tail in srp_remove_req.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
===
--- last_stable.orig/drivers/infiniband/ulp/srp/ib_srp.c2006-05-19
11:14:35.0 +0300
+++ last_stable/drivers/infiniband/ulp/srp/ib_srp.c 2006-05-21
17:41:25.0 +0300
@@ -451,14 +451,26 @@ static void srp_unmap_data(struct scsi_c
scmnd->sc_data_direction);
}
+static void srp_remove_req(struct srp_target_port *target, struct srp_request
*req)
+{
+ srp_unmap_data(req->scmnd, target, req);
+ list_move_tail(&req->list, &target->free_reqs);
+}
+
+static void srp_reset_req(struct srp_target_port *target, struct srp_request
*req)
+{
+ req->scmnd->result = DID_RESET << 16;
+ req->scmnd->scsi_done(req->scmnd);
+ srp_remove_req(target, req);
+}
+
static int srp_reconnect_target(struct srp_target_port *target)
{
struct ib_cm_id *new_cm_id;
struct ib_qp_attr qp_attr;
- struct srp_request *req;
+ struct srp_request *req, *tmp;
struct ib_wc wc;
int ret;
- int i;
spin_lock_irq(target->scsi_host->host_lock);
if (target->state != SRP_TARGET_LIVE) {
@@ -494,19 +506,12 @@ static int srp_reconnect_target(struct s
while (ib_poll_cq(target->cq, 1, &wc) > 0)
; /* nothing */
- list_for_each_entry(req, &target->req_queue, list) {
- req->scmnd->result = DID_RESET << 16;
- req->scmnd->scsi_done(req->scmnd);
- srp_unmap_data(req->scmnd, target, req);
- }
+ list_for_each_entry_safe(req, tmp, &target->req_queue, list)
+ srp_reset_req(target, req);
target->rx_head = 0;
target->tx_head = 0;
target->tx_tail = 0;
- INIT_LIST_HEAD(&target->free_reqs);
- INIT_LIST_HEAD(&target->req_queue);
- for (i = 0; i < SRP_SQ_SIZE; ++i)
- list_add_tail(&target->req_ring[i].list, &target->free_reqs);
ret = srp_connect_target(target);
if (ret)
@@ -706,13 +711,6 @@ static int srp_map_data(struct scsi_cmnd
return len;
}
-static void srp_remove_req(struct srp_target_port *target, struct srp_request
*req)
-{
- srp_unmap_data(req->scmnd, target, req);
- list_del(&req->list);
- list_add_tail(&req->list, &target->free_reqs);
-}
-
static void srp_process_rsp(struct srp_target_port *target, struct srp_rsp
*rsp)
{
struct srp_request *req;
@@ -1349,11 +1347,8 @@ static int srp_reset_device(struct scsi_
spin_lock_irq(target->scsi_host->host_lock);
list_for_each_entry_safe(req, tmp, &target->req_queue, list)
- if (req->scmnd->device == scmnd->device) {
- req->scmnd->result = DID_RESET << 16;
- req->scmnd->scsi_done(req->scmnd);
- srp_remove_req(target, req);
- }
+ if (req->scmnd->device == scmnd->device)
+ srp_reset_req(target, req);
spin_unlock_irq(target->scsi_host->host_lock);
--
Ishai Rabinovitz
___
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] RFC: use stdint.h types
Quoting r. Roland Dreier <[EMAIL PROTECTED]>: > Subject: Re: [PATCH] RFC: use stdint.h types > > My initial reaction is that I don't like this, since it makes it > harder to keep the kernel ABI files in sync between libraries and the > kernel. How about a perl script? #!/usr/bin/perl -pi s/\b__u(64|32|16|8)\b/uint$1_t/; s/\b__s(64|32|16|8)\b/int$1_t/; and back #!/usr/bin/perl -pi s/\b(uint)(64|32|16|8)_t\b/__u$1/; s/\b(__s)(64|32|16|8)\b/__s$1/; > Does overriding offsetof() really cause any problems? Donnu, but I'm worried there's some subtle reason gcc 4.0 defines it by means of __builtin_offsetof rather than the traditional way. > Does including break anything? Well, we are using an undocumented interface, and so it does make things fragile, take the compilation problem on sles10 as an example. -- MST ___ 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: OFED RC6 Tag
Woodruff, Robert J wrote: Hi, I noticed that you now have a rc6 tag for the OFED kernel code. Is there a tag for the userspace code ? or what SVN rev will be used for RC6. woody There is no tag for the user level code since it is taken directly from the HEAD of branch. In the release BUILD ID you can see the svn revision of the user level. Tziporet ___ 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
