On Wed, Jan 26, 2005 at 08:49:27PM -0800, Sean Hefty wrote: > > I'm seeing the following Oops on both passive and active connects. > >On active side it's around theend of the REP callback, or the sending > >of the RTU. On the passive side it appears to be around the sending > >of the REP or receiving of the RTU. > > Thanks for the feedback. I'll take a look at the oops first off in the > morning.
On the active connection side, I see two cm_alloc_msg() calls, presumably one for the REQ and one for the RTU. However, I only see a single cm_free_msg, which is the one that is causing the oops, and the fields in the structure appear to be garbage. Is there any info I can gather for you, if you want me to take a closer look, let me know how alloc and free should work... > > On another note, calling ib_cm_establish from CQ callback context, I > >would expect to see a callback from the CM that I've entered ESTABLISHED > >state, but looking at the code, that does not appear to be the case. Is > >this something that wasn't intended, or just isn't there yet? > > This wasn't intended. The assumption being that the user knows that the > connection was already established. I don't think that it would be too hard > to add. (The only issue that jumps to mind at the moment could be a > potential race condition processing a DREQ.) Is this something that you > need? Would you need the callback from one of the CM's threads? Once the connection is in established state, on the passive side, I need to make one more QP state transition. So if the CM doesn't make an established callback, the consumer needs to create a work thread to perform the QP state transition. If a DREP is received ahead of an RTU, in REP_SENT state, it means that the RTU was sent and lost. So the DREP implies a established transition. How about receiving a DREP in REP_SENT, generates two transitions and callbacks, established and timewait? Likewise, a sent RTU in the REP_RCVD state would generate and established callback as well. -Libor _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
