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.
> > >
> >
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
[mailto:linux-rdma-ow...@vger.k
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 proces
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)
finishes
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 w
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 priority 1, SM2 with priority 2, SM3 with prior
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
From: Alex Netes
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
---
opensm/osm_state_mgr.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/opensm/osm_state_mgr.c b/opensm/osm_state_
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
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 set_client_rereg_on_sweep f
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 (unm
11 matches
Mail list logo
