Padmanabh Ratnakar wrote:
> As part of commit e325b49a320b493cc5d69e263751ff716dc458fe,
> order in which resources are destroyed was changed for fixing
> a seg fault. Due to this change, CQ will never get destroyed as
> CQ should be destroyed after QP destruction. Seg fault is caused
> improper cl
>
> This other three are nice, remove code, and make it correct with the case
> that qp has to be removed first.
>
> So, should we drop the listen_id part, or there is a reason for it?
>
> Later, Juan.
>
listen_id is used only in server side.
Saw that listen_id gets created before cm_id.
So f
> -Original Message-
> From: Dr. David Alan Gilbert [mailto:dgilb...@redhat.com]
> Sent: Wednesday, March 25, 2015 4:10 PM
> To: Padmanabh Ratnakar
> Cc: quint...@redhat.com; amit.s...@redhat.com; mrhi...@us.ibm.com;
> Padmanabh Ratnakar; Meghana Cheripady; qemu-devel@nongnu.org
> Subject:
Padmanabh Ratnakar wrote:
> As part of commit e325b49a320b493cc5d69e263751ff716dc458fe,
> order in which resources are destroyed was changed for fixing
> a seg fault. Due to this change, CQ will never get destroyed as
> CQ should be destroyed after QP destruction. Seg fault is caused
> improper cl
> As part of commit e325b49a320b493cc5d69e263751ff716dc458fe,
> order in which resources are destroyed was changed for fixing
> a seg fault. Due to this change, CQ will never get destroyed as
> CQ should be destroyed after QP destruction. Seg fault is caused
> improper cleanup when connection fails
As part of commit e325b49a320b493cc5d69e263751ff716dc458fe,
order in which resources are destroyed was changed for fixing
a seg fault. Due to this change, CQ will never get destroyed as
CQ should be destroyed after QP destruction. Seg fault is caused
improper cleanup when connection fails. Fixing c
