Tziporet Koren wrote:
Or Gerlitz wrote:
In one of our tests that is doing up/down of the driver we see some
deadlock when this patch is used, and it does not happened when its
removed.
Thus we decided to remove this patch till we get to the root cause of
the problem
Note that we do not think
OFED-1.2.5.4 is ready:
http://www.openfabrics.org/downloads/OFED/ofed-1.2.5/OFED-1.2.5.4.tgz
Changes since OFED 1.2.5
- RDS:
- Performance enhancements
- GA for Oracle 11
- IPoIB:
- Use NAPI by default
- For small received packets, allocate a new, smaller
Meeting Summary:
1. We must get bugzilla fixed ASAP to track OFED 1.3 bugs - Jeff B.
2. RC1 is delayed to next week since there were no builds for almost a week
3. Beta release testing status:
* Voltaire: See issues with:
o TCP performance of ConnectX (30% worst then Arbel on UD
Hello Tziporet!
This is our test status:
* Tested ehca, ehca2 on SLES10 ppc64 and upstream kernel
* RHEL4.5, RHEL5.1 and other backport test will be next
* Build process works great (basic, custom, 32/64-bit libs)
Thanks
Nam
[EMAIL PROTECTED] wrote on 04.12.2007 10:34:55:
Meeting Summary:
1.
Hi,
I don't have access to such platform in Mellanox and from the log I
don't really understand the problem.
Can I get remote access to the machine ?
Regards,
Pasha.
Woodruff, Robert J wrote:
I get the following build error trying to build
mvapich on ia64 on RedHat EL5.1 using today's OFED
Tziporet Koren wrote:
Or Gerlitz wrote:
I understand that this patch does not exist in OFED 1.3, correct?
correct - but don't worry for the bugs we see new oops even with IPoIB
vanilla from 2.6.24-rc3 :-(
I see, how about sending the oop trace to the general list?
Or.
It also might be useful to see if a simple program including netdb.h can
compile on the system. We could find out if the error is really in the
system header files or due to some other interaction.
#include netdb.h
int foo(int i) {
return i 1 ? i * foo(i - 1) : 1;
}
Pavel Shamis
OK, I just pushed out a few more small cleanups (running unifdef,
fixing signedness warnings, and fixing a locking bug on an error
path). One question: what is the point of the monkeying with
SPIN_BUG_ON on in nes.c?
- R.
___
ewg mailing list
#ifdef NES_NAPI
Is #ifdef napi sprinkled throughout the code common for most drivers? Is
there
a better way to handle this? (Is this OFED only for backports, or for
upstream?)
Is there any reason why we want the upstream kernel to have both NAPI
and non-NAPI support? If so, then
OK, I just pushed out a few more small cleanups (running unifdef,
fixing signedness warnings, and fixing a locking bug on an error
path). One question: what is the point of the monkeying with
SPIN_BUG_ON on in nes.c?
Probably just some leftover debugging. I can remove it.
Thanks for
It looks like there is something corrupt with the tarball.
13:29:50 tar xzf OFED-1.2.5.4.tgz
gzip: stdin: unexpected end of file
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
Ira
On Tue, 4 Dec 2007 10:34:48 +0200
Tziporet Koren
Here is an issue we have:
struct ibv_context {
struct ibv_device *device;
struct ibv_context_ops ops;
int cmd_fd;
int async_fd;
int num_comp_vectors;
pthread_mutex_t mutex;
Here is an issue we have:
struct ibv_context {
struct ibv_device *device;
struct ibv_context_ops ops;
int cmd_fd;
int async_fd;
int num_comp_vectors;
pthread_mutex_t
BTW, sifting through the OFED 1.3 libibverbs tree, I do see that the
commit to add max_xrc_domains to struct ibv_device_attr did break
things by adding the member in the middle of the structure (so that an
app compiled against the old header will see bogus values for
local_ca_ack_delay and
oops, sorry... I see that the very next OFED 1.3 commit reverted that
change, so things aren't as bad as I thought.
Never mind.
- R.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
I think the problem is that sizeof struct ibv_context_ops has changed, so
the new driver returns a
big struct ibv_context, app compiled with older header file has a smaller
struct ibv_context and
use the old offset to find fields after ops.
--CQ
-Original Message-
From: Roland
I think the problem is that sizeof struct ibv_context_ops has
changed, so the new driver returns a big struct ibv_context, app
compiled with older header file has a smaller struct ibv_context
and use the old offset to find fields after ops.
Oh crud, you're obviously right. For some
17 matches
Mail list logo
