On 02/27/14 12:32, Sagi Grimberg wrote:
As I recall (need to re-confirm this), the problem was that in unstable
ports condition srp_abort is
called invoking srp_free_req (unmap call #1) and reconnect process (or
reset_device or terminate_io)
finishes all requests in the request ring (unmap
From: Alex Netes ale...@mellanox.com
Date: Mon, 3 Dec 2012 14:45:24 +0200
This reverts commit f4722b0f833ed7a060f80b6757cfb9af78252678.
This patch is no longer needed since first_master_sweep is now set
when reaching MASTER state even if SM was in MASTER before. This is
equivalent to the
Regarding the comment in the reverted patch:
- 3. set_client_rereg_on_sweep is TRUE. The one situation in which
this
- is true but first_time_master_sweep is FALSE is when the SM receives
- a HANDOVER while in master. We don't want to re-setup everything by
-
From: Alex Netes ale...@mellanox.com
Date: Thu, 18 Jul 2013 11:08:14 +0300
We should clear first_time_master_sweep anyway during the first sweep.
Signed-off-by: Alex Netes ale...@mellanox.com
---
opensm/osm_state_mgr.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git
On 3/6/2014 12:04 AM, Nicholas A. Bellinger wrote:
On Wed, 2014-03-05 at 14:12 +0200, Sagi Grimberg wrote:
On 3/5/2014 2:06 AM, Nicholas A. Bellinger wrote:
On Tue, 2014-03-04 at 17:17 +0200, Sagi Grimberg wrote:
On 3/4/2014 2:00 AM, Nicholas A. Bellinger wrote:
From: Nicholas Bellinger
On 3/6/2014 8:01 AM, Alex Netes wrote:
Before this patch, when SM in Master state finds other Master SM, it
sends trap144 to previously found Master SM/SM with higher priority when
it was in Discovering/Standby state.
This can lead to wrong behaviour in a multi-SM topolgy:
Setup: SM1 with
On 3/6/2014 11:10 AM, Bart Van Assche wrote:
On 02/27/14 12:32, Sagi Grimberg wrote:
As I recall (need to re-confirm this), the problem was that in unstable
ports condition srp_abort is
called invoking srp_free_req (unmap call #1) and reconnect process (or
reset_device or terminate_io)
On 3/6/2014 5:32 PM, sagi grimberg wrote:
On 3/6/2014 11:10 AM, Bart Van Assche wrote:
On 02/27/14 12:32, Sagi Grimberg wrote:
As I recall (need to re-confirm this), the problem was that in
unstable
ports condition srp_abort is
called invoking srp_free_req (unmap call #1) and reconnect
Hi Roland,
Is it okay to send next series of patches even if previous series is not
accepted yet in your tree? Off-course I will cut patches on top of previous
series of patches.
-Regards
Devesh
-Original Message-
From: linux-rdma-ow...@vger.kernel.org
On Wed, Mar 05, 2014 at 17:58:19 -0600, Steve Wise wrote:
BTW, if you're frustrated from having to send these patches so many
times because of changes being requested, this is the main reason
why you shouldn't queue up such enormous numbers of patches at one
time.
Please try to
10 matches
Mail list logo