On Tue, Jan 13, 2015 at 11:31:16AM -0600, Steve Wise wrote:
Reviewed-by: Steve Wise sw...@opengridcomputing.com
Thanks, applying for 3.20.
--b.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Thu, 2015-01-15 at 09:19 +, Erez Shitrit wrote:
Hi Doug,
Thank you for the quick response.
Now I can see 2 issues, that I want to draw your attention to:
1. if there is a mcg that the driver failed to join, the mc_task enters to
endless loop of re-queue, and the log will be full
On Thu, 2015-01-15 at 22:08 +0200, Erez Shitrit wrote:
On 1/15/2015 5:24 PM, Doug Ledford wrote:
On Thu, 2015-01-15 at 09:19 +, Erez Shitrit wrote:
Hi Doug,
Thank you for the quick response.
Now I can see 2 issues, that I want to draw your attention to:
1. if there is a mcg
Make the send only join completion handler behave like the normal join
completion handler in that we should restart the multicast join thread
whenever our join completes with either an error or success, but don't
restart the thread if we got a net reset event, let ipoib_event queue
up a device
On 1/15/2015 5:24 PM, Doug Ledford wrote:
On Thu, 2015-01-15 at 09:19 +, Erez Shitrit wrote:
Hi Doug,
Thank you for the quick response.
Now I can see 2 issues, that I want to draw your attention to:
1. if there is a mcg that the driver failed to join, the mc_task enters to
endless loop
When the core layer calls our callback with ENETRESET as the error, we
clear the status to 0 before returning indicating that we are going to
handle the error ourselves. This causes the core layer to not free the
mcast-mc structure, but we are releasing our reference to it by
clearing mcast-mc.
During the various work I've done on this, some extra locking has crept
in when things weren't working right. This is one of those spots.
Remove the unneeded spinlocks. The mutex is enough to protect against
what we need to protect against.
Signed-off-by: Doug Ledford dledf...@redhat.com
---
On 1/12/2015 12:11 PM, ira.we...@intel.com wrote:
From: Ira Weiny ira.we...@intel.com
OPA_MIN_CLASS_VERSION -- OPA Class versions are 0x80
OPA_SMP_CLASS_VERSION -- Defined at 0x80 OPA_MGMT_BASE_VERSION --
Defined at 0x80
Increase max management version to accommodate OPA
Cleanup all the MACROS that are defined in t4fw_ri_api.h and affected files
Signed-off-by: Hariprasad Shenai haripra...@chelsio.com
---
drivers/infiniband/hw/cxgb4/cm.c | 30 +-
drivers/infiniband/hw/cxgb4/cq.c | 22 +-
drivers/infiniband/hw/cxgb4/device.c | 12 +-
Hi,
This patch series cleansup macros/register defines, defined in t4.h and
t4fw_ri_api.h and all the affected files.
This patch series is created against net-next tree and includes patches on
iw_cxgb4 tree. Since the patches are dependent on previous cleanup patched we
would line to get this
Cleanup all the MACROS defined in t4.h and the affected files
Signed-off-by: Hariprasad Shenai haripra...@chelsio.com
---
drivers/infiniband/hw/cxgb4/cq.c | 38
drivers/infiniband/hw/cxgb4/qp.c |2 +-
drivers/infiniband/hw/cxgb4/t4.h | 90
From: Hariprasad Shenai haripra...@chelsio.com
Date: Fri, 16 Jan 2015 09:24:46 +0530
This patch series cleansup macros/register defines, defined in t4.h and
t4fw_ri_api.h and all the affected files.
This patch series is created against net-next tree and includes patches on
iw_cxgb4 tree.
Hi Doug,
Thank you for the quick response.
Now I can see 2 issues, that I want to draw your attention to:
1. if there is a mcg that the driver failed to join, the mc_task enters to
endless loop of re-queue, and the log will be full with the next messages:
[682560.569826] ib0: no multicast
On 1/12/2015 12:11 PM, ira.we...@intel.com wrote:
From: Ira Weiny ira.we...@intel.com
OPA_MIN_CLASS_VERSION -- OPA Class versions are 0x80
OPA_SMP_CLASS_VERSION -- Defined at 0x80
OPA_MGMT_BASE_VERSION -- Defined at 0x80
Increase max management version to accommodate OPA
Allocation of
14 matches
Mail list logo
