[openib-general] Re: [Fwd: Re: [Fwd: Re: OpenSM Bugs]]

[Tom Duffy]

On Wed, 2005-01-19 at 19:15 -0500, Hal Rosenstock wrote:
> The OpenIB side wouldn't send an ACK so this message must indicate
> something else. Any chance you can get an IB trace of what is going on ?
> Alternatively can you dump out the MAD where the unsupported base
> version is printed out ? It will take me a little bit before I am setup
> to try to recreate this.

Here is the analysis of what is going on (from Solaris's perspective).

Sandip Barua wrote:
> Based on the trace output I obtained this morning,
> I am seeing a number of the following transactions:
> 
> 1) IBMF makes a request (non-RMPP send)
> 2) openIB responds with one RMPP MAD which is marked as both
>    the first and the last packet of the RMPP transaction
> 3) IBMF sends an ACK
> 
> At this point, the transaction should be complete, but MADs continue
> to arrive. In one case an ACK arrives which is an
> illegal packet to receive while in receiver terminate loop, so, ibmf
> returns an ABORT. In the remaining cases, DATA packets are being
> received after the transaction is complete, so, ibmf drops them and
> returns ACKs if in the receiver termination loop.
> 
> From the IBMF side, the following packets are being sent,
> o request data packet (non-rmpp, will not have base version set)
> o ACK packet on completion of the transaction
> o ABORT packet on receiving an ACK
> 
> Based on my review of the code, and the occurrence of certain
> messages, it looks to me like the base version should be set on all
> outgoing ACK and ABORT packets.

-tduffy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20050120/5e6239ec/attachment.sig>