Title: Unusable QP's on CM established connections from gen2 client to gen1 server.

As written before I have to connect a gen2 client with a gen1 server using CM.

The connection is established fine and both sides go into the connected state.

However I cant send any data from none of the two sides.

As soon as I do so I get a 0x81 VAPI_RETRY_EXC_ERR when trying to send from the gen1 or a vendor_err 0x81 when trying to send from the gen2 side.

What works so far with my gen1 and gen2 code is:

Connecting gen1 client and gen1 server is no problem.

Connecting gen2 client and gen2 server is no problem.

Connecting gen1 client and gen2 server is no problem

Unfortunately the only usage scenario I have is to connect gen2 client and gen1 server. L

Is there a way to diagnose the reason for trouble when a  VAPI_SEND / IBV_WR_SEND returns that 0x81 VAPI_RETRY_EXC_ERR?

It seems as if the receiving side which is sure in the receive mode does not get any notification as if the sender does not even start sending.

I already printed out the qp_state of both the gen2 client and the gen1 server before the send fails. Which look like:

Gen2 client QP state.

           qp_state: 3

       cur_qp_state: 3

           path_mtu: 4

     path_mig_state: 0

               qkey: 16391

             rq_psn: 5571589

             sq_psn: 15025863

        dest_qp_num: 10814473

    qp_access_flags: 14

                cap: 256

            ah_attr: 256

        alt_ah_attr: 29

         pkey_index: 3

     alt_pkey_index: 460

en_sqd_async_notify: 33022

        sq_draining: 0

      max_rd_atomic: 82905088

 max_dest_rd_atomic: 219649539

      min_rnr_timer: 0

           port_num: 16384

            timeout: 50331753

          retry_cnt: 65795

          rnr_retry: 0

       alt_port_num: 0

        alt_timeout: 0

Gen1 server QP state.

           qp_state: 3

  en_sqd_asyn_notif: 0

        sq_draining: 0

             qp_num: 10814473

remote_atomic_flags: 7

               qkey: 0

           path_mtu: 4

     path_mig_state: 0

             rq_psn: 15025863

             sq_psn: 5571589

     qp_ous_rd_atom: 4

    ous_dst_rd_atom: 4

      min_rnr_timer: 27

                cap: 200

        dest_qp_num: 200

        sched_queue: 28

            pkey_ix: 28

               port: 460

                 av: 5571589

            timeout: 0

        retry_count: 0

          rnr_retry: 1

        alt_pkey_ix: 0

           alt_port: 0

             alt_av: 0

        alt_timeout: 0

In the good cases described above the qp_state look similar to the ones described here

Any help welcome.

Thomas Bub

............................................................
Thomas Bub

Grass Valley Germany GmbH
Brunnenweg 9
64331 Weiterstadt, Germany
Tel: +49 6150 104 147
Fax: +49 6150 104 656
Email:
[EMAIL PROTECTED]
www.GrassValley.com
............................................................

_______________________________________________
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

Reply via email to