I've traced it down to cma_ib_listen(). It destroys the cm_id if the
listen fails. It probably shouldn't, correct? IE the cm_id is owned by
the ULP who called rdma_create_id() and should be destroyed by that
ULP...
Steve.
--- snipit from cma_ib_listen() ---
ret = ib_cm_listen(id_priv->cm_id, svc_id, 0);
if (ret)
ib_destroy_cm_id(id_priv->cm_id);
----- Original Message -----
From: "Steve Wise" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, October 31, 2005 2:35 PM
Subject: [openib-general] possible CMA bug
Hi,
I'm using the new rdma cma interface and i've perhaps stumbled onto a
bug. I'm trying to bind to port 9999 on both IB ports of a mthca
device. The IPoIB interfaces for the HCA are configured as two
seperate subnets. The second rdma_listen() always fails with EBUSY.
Maybe this is a limitation in the CMA design, but TCP stacks allow
binding to the same port on different ip addresses. And the CMA
interface allows it too as long as the two ip addresses map to
different IB devices. Whether this should work or not, I am seeing a
crash when I try to destroy the cm_id after the rdma_listen() failure.
Here is a log of the event (printks from my krping module in
branches/iwarp/utils/src/linux-kernel/infiniband/krping). It seems as
though the cm_id is being destroyed twice, but I don't think the
krping module is doing it...
krping: proc write |verbose,server,addr=192.168.80.154,port=9999|
krping: verbose
krping: server
krping: ipaddr (192.168.80.154), nbo 0x(9a50a8c0)
krping: port hbo 0x270f nbo 0xf27
krping: created cm_id ffff81003f376800
krping: rdma_bind_addr worked
krping: created pd ffff81003feac600
krping: created cq ffff81007a1df080
krping: create listener
krping: rdma_listen error -16
krping: listen error -16
krping: destroying cq ffff81007a1df080
krping: dealloc pd ffff81003feac600
krping: destroy cm_id ffff81003f376800
idr_remove called for id=2 which is not allocated.
Call Trace:<ffffffff801fdc04>{idr_remove+244}
<ffffffff88238a88>{:ib_cm:ib_destroy_cm_id+408}
<ffffffff8013768d>{printk+141}
<ffffffff8825f116>{:rdma_cm:cma_exch+70}
<ffffffff8825f939>{:rdma_cm:rdma_destroy_id+57}
<ffffffff880fc4ac>{:ib_mthca:mthca_free+44}
<ffffffff88100155>{:ib_mthca:mthca_free_mr+213}
<ffffffff88268961>{:ib_krping:krping_write_proc+6657}
<ffffffff8019c739>{__d_lookup+297} <ffffffff8019b556>{dput+54}
<ffffffff80190dd4>{__follow_mount+52}
<ffffffff80190fd4>{do_lookup+100}
<ffffffff801c0327>{proc_file_write+39}
<ffffffff80182659>{vfs_write+233}
<ffffffff801827f3>{sys_write+83}
<ffffffff8010dc76>{system_call+126}
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit
http://openib.org/mailman/listinfo/openib-general
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
