Dear All,
I would like know the QDR Infinibad cards will support to back to back
connectivity or not ie with out IB swicth to enable the IB communication
between the two machines .
Regards
laxman
_
We all see it as it
Simplify (and unify) forwarding tables setup decision flow.
Signed-off-by: Sasha Khapyorsky sas...@voltaire.com
---
opensm/opensm/osm_ucast_mgr.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/opensm/opensm/osm_ucast_mgr.c b/opensm/opensm/osm_ucast_mgr.c
index
The function set_next_lft_block() is called in loop with block number
incremented, inside it loops by itself in looking for changed block,
caller will call this function with original block number incremented
so this internal loop could be repeated again and again. This patch
cleans this
-2.6.16.60-0.21-smp
Log:
/home/vlad/tmp/ofa_1_5_kernel-20090828-0200_linux-2.6.16.60-0.21-smp_x86_64_check/net/rds/cong.c:
In function 'rds_cong_clear_bit':
/home/vlad/tmp/ofa_1_5_kernel-20090828-0200_linux-2.6.16.60-0.21-smp_x86_64_check/net/rds/cong.c:301:
error: implicit declaration of function
Hal Rosenstock hal.rosenst...@gmail.com wrote on 27.08.2009 15:31:40:
I don't think it should be hard coded. IMO it would be better to default
to 18
and somehow able to be adjusted (via a (dynamic) module parameter ?).
I don't see how making this a parameter would benefit any end user, while
Per MgtWG RefID #4503
Signed-off-by: Hal Rosenstock hal.rosenst...@gmail.com
---
diff --git a/opensm/opensm/osm_helper.c b/opensm/opensm/osm_helper.c
index 3692474..1b83a9e 100644
--- a/opensm/opensm/osm_helper.c
+++ b/opensm/opensm/osm_helper.c
@@ -531,7 +531,7 @@ const char
On 8/28/09, Sasha Khapyorsky sas...@voltaire.com wrote:
Simplify (and unify) forwarding tables setup decision flow.
Seems to work for all engines but I got a failure for a test case where lash
fell back to min hop:
lash_core: ERR 4D02: Lane requirements (9) exceed available lanes (8) with
I would like know the QDR Infinibad cards will support to back to
back connectivity or not ie with out IB swicth to enable the IB
communication between the two machines .
Yes, any IB port should be able to connect to any other IB port. You do
need a subnet manager (SM) on every IB
Given that you seem to like the rest of the code and Jason hasn't spoken
up yet, I think we can have Roland merge this patch. Roland, what do you
think?
I don't see any problem with the idea and this does sound like a step
forward, so I am planning on merging this (pending review).
It seems we only had positive responses to moving from general@ to a new
linux-r...@vger.kernel.org list, so I'll work on a transition plan.
For now, please continue to use gene...@lists.openfabrics.org. However,
you may want to subscribe to the vger list to be ready for the
transition; for
checkpatch output:
WARNING: suspect code indent for conditional statements (8, 12)
#88: FILE: drivers/infiniband/hw/mlx4/main.c:345:
+ if (!dev-ib_active)
+ return ERR_PTR(-EAGAIN);
ERROR: code indent should use tabs where possible
#107: FILE:
thanks, applied (and thanks for the detailed changelog, that really
makes things easier)
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit
On 8/28/09, Sasha Khapyorsky sas...@voltaire.com wrote:
The function set_next_lft_block() is called in loop with block number
incremented, inside it loops by itself in looking for changed block,
caller will call this function with original block number incremented
so this internal loop could
Fixes builds on FC11.
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
libibumad/Makefile.am |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libibumad/Makefile.am b/libibumad/Makefile.am
index 50222df..27c6ff2 100644
--- a/libibumad/Makefile.am
+++
Hi,
LASH uses osm_switch_t:priv to reference private data that persists between
calls to the routing engine. The first patch fixes a use-after-free bug
that occurs due to this reference, when a switch is removed from a fabric
that LASH is routing.
The second patch applies the same methodology
When LASH is run against ibsim, valgrind reports the following
(on x86_64) after a switch is removed from the fabric:
==15699== Invalid write of size 8
==15699==at 0x45FD8A: switch_delete (osm_ucast_lash.c:648)
==15699==by 0x461483: lash_cleanup (osm_ucast_lash.c:1123)
==15699==by
Although no routing engine currently uses osm_port_t:priv to reference
routing engine data that is persistent between calls to the engine,
one may be added in the future.
Since this type of bug was just fixed for osm_switch_t:priv, fix up
osm_port_t to use the same mechanism.
Signed-off-by: Jim
17 matches
Mail list logo
