[openib-general] kdapltest regression? failing now...

[James Lentini]

For what it's worth, this is the check that we are "failing":

  qp->sq.max_gs > dev->limits.max_sg

( qp->sq.max_gs + 2 > dev->limits.max_sg is also true but
   qp->transport == MLX is not).

On Thu, 19 May 2005, James Lentini wrote:

>
> I'm looking into this Tom.
>
> The following code was added to hw/mthca/mthca_qp.c on Friday
> (starting on line 1233):
>
>
> if ((qp->transport == MLX && qp->sq.max_gs + 2 > dev->limits.max_sg) ||
>    qp->sq.max_gs > dev->limits.max_sg || qp->rq.max_gs > dev->limits.max_sg)
>             return -EINVAL;
>
> If anyone knows what we have set incorrectly, please let me know.
>
> Thanks,
> james
>
> On Thu, 19 May 2005, Tom Duffy wrote:
>
> tduffy> I am not sure when this started, but after updating to top of trunk*, I
> tduffy> can no longer get kdapltest to work properly.  Both ipoib and sdp are
> tduffy> working.
> tduffy>
> tduffy> Both server and client are returning an error: DAT_INVALID_HANDLE.  This
> tduffy> is coming from ib_create_qp().  With debugging turned on:
> tduffy>
> tduffy> [root at flopteron2 ~]# ./kdapltest -T S -D mthca0a -d
> tduffy> kDAPL: dapl_ia_open (mthca0a, 8, ffff81000b806308, ffff81000b8062d8)
> tduffy> kDAPL: dapl_ia_open () returns 0x0
> tduffy> kDAPL: dapl_pz_create (ffff81001ba165c8, ffff81000b8062e0)
> tduffy> kDAPL: dapl_evd_kcreate (ffff81001ba165c8, 8, 1, upcall, 0x20, ffff81000b8062e8)
> tduffy> kDAPL: dapl_evd_kcreate (ffff81001ba165c8, 8, 1, upcall, 0xa0, ffff81000b8062f0)
> tduffy> kDAPL: dapl_evd_kcreate (ffff81001ba165c8, 8, 1, upcall, 0x10, ffff81000b806300)
> tduffy> kDAPL: dapl_evd_kcreate (ffff81001ba165c8, 8, 1, upcall, 0x40, ffff81000b8062f8)
> tduffy> kDAPL: dapl_ep_create (ffff81001ba165c8, ffff81001b9442c8, ffff81001ba164b0, ffff81001ba166e0, ffff81001ba22050, 0000000000000000, ffff81000b806318)
> tduffy> kDAPL:  dapl_ib_qp_alloc: ib_create_qp failed = -22
> tduffy> kDAPL: dapl_evd_free (ffff81001ba22050)
> tduffy> kDAPL: dapl_evd_free () returns 0x0
> tduffy> kDAPL: dapl_evd_free (ffff81001ba22168)
> tduffy> kDAPL: dapl_evd_free () returns 0x0
> tduffy> kDAPL: dapl_evd_free (ffff81001ba166e0)
> tduffy> kDAPL: dapl_evd_free () returns 0x0
> tduffy> kDAPL: dapl_evd_free (ffff81001ba164b0)
> tduffy> kDAPL: dapl_evd_free () returns 0x0
> tduffy> kDAPL: dapl_pz_free (ffff81001b9442c8)
> tduffy> kDAPL: dapl_ia_query (ffff81001ba165c8, 0000000000000000, 0000000000000000, ffff81001bba7b28)
> tduffy> kDAPL: dapl_ia_query () returns 0x0
> tduffy> kDAPL: dapl_ia_close (ffff81001ba165c8, 1)
> tduffy> kDAPL: dapl_evd_free (ffff81001ba167f8)
> tduffy> kDAPL: dapl_evd_free () returns 0x0
> tduffy> Server_Cmd.debug:       1
> tduffy> Server_Cmd.dapl_name: mthca0a
> tduffy> DT_cs_Server: IA mthca0a opened
> tduffy> DT_cs_Server: PZ created
> tduffy> DT_cs_Server: dat_ep_create error: DAT_INVALID_HANDLE
> tduffy> DT_cs_Server: Waiting for clients to all go away...
> tduffy> DT_cs_Server: Cleaning up ...
> tduffy> DT_cs_Server: IA mthca0a closed
> tduffy> DT_cs_Server (mthca0a):  Exiting.
> tduffy> TEST INSTANCE 0
> tduffy> TEST return code = 1
> tduffy>
> tduffy> Also, the ib_at module prints this out now when you ping (after running
> tduffy> kdapltest)...
> tduffy>
> tduffy> ib_at: ib_at_arp_work: Process IB ARP ip <192.168.0.26> gid <0xfe800000000000000002c9010a99e031>
> tduffy>
> tduffy> -tduffy
> tduffy>
> tduffy> * running x86_64 SMP, 2.6.12-rc4, gcc 4.0.0-6, OpenIB r2414, opensm r2414 2 machines back-2-back
> tduffy>
>