On Thu, May 24, 2012 at 6:42 PM, Hefty, Sean wrote:
> I believe that I was *just* hitting into this bug.
Good, so we came just in time.
> I don't understand the part about breaking the ABI. Why wouldn't you just
> return the correct values from the kernel? Are the values being returned
> now
I'm sending these patches as a response to Sean's query, basically
I was planning to do so little bit later with more patches, but
here they are.
Or.
Sagi Grimberg (2):
Limit qp resources accepted for ibv_create_qp()
Report correct resource limits to a new user context
src/mlx4.c | 13 ++
From: Sagi Grimberg
When creating a new user context, query device for various limits,
for use in sanity checks and other resource limitation needs.
Passing needed info back to userspace in this manner is preferable
to breaking the ABI.
Signed-off-by: Jack Morgenstein
Signed-off-by: Sagi Grimb
From: Sagi Grimberg
Use the limits reported in ib_query_device(). Make sure that the limits
returned to the caller following qp creation also lie within the
reported device limits.
Signed-off-by: Sagi Grimberg
Signed-off-by: Jack Morgenstein
Signed-off-by: Or Gerlitz
---
src/mlx4.h | 16 +
> We are trying to figure out the cause for RDMA_CM_EVENT_ROUTE_ERROR
> errors after a failover event of the bonding driver.
> The event status returned is -EINVAL. To gather further information on
> when this EINVAL is returned,
> I added some debug which showed 3 for mad_hdr.status in the below
>
Hello,
We are trying to figure out the cause for RDMA_CM_EVENT_ROUTE_ERROR
errors after a failover event of the bonding driver.
The event status returned is -EINVAL. To gather further information on
when this EINVAL is returned,
I added some debug which showed 3 for mad_hdr.status in the below
Signed-off-by: Hal Rosenstock
---
diff --git a/src/ibportstate.c b/src/ibportstate.c
index 5559d18..9bf6f4a 100644
--- a/src/ibportstate.c
+++ b/src/ibportstate.c
@@ -654,7 +654,7 @@ int main(int argc, char **argv)
} else {
if (fdr10e & FDR1
On Thu, 24 May 2012 15:10:23 +0300
Alex Netes wrote:
> The issue is resolved by adding High priority unicast FIFO queue to the VL15
> poller thread.
>
> Signed-off-by: Vladimir Koushnir
> Signed-off-by: Alex Netes
> ---
> include/opensm/osm_sm.h |7 +--
> include/opensm/osm_vl15
espeed and fdr10
Signed-off-by: Hal Rosenstock
---
diff --git a/src/ibportstate.c b/src/ibportstate.c
index 5559d18..c633a45 100644
--- a/src/ibportstate.c
+++ b/src/ibportstate.c
@@ -350,8 +350,8 @@ int main(int argc, char **argv)
uint16_t devid, rem_devid;
long val;
cha
> 1. Limit max number of wqes per QP reported when querying the device,
> so that ib_create_qp will never fail due to any additional headroom WQEs
> allocated.
>
> 2. Limit qp resources accepted for ib_create_qp() to the limits
> reported in ib_query_device(). In kernel space, make sure that
> the
CX3 devices can work with 64 or 32 byte CQEs/EQEs. Using 64 byte
EQEs/CQEs allow better utilization of new chipsets and gaining higher
performance. This patch queries the HCA's capabilities and if it
supports BOTH 64 byte CQEs and EQES will configure the HW to work
in 64 byte mode. Note that the 32
From: Sagi Grimberg
1. Limit max number of wqes per QP reported when querying the device,
so that ib_create_qp will never fail due to any additional headroom WQEs
allocated.
2. Limit qp resources accepted for ib_create_qp() to the limits
reported in ib_query_device(). In kernel space, make sure
From: Shlomo Pongratz
Commit e605b743f "IB/mlx4: Increase the number of vectors (EQs) available
for ULPs" didn't handle correctly the case where there aren't enough MSIX
vectors to increase the number of EQs, such that only the legacy EQs are
allocated. This resulted in an attempt to memset to ze
From: Jack Morgenstein
Commit 096335b3f (mlx4_core: Allow dynamic MTU configuration for IB
ports) modifies the port VL setting. This exposes a bug in procedure
mlx4_common_set_port(), where the VL cap value passed in (inside the
command mailbox) is incorrectly zeroed-out. The problem flow is as
Hi Roland,
So here's a batch with three fixes to the mlx4 driver, I still don't
have the patch that deals with fixing the MTT scaling by RAM size ready,
hope to get there next week.
Jack Morgenstein (1):
net/mlx4_core: Fix setting VL_cap in mlx4_SET_PORT wrapper flow
Sagi Grimberg (1):
IB/m
Terminate receive processing when SMP status is not 0
Signed-off-by: Hal Rosenstock
Signed-off-by: Alex Netes
---
opensm/osm_sminfo_rcv.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/opensm/osm_sminfo_rcv.c b/opensm/osm_sminfo_rcv.c
index 6f0b099..ff4d209 10064
These log messages should be issued only if current operational vl/neighbor mtu
are different from calculated operational vl/neighbor mtu.
Signed-off-by: Vladimir Koushnir
Signed-off-by: Alex Netes
---
include/opensm/osm_port.h | 12 +-
opensm/osm_lid_mgr.c |6 +++-
opensm/os
The issue is resolved by adding High priority unicast FIFO queue to the VL15
poller thread.
Signed-off-by: Vladimir Koushnir
Signed-off-by: Alex Netes
---
include/opensm/osm_sm.h |7 +--
include/opensm/osm_vl15intf.h | 15 +--
opensm/osm_req.c |6 +++
On Thu, May 24, 2012 at 1:07 AM, Ursula Braun wrote:
> we want to make use of Infiniband communication and I am working on the
> Linux part. The peer can be a non-Linux system. Now we see a mismatch in
> the size of the queue pair number in Linux (32 bits) and the Infiniband
> Architecture Specifi
Hi,
we want to make use of Infiniband communication and I am working on the
Linux part. The peer can be a non-Linux system. Now we see a mismatch in
the size of the queue pair number in Linux (32 bits) and the Infiniband
Architecture Specification (24 bits). Will the additional 8 highest
order bit
Hi Hector,
Do you see any errors/warnings in the SM's log, when you run opensm with high
verbosity (>VERBOSE)?
On 14:51 Wed 23 May , Hector Abrach wrote:
> Hello,
>
> I was hoping you could help me if at all just give me some pointers as
> to what my problem may be.
>
> I have a problem wit
21 matches
Mail list logo
