[openib-general] Unusable QP's on CM established connections from gen2 client to gen1 server.

[Bub Thomas]

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 can't 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. :-(

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: Thomas.Bub at thomson.net
www.GrassValley.com  <http://www.grassvalley.com> 
............................................................


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20061109/68532327/attachment.html>