Hi all,
Is the OpenIB subversion repository dead at the moment? It's just
sitting there for me when I try to do an update or a checkout.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934
.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain View, CA 94043
:-)
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain View, CA 94043.
___
openib-general mailing
,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain View, CA 94043
, you know about that, then ;-) Oddly enough, it doesn't affect me
when I try to build 2.6.13: must be something either to do with the
Lustre patch or something else in his .config that I don't have.
Anyway, the patch he sent me is attached. It's pretty simple.
Regards,
Robert.
--
Robert Walsh
tonight or tomorrow.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain View, CA 94043
and finishing the userland stuff. Thanks for doing this!
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain View, CA 94043
.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain View, CA 94043
signature.asc
Description: This is a digitally signed message
I got my system set up again. I needed the following patch to work
with the latest kernel (which no longer has io_remap_page_range). I'm
also throwing in a warning cleanup.
Applied.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc
. libipath is already taken with something
else we ship, so I can't use that.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain View
over well here. The next thing is, can svn handle
directory name changes?
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain View
the old directory and created a new one.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain View, CA 94043
for the feedback. We're going to review all of these early next
week and we'll get back to you then.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200
, then the
2.6.15 window for core changes will close by the end of next week, so
it's a good idea to get any generic stuff merged ASAP]
Right.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934
Hi all,
Is multipathing implemented/working in OpenIB?
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain
,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain View, CA 94043.
___
openib
Hi all,
There was some discussion back in Sep/Oct about ip_dev_find. Was there
ever a resolution to this? Are we just waiting to get the modules that
use it put into the kernel so we can justify getting it re-exported once
again?
Regards,
Robert.
--
Robert Walsh
.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain View, CA 94043.
___
openib-general
set_page_dirty_lock().
OK.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain View, CA 94043
On Sat, 2005-12-17 at 14:38 +0200, Pekka Enberg wrote:
On 12/17/05, Roland Dreier [EMAIL PROTECTED] wrote:
+#define TRUE 1
+#define FALSE 0
Please kill these.
OK.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone
inlines instead for readability.
OK.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain View, CA 94043
a very odd wrapper anyway?
The volatile is there so the compiler doesn't optimize away the read.
This is important, because reads of our hardware have side-effects and
cannot be optimized out.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc
as unsigned long long.
Some use unsigned long. Best way of implmenting the all-ones pattern is
just `-1'.
OK.
Gee. Big driver.
Tell me about it :-) Basically, we're doing infiniband in software: no
offload.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL
+ movl %edx,%ecx
+ rep
+ movsd
+ ret
err, we have a portability problem.
Any chance we could get these moved into the x86_64 arch directory,
then? We have to do double-word copies, or our chip gets unhappy.
Regards,
Robert.
--
Robert Walsh Email
() and family most like; they already take
care of this anyway.
Oh, OK then.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428
what I can do.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain View, CA 94043
) including a description what and how you are measuring?
I'll try get around to this after my vacation and after we've had time
to absorb and address all the other feedback we received.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc
On Sat, 2005-12-17 at 19:10 -0800, Andrew Morton wrote:
Robert Walsh [EMAIL PROTECTED] wrote:
+int ipath_mlock(unsigned long start_page, size_t num_pages, struct
page **p)
OK. It's perhaps not a very well named function.
Really? Suggestion for a better name
. the Linux Networx LS/X.)
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain View, CA 94043
On Sun, 2005-12-18 at 04:27 +0100, Andi Kleen wrote:
Robert Walsh [EMAIL PROTECTED] writes:
Any chance we could get these moved into the x86_64 arch directory,
then? We have to do double-word copies, or our chip gets unhappy.
Standard memcpy will do double word copies if everything
this driver. To avoid breaking
`make allmodconfig'.
How about we implement a portable version in C that you get
by default if you don't implement the assembler routine?
Pretty please? :-)
Sure. :-)
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc
a closer look.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain View, CA 94043
compared to -objs
No problem.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain View, CA 94043
in magic typedef for s32 and friends in userland, that won't work,
hence we use the C standard typedefs.
Is this a problem?
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court
that all files in there have. For
consistency, I'll leave it as EXPORT_SYMBOL, but I don't have any real
problems with it either way.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
the feedback from lkml.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain View, CA 94043
On Fri, 2006-02-10 at 16:51 -0800, Roland Dreier wrote:
Here is a series of patches that adds a new function ib_modify_qp_is_ok(),
which low-level drivers can use to replace boilerplate logic for
validating the parameters to the modify_qp method.
In addition to getting rid of duplicated
libsysfs is unmaintained, and the main user of it (udev) has stopped
using it. So it's going to bitrot and get dropped from distros. And
libsysfs kind of sucks too.
Fair enough - that's a good reason.
Regards,
Robert.
signature.asc
Description: This is a digitally signed message part
about this (I was swamped
with unrelated stuff.) I'll try get someone else here at PathScale to
get these numbers.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court
mounting it on /ipathfs. Not that the difference is
terribly important. But if you do have suggestions on where this kind
of thing should go, I'd love to hear it.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc
out the
guts of ipath_mad.c and had it pass the requests to the userspace SMA,
we'd still have to have the diversion path in there for cases where the
IB stack isn't around.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone
be used by the ipath_ether driver. That
would be a good cleanup too but I'll leave that for another day.
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
Thanks, Roland. I'll merge them in as appropriate.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED
- dev-node_type = IB_NODE_CA;
+ dev-node_type = RDMA_NODE_IB_CA;
Which of these #defines is valid in 2.6.17? Just curious. What we have
in svn matches what you put in your git tree, you see... Perhaps an
#ifdef until 2.6.17 goes through?
Regards,
Robert.
--
Robert Walsh
. The svn tree has some iWARP-related
changes that make it RDMA_NODE_IB_CA, but those haven't been merged
upstream and won't be in 2.6.17.
Would an ifdef be OK?
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650
it for ages.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
QLogic Corporation Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain View, CA 94043
Do we have any CentOS 4.2 or 4.3 machines?
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain View, CA 94043
On Tue, 2006-04-11 at 15:31 -0700, Robert Walsh wrote:
Do we have any CentOS 4.2 or 4.3 machines?
People on openib-general can ignore this :-) I meant to send it to an
internal alias. Sorry for the bother.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL
in OpenFabrics, but just about every developer here shot the
idea down as a step backwards, development-wise. Chalk that one
up to religion.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
QLogic Corporation
updates
from the libipathverbs end.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain View, CA 94043
It does seem to be a scalability problem for some devices/workloads,
and Robert Walsh from qlogic was planning on looking at this
(replacing the mutex with a reference counting scheme). I don't know
if he's started on this or not.
Not yet, but I'll be starting this as soon as I'm done
On Mon, 2006-06-12 at 12:36 -0700, Roland Dreier wrote:
IB/uverbs: Don't serialize with ib_uverbs_idr_mutex
This looks good - I had started something similar but your solution
solves some problems mine had (by using the live flag, even if it is
kind of bleh.)
Regards,
Robert.
--
Robert Walsh
. I'll fix that up, too.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain View, CA 94043.
signature.asc
On Fri, 2006-06-16 at 15:07 -0700, Roland Dreier wrote:
Robert, can you confirm that the new uverbs locking scheme helps the
performance problems you're having?
Sure - I'll take a look on Monday.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED
On Fri, 2006-06-16 at 15:07 -0700, Roland Dreier wrote:
Robert, can you confirm that the new uverbs locking scheme helps the
performance problems you're having?
Yup - that was a big help. Thanks!
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED
the SMA, maybe?
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain View, CA 94043.
signature.asc
Description: This is a digitally
On Mon, 2006-06-26 at 15:53 -0700, Robert Walsh wrote:
On Mon, 2006-06-26 at 17:53 -0400, Pete Wyckoff wrote:
Using stock 2.6.17.1, with verbs 1.0.3-1.fc4 and mthca 1.0.2-1.fc4
with MT25204, this line:
ret = ibv_query_device(ctx, hca_cap);
tells me that hca_cap.max_sge = 30
Roland Dreier wrote:
Sean Why not remove your code from SVN?
Along those lines, how would people feel if I removed the mthca kernel
code from svn, and just maintained mthca in kernel.org git trees? I
am getting heartily sick of double checkins for every mthca change...
I think this is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roland Dreier wrote:
1) What makes ipath special so that we want this warning for ipath
devices but not other IB hardware?
There's nothing special about our hardware that requires this. We just
wanted that in there so we could direct customers to
Roland Dreier wrote:
Michael Looks like your devices are all single-port. With a multi
Michael port device it is quite common to have one port down.
My reading of the patch is that it warns if the link is up physically
but does not come up logically. Which would still be reasonable
J Why not copy what most ethernet drivers do and just log a message on
link negotiation state changes? ie like the:
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
Maybe something like:
ib0: link up, 10Gbps, port active, lid 0x10/16
That's a neat idea.
Woodruff, Robert J wrote:
Robert Walsh wrote,
[0][rdma_iba_priv_intel.c:429] error(0x60029): OpenIB-cma: Could not
create DAPL endpoint: DAT_INVALID_PARAMETER(DAT_INVALID_ARG6)
[1][rdma_iba_priv_intel.c:429] error(0x60029): OpenIB-cma: Could not
create DAPL endpoint: DAT_INVALID_PARAMETER
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Walsh wrote:
Hi all, I installed the RC3 package on my Xeon/Lindenhurst platforms
and with the pathscale card I have the following problem
when trying to run Intel MPI and NetPipe.
Actually, I've been trying to run Intel MPI myself
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hmm, if you have a debug version of the DAPL library, can you enable
debug messages,
export DAPL_DBG_TYPE=0x
That may give us more information. I will also have Arlin take a look
at this when returns on Tues.
I've been using the stuff from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arlin Davis wrote:
Robert,
Here is a slightly modified patch for your attributes issue. Can you give it
a try?
I'll give it a spin this afternoon: it looks quite a bit more
comprehensive than the small patch I did.
Regards,
Robert.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Just added all appropriate RDMA in/out fields and some code to zero out
the structure to avoid uninitialized data fields.
Yup. By comprehensive, I meant better :-)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arlin Davis wrote:
Robert,
Here is a slightly modified patch for your attributes issue. Can you give it
a try?
Oddly enough, I'm back to the same problem with your new patch as I saw
with the unpatched version:
$ mpiexec -n 2 ./a.out
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Oddly enough, I'm back to the same problem with your new patch as I saw
with the unpatched version:
Hmmm. We ran this with OFED 1.1 RC3 and MPI 3.0b on an EM64T server with your
adapter and it worked.
Weird - it's not working for me at all.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Woodruff, Robert J wrote:
Robert Walsh wrote,
I'll give it a spin this afternoon: it looks quite a bit more
comprehensive than the small patch I did.
I also just tried running the ib_rdma_bw test and it seems to
be flaky if you stress
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Here is a slightly modified patch for your attributes issue. Can you give it
a try?
I rebuilt OFED from scratch with the patch, and ran successfully on
Intel MPI 2.0.1 with the refresh patch. I could not get it to run on
Intel MPI 3.0b. If you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tziporet Koren wrote:
Robert Walsh wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Here is a slightly modified patch for your attributes issue. Can you
give it a try?
I rebuilt OFED from scratch with the patch, and ran
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I spoke with our MPI team lead and it is very likely that the fix that
is in 2.0.1-refresh did not make it into 3.0 beta, but it should be
in the 3.0 release schedule to be completed in a couple of weeks.
OK then - I'll wait for that.
Regards,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Woodruff, Robert J wrote:
Robert Walsh wrote,
I'll give it a spin this afternoon: it looks quite a bit more
comprehensive than the small patch I did.
I also just tried running the ib_rdma_bw test and it seems to
be flaky if you stress
Could be a library function in core so that ipath etc can reuse it.
But note how there's no dependency between drivers here - no
reason to block change in mthca until ipath/ehca implement this functionality,
too.
True. But FWIW, we (QLogic) could probably spin something like this
pretty
Somewhere between OFED-1.1-RC3 and -RC4, the ibv_driver_init function
was renamed to openib_driver_init. We at QLogic were aware this change
was being made and so now our user verbs support does not work at all in
RC4. Why did something like this happen between two release candidates?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I don't think you can do symbol versioning here.
Right - probably being a little more verbose about finding the file but
not the symbol would be a good idea, though. It took me a bit of gdb
work to track the problem down: not really a big deal, but
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I installed RC5 and now it just hangs,
[EMAIL PROTECTED] bin]$ ./ib_rdma_bw -n 1 -t 1000 -s 200 rkl-12
4702: | port=18515 | ib_port=1 | size=200 | tx_depth=1000 |
iters=1 | duplex=0 | cma=0 |
4702: Local address: LID 0x03, QPN
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I installed RC5 and now it just hangs,
Wow - we can't even get RC5 to build here. What distro are you running?
I've tried this on RC4 + a fixed libipathverbs package and it runs OK
(although it does take a while, which might explain the hang you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Woodruff, Robert J wrote:
Robert Walsh wrote,
[EMAIL PROTECTED] bin]$ ./ib_rdma_bw -n 1 -t 1000 -s 200 rkl-12
4730: | port=18515 | ib_port=1 | size=200 | tx_depth=1000 |
iters=1 | duplex=0 | cma=0 |
4730: Local address: LID 0x03
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
We've got some patches to gen2_basic to fix some problems with the test
suite. Some are trivial (fix typos, etc.) and some are more serious
(handle max_qp counts correctly, etc.) I'm going to be sending them out
piecemeal as we review them
gen2_basic - fix some minor typos
Signed-off by: Robert Walsh [EMAIL PROTECTED]
diff -rNu a/gen2_basic/test_cq.c b/gen2_basic/test_cq.c
--- a/gen2_basic/test_cq.c 2006-07-27 13:42:44.857603000 -0700
+++ b/gen2_basic/test_cq.c 2006-08-14 14:17:17.352167000 -0700
@@ -1,5 +1,6
gen2_basic - fix up some compiler warnings
Create a new CHECK_PVALUE macro for checking pointers and use it where
appropriate. This makes a bunch of compiler printf warnings go away.
Signed-off by: Robert Walsh [EMAIL PROTECTED]
diff -rNu a/gen2_basic/test_cq.c b/gen2_basic/test_cq.c
gen2_basic - fix is_global settings for AH attributes
For valid address handles, the is_global field of the AH attribute should
not be a random number if the dlid is a multicast LID.
Signed-off by: Robert Walsh [EMAIL PROTECTED]
diff -rNu a/gen2_basic/main.h b/gen2_basic/main.h
--- a/gen2_basic
gen2_basic - make sure the DLID is valid
For valid address handles, make sure the DLID is not a multicast LID.
You can't modify a QP to use a multicast DLID using ib_modify_qp().
Signed-off by: Robert Walsh [EMAIL PROTECTED]
diff -rNu a/gen2_basic/test_cq.c b/gen2_basic/test_cq.c
gen2_basic - select a valid port number
Port numbers start at 1, not 0.
Signed-off by: Robert Walsh [EMAIL PROTECTED]
diff -rNu a/gen2_basic/test_poll_post.c b/gen2_basic/test_poll_post.c
--- a/gen2_basic/test_poll_post.c 2006-09-13 19:09:47.410808000 -0700
+++ b/gen2_basic
gen2_basic - handle case where max_sge 100
When choosing an illegal number of maximum SGEs, handle the case where
the device allows more than 100 SGEs.
Signed-off by: Robert Walsh [EMAIL PROTECTED]
diff -rNu a/gen2_basic/test_poll_post.c b/gen2_basic/test_poll_post.c
--- a/gen2_basic
Hal Rosenstock wrote:
On Tue, 2006-09-19 at 20:28, Robert Walsh wrote:
gen2_basic - select a valid port number
Port numbers start at 1, not 0.
True for CA and routers but not switches.
Yeah. Does anyone run gen2_basic on switches, though? I assumed it was
HCA-centric.
Regards,
Robert
Its easy to get linux running on a switch, so why not? You just
need to write a low level driver that cn send/receve MADs.
We did run a gen1 port on a switch at some point, and someone might want to
do it again.
OK - that's a fine project idea, but I'm not about to start coding it up
any
Dotan Barak wrote:
Dotan Barak wrote:
Robert Walsh wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
We've got some patches to gen2_basic to fix some problems with the test
suite. Some are trivial (fix typos, etc.) and some are more serious
(handle max_qp counts correctly
Hi Dotan,
I just noticed that you didn't apply one of my patch hunks that called
get_is_global(). I know why you didn't do it (the dlid is always 0: see
line 218 of test_av.c), but should you still be setting the is_global
field in the ah_attr structure to some value? Right now, it will just
be
Another quick question: I noticed that in the latest changes your
pushed, including my patches, you removed the following check in test_qp.c:
@@ -1702,7 +1700,6 @@
CHECK_VALUE(qp_type, query_init_attr.qp_type,
attr.qp_type, goto cleanup);
CHECK_VALUE_PTR(recv_cq,
gen2_basic - choose illegal max_qp_init_rd_atom values correctly
Signed-off by: Robert Walsh [EMAIL PROTECTED]
diff -rNu a/gen2_basic/test_qp.c b/gen2_basic/test_qp.c
--- a/gen2_basic/test_qp.c 2006-09-13 19:09:47.419791000 -0700
+++ b/gen2_basic/test_qp.c 2006-08-14 14:16:57.911621000
gen2_basic - handle auto path migration properly
Signed-off by: Robert Walsh [EMAIL PROTECTED]
diff -rNu a/gen2_basic/test_qp.c b/gen2_basic/test_qp.c
--- a/gen2_basic/test_qp.c 2006-09-13 19:15:59.829006000 -0700
+++ b/gen2_basic/test_qp.c 2006-08-14 14:16:57.911621000 -0700
@@ -586,6
gen2_basic - fix static_rate check
Make sure we're comparing apples to apples in the static_rate check.
Signed-off by: Robert Walsh [EMAIL PROTECTED]
diff -rNu a/gen2_basic/test_qp.c b/gen2_basic/test_qp.c
--- a/gen2_basic/test_qp.c 2006-09-13 19:17:17.835923000 -0700
+++ b/gen2_basic
gen2_basic - handle other vendor devices for max QP count
When choosing the actual max QP number, handle non-Mellanox devices too.
Make sure we only clean up the QPs we actually created.
Signed-off by: Robert Walsh [EMAIL PROTECTED]
diff -rNu a/gen2_basic/test_qp.c b/gen2_basic/test_qp.c
All the rest of the attributes (for example: is_global) are being set
with 0.
Oh, OK - I wasn't sure that you wanted it set that way or randomly like
it used to be. No biggie.
Regards,
Robert.
___
openib-general mailing list
Thierry Delaitre wrote:
I get the following when loading lustre o2ib module. I'm using ofed-1.1
rc6 on sles10 and i'm sure the ib modules are the ones recompiled for the
kernel i'm using and lustre too. I don't understand why i get the
following as i only have one version of the ib modules ?
Robert Walsh wrote:
The attached patch fixes this problem by deferring creation of our
diagpkt device until at least one piece of hardware has been found.
Of course, if I'd actually attached the patch, it might have been a bit
more useful :-)
IB/ipath - initialize diagpkt file on device init
The attached patch fixes this problem by deferring creation of our
diagpkt device until at least one piece of hardware has been found.
Michael: this will fix the OFED testing problem you were seeing.
Roland: please queue for 2.6.19.
Regards,
Robert.
Michael S. Tsirkin wrote:
Quoting r. Robert Walsh [EMAIL PROTECTED]:
Subject: Re: [openfabrics-ewg] OFED Status
The attached patch fixes this problem by deferring creation of our
diagpkt device until at least one piece of hardware has been found.
Michael: this will fix the OFED testing
This seems dangerous, especially now that we have PCI_MULTITHREAD_PROBE:
nothing prevents ipath_cdev_init() from being called twice. Better to
use something like test_and_set_bit() to make sure this is done
exactly once.
Well, it needs to be refcounted, as we need to create it on first
1 - 100 of 115 matches
Mail list logo
