On Thu, 2006-04-13 at 01:44, Roland Dreier wrote:
OK, I applied this by hand ... your mailer turned all your tabs into
spaces somewhere along the way, so the patch wouldn't apply.
Wow. That hasn't happened in a while. I used preformat on evolution the
same as the other patches so I'm not sure
Hi again Ron,
On Wed, 2006-04-12 at 23:46, Ronald G Minnich wrote:
Hal Rosenstock wrote:
hoq is HOQLife. Is slv the switch LifeTimeValue ?
I believe so.
Does that have anything to do with those settings ?
it would not work until hoq and slv were 17.
Truly hanging ?
yes, and
Sayantan Sur wrote:
Hello Roger,
With mvapich-0.9.7 it errors out in the building
stage with an error ibv_free_device_list/ibv_get_device_list missing,
I cannot find any of the ib libraries on RHEL4U3 that appear to contain
that library.
Thanks for trying out MVAPICH-0.9.7. Currently, we
Hello Roger,
Do you know if it would be possible to just replace the userspace
section and not mess with the kernel part of OpenIB? I am guessing
from what I have read that this is very possible, and only requires
me to remove the already existing RHEL rpms for OpenIB userspace
support.
Sayantan Roland, any thoughts on which SVN version of userspace
Sayantan support may work with the RHEL default RPMs?
Any version should work. It might be simpler to use stable releases
such as libibverbs-1.0.2 and libmthca-1.0.1.
- R.
___
Yes, I am trying the default version of RHEL4U3, alot of our
customers would much rather use unmodified RHEL, though I can probably
talk them out of it with a bit of work. They have some strange
ideas that RHEL is somehow guaranteed to work right, and from
what I can tell it won't
Scott wrote,
I didn't try MVAPICH, but I had no luck getting Open MPI 1.0.1 to work
with the RHEL4 U3 OpenIB code.
Not sure if you are interested in a comercial MPI or not, but we
did test Intel MPI with the RHEL4-U3 code and it worked fine, except
on Mellanox DDR cards.
woody
Hello Roger,
I'm just CC-ing this to openib-general for the community.
Thanks for giving us access. I have verified that the
`ibv_get_device_list' verb is indeed *missing* from the OpenIB install.
I'm afraid that given this Redhat rpm, it is difficult to get mvapich to
work (without patching
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
Nothing but replacing spaces with tabs. Please apply to svn and let
me know if it's OK to queue for upstream.
BTW, any progress on reviewing the static function cleanups I sent earlier?
drivers/infiniband/hw/ipath/ipath_intr.c |4 +
Hi Roland,
Please review this patch
+ introducing srp_sg_tablesize as module parameter
+ adjusting SRP_MAX_IU_LEN, SRP_MAX_INDIRECT from srp_sg_tablesize
+ throttling command per lun ie. max_cmd_per_lun can be passed in when
adding target (same as max_sect)
Signed-off-by: Vu Pham [EMAIL
Works like a charm...
-Viswa
On 12 Apr 2006 21:32:33 -0400, Hal Rosenstock [EMAIL PROTECTED] wrote:
On Wed, 2006-04-12 at 20:46, Hal Rosenstock wrote: On Wed, 2006-04-12 at 18:25, Viswanath Krishnamurthy wrote: The RMPP version needs to be 1. Thanks. I'm not sure what changed here to require
Roland Dreier wrote:
OK, I updated my rdma_cm branch with all of this.
In addition I put the following in -- it's idiomatic in the kernel to
let the compiler handle htons(A_CONSTANT) in code. Should I commit
this to svn too?
This change is fine. Please commit to svn too. Thanks.
- Sean
Hi Roland,
Apr 7 18:17:17 lab105 kernel: Unable to handle kernel paging request at
virtual address 6b6b6b6b6b6b6b6b
I think I fixed the bug causing this oops (I was able to reproduce it,
and I don't see it any more). I checked the following patch in and
queued it for kernel 2.6.17:
My
Ira Weiny wrote:
I have started writing a simple RDMA app which uses the rdmacm. I have gotten
the connection established, QP's and MR's set up, and have sent the RDMA ETH.
However, more and more I am getting the RNR Retry Counter Exceeded error back
from the client's post send of the RDMA ETH.
Hi,
With svn r6460, a new diags tool is now available on the trunk. It is
Ira Weiny's saquery. (Thanks for bearing with me on this).
saquery tool obtains information based on node name:
saquery -h
Usage: saquery [-h -d -P -N -L -G][name]
Queries node records by default
-d enable debugging
We just moved a cluster over to the latest redhat release, and opensm
seems to be having issues.
This is running the redhat provided kernel and opensm packages
[EMAIL PROTECTED] troy]# uname -r
2.6.9-34.ELsmp
[EMAIL PROTECTED] troy]# cat /etc/redhat-release
Red Hat Enterprise Linux WS release 4
Hi Troy,
On Thu, 2006-04-13 at 15:35, Troy Benjegerdes wrote:
We just moved a cluster over to the latest redhat release, and opensm
seems to be having issues.
This is running the redhat provided kernel and opensm packages
[EMAIL PROTECTED] troy]# uname -r
2.6.9-34.ELsmp
[EMAIL
As part of the libibverbs 1.1 release, I would like to remove the
dependency on libsysfs, since libsysfs is not very well maintained,
not consistent across distros, and the simple sysfs stuff we need is
easy to do directly.
In this direction, I've already made some changes to libibverbs to
reduce
Hmm, it's clearly a use-after-free bug. Based on
ip is at srp_reconnect_target+0x2b1/0x5c0 [ib_srp]
can you guess where it is in the SRP driver or what it's accessing?
Also this is happening because the connection is being reconnected,
because SCSI commands are timing out. Do you have any
Roland Hmm, it's clearly a use-after-free bug.
(...because 6b is the slab poisoning free value, and the oops is at
6b6b6b6b6b6b6b6b...)
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To
One stupid but useful way to narrow this down would be to reproduce
the crash with the following patch applied on top...
Index: linux-kernel/infiniband/ulp/srp/ib_srp.c
===
--- linux-kernel.orig/infiniband/ulp/srp/ib_srp.c
Dotan Barak wrote:
Hi.
thanks for the quick response.
I executed the dtest with the -v parameter and here is the output of both sides.
I added the test the '-l' parameter to be able to change to dapl provider in
command line (if you wish i can post you a patch).
full server output:
Arlin Davis wrote:
What does driver IBED-1.0-rc3 consist of?
I think that we want all IBED release issues to go directly to the IBED release
team.
- Sean
___
openib-general mailing list
openib-general@openib.org
I'm trying to compile the svn 6462 snapshot with linux-2.6.17-rc1 on a
RHEL4 based system.
I get the following error for addr.c:
CC [M] drivers/infiniband/core/index.o
CC [M] drivers/infiniband/core/addr.o
In file included from drivers/infiniband/core/addr.c:38:
On Thursday 13 April 2006 16:32, Matt Leininger wrote:
I'm trying to compile the svn 6462 snapshot with linux-2.6.17-rc1 on a
RHEL4 based system.
Are you building the ipath driver out of the kernel.org tree, or out of svn?
If the latter, you have to patch the kernel and rebuild it first.
On Thu, 2006-04-13 at 16:40 -0700, Bryan O'Sullivan wrote:
On Thursday 13 April 2006 16:32, Matt Leininger wrote:
I'm trying to compile the svn 6462 snapshot with linux-2.6.17-rc1 on a
RHEL4 based system.
Are you building the ipath driver out of the kernel.org tree, or out of svn?
If
On Thursday 13 April 2006 16:51, Matt Leininger wrote:
Are you building the ipath driver out of the kernel.org tree, or out of
svn? If the latter, you have to patch the kernel and rebuild it first.
Out of svn. I have the drivers/infiniband pointing to the svn tree.
Yes, that won't work,
On Thu, 2006-04-13 at 16:54 -0700, Bryan O'Sullivan wrote:
On Thursday 13 April 2006 16:51, Matt Leininger wrote:
Are you building the ipath driver out of the kernel.org tree, or out of
svn? If the latter, you have to patch the kernel and rebuild it first.
Out of svn. I have the
On Thursday 13 April 2006 16:56, Matt Leininger wrote:
Ok. So the current state is that the mainline devel branch will be
broken for a while?
I have no idea. The current situation is fairly annoying, though.
b
___
openib-general mailing
As part of the libibverbs 1.1 release, I would like to remove the
dependency on libsysfs
I highly approve of this move.
the simple sysfs stuff we need is easy to do directly.
I was looking at it earlier this week and came to the same conclusion.
Johann
Matt If I remove include/rdma (which I had to do in the past)
Matt then some of the pathscale code fails to compile. Here is
Matt the error:
Yes, you need the patch below for the ipath directory. I sent this to
pathscale a while ago but it seems to take a while for patches to make
Bryan Is the goal of this to make sure that new hardware-specific
Bryan libraries will work with old libibverbs? How likely do you
Bryan think that is to happen? I don't see much of a problem
Bryan with simply breaking backwards compatibility here, since it
Bryan seems
Here are the latest IPoIB results:
For mthca I saw a range of 380-424 MB/s. The local CPU utilization on
the send side dropped for the 380 MB/s, from 98% to 70%
For ipath it was 310 MB/s. The local CPU utilization on the send side
was always around 30%.
- Matt
Mellanox benchmarks are
33 matches
Mail list logo
