Quoting r. Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: pingpong problem
Hi!
I'm running on x86_64 64 bit user and kernel space.
the pingpong test does not seem to work with size other than the
default 4096 (I am running with external loopback):
Tried again today after a reboot and could
The pd is already allocated when idr_pre_get is called. So, must deallocate
on error.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
Index: core/uverbs_cmd.c
===
--- core/uverbs_cmd.c (revision 1922)
+++ core/uverbs_cmd.c
Hi, Roland!
I'd like to suggest extending ibv_reg_mr to pass the
virtual address for RDMA, in addition to the CPU virtual address.
Currently it seems they are assumed to be the same, but there
does not appear to be an actual reason to enforce this limitation.
For example, I am now writing a
Declare qp_access_flags with the appropriate enum type.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
Index: userspace/libibverbs/include/infiniband/verbs.h
===
--- userspace/libibverbs/include/infiniband/verbs.h (revision
Below is an agenda for the call:
+ Additional Items?
+ Enumerate Tasks:
- uDAPL
who: Arlin Davis at Intel
- kDAPL
who: Itamar Rabenstein at Mellanox
Voltaire for CM related features
- Linux coding style
who: everyone
- kDAPL API changes for Linux coding style
who:
Quoting r. Roland Dreier [EMAIL PROTECTED]:
Subject: Re: ANNOUNCE: First usable version of userspace verbs
I also fixed a few warnings and other small glitches, and now the
pingpong test works for me from both 32- and 64-bit userspace.
I still see these:
src/cmd.c: In function
Quoting r. Roland Dreier [EMAIL PROTECTED]:
Subject: ANNOUNCE: First usable version of userspace verbs
To actually try things out, you can use the ibv_pingpong program
shipped as part of the libibverbs package. For example, one one
system start the server side
$ ibv_pingpong
and
Thanks, looks like I had the same bug in create CQ as well...
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit
Michael Shall uverbs and umad share the same major?
Yes, they should. umad uses minors 0 ... 127 and uverbs uses minors
128 ... 160. See http://www.lanana.org/docs/device-list/devices-2.6+.txt
- R.
___
openib-general mailing list
Hmm, I can't reproduce this. It looks like ib_uverbs_mmap() is
following a bad ib_dev-mmap() function pointer, but I can't see how
that could happen.
- R.
___
openib-general mailing list
openib-general@openib.org
Michael Hi! I'm running on x86_64 64 bit user and kernel space.
Michael the pingpong test does not seem to work with size other
Michael than the default 4096 (I am running with external
Michael loopback):
Looks like you had a size mismatch between the two sides. In which
case
Libor Michalek wrote:
There's a problem with REJ response to REQ. The REJ handler
uses cm_acquire_id() to find the cm_id of the REQ, but it uses
rej_msg-local_comm_id to perform the lookup. In the REQ case the
cm_id does not have a remote_id with which to match the REJ.
My thinking on this was
Roland I guess this patch can't hurt but can the mm really go
Roland away? The only time we will call ib_umem_get() is during
Roland a write system call (which requires an open file,
Roland obviously). Can current-mm go away before all files are
Roland closed?
I didn't
Michael Interestingly, if I rebuild libmthca with -O3 compiler
Michael flag, the pingpong program does not make progress.
Michael Building libibverbs or the test itself with -O3 has no
Michael such effect.
I can't reproduce this on either i386 or x86-64 (Intel Nocona system).
list_for_each_entry() should be list_for_each_entry_safe()
in ipoib_mcast_restart_task(). Here is the patch. Please review it.
Signed-off-by: Shirley Ma [EMAIL PROTECTED]
diff -urpN infiniband/ulp/ipoib/ipoib_multicast.c
infiniband-mcast/ulp/ipoib/ipoib_multicast.c
---
This API seems overly complex and at the same time too inflexible to
me. However, rather than getting bogged down nitpicking about APIs, I
think we have to take a few steps back.
I am very open to suggestions.
First, let's understand the problem we're trying to solve. Who are
the
On Mon, Feb 28, 2005 at 09:23:25AM -0800, Sean Hefty wrote:
Libor Michalek wrote:
There's a problem with REJ response to REQ. The REJ handler
uses cm_acquire_id() to find the cm_id of the REQ, but it uses
rej_msg-local_comm_id to perform the lookup. In the REQ case the
cm_id does not
Libor Michalek wrote:
My thinking on this was that the for the sender of the REQ, the remote
ID would be set to 0. The sender of the REJ would set the local ID to
0, since it wouldn't have one (unless it had previously sent an MRA).
Does this make sense, or am I missing something else here?
Thanks, good catch.
+ list_for_each_entry_safe(mcast, remove_list, list) {
should really be
+ list_for_each_entry_safe(mcast, tmcast, remove_list, list) {
though, right?
When you send a patch with a title like mcast restart causes kernel
oops can you make it clearer if you
Roland First, let's understand the problem we're trying to solve.
Roland Who are the consumers of this address translation service?
shaharf Any ULPs at user kernel, and also some
shaharf applications.
I think this is too general an answer. We should be designing based
on
On Mon, Feb 28, 2005 at 10:29:19AM -0800, Roland Dreier wrote:
Roland First, let's understand the problem we're trying to solve.
Roland Who are the consumers of this address translation service?
shaharf Any ULPs at user kernel, and also some
shaharf applications.
I think
-Original Message-
From: [EMAIL PROTECTED] [mailto:openib-general-
[EMAIL PROTECTED] On Behalf Of Roland Dreier
Sent: Monday, February 28, 2005 7:13 PM
To: shaharf
Cc: openib-general@openib.org
Subject: Re: [openib-general] IB Address Translation service
This API seems overly
Paul Would this proposed address translation layer interface
Paul provide a sufficient subset of IPoIB functionality that
Paul allowed an SDP implementation to exist without a larger,
Paul full-featured IPoIB implementation?
I doubt it. Right now the IPoIB driver has very little
On Mon, Feb 28, 2005 at 07:31:47PM -, Paul Baxter wrote:
Roland First, let's understand the problem we're trying to solve.
Roland Who are the consumers of this address translation service?
shaharf Any ULPs at user kernel, and also some
shaharf applications.
I think
Quoting r. Roland Dreier [EMAIL PROTECTED]:
Subject: Re: [PATCH][uverbs] use get_task_mm
Roland I guess this patch can't hurt but can the mm really go
Roland away? The only time we will call ib_umem_get() is during
Roland a write system call (which requires an open file,
Quoting r. Roland Dreier [EMAIL PROTECTED]:
Subject: Re: ANNOUNCE: First usable version of userspace verbs
Michael Interestingly, if I rebuild libmthca with -O3 compiler
Michael flag, the pingpong program does not make progress.
Michael Building libibverbs or the test itself with
Below are my meeting notes:
Porting DAPL to OpenIB
==
Meeting Notes
Date: 2/28/2005
Time: 11:30 AM EST
Attendees:
James Lentini [EMAIL PROTECTED]
Dror Goldenberg [EMAIL PROTECTED]
Itamar Rabenstein [EMAIL PROTECTED]
Arkady Kanevsky [EMAIL PROTECTED]
Hal
It is my understanding that the current MTHCA driver does not support
InfiniBand memory windows or memory registration using virtual
addresses.
Is this information correct? If so, when will these features be
supported?
Thanks,
-james
James Lentiniemail: [EMAIL PROTECTED]
As promised during the call today, here is a link to the patches Tom
Duffy sent:
http://sourceforge.net/mailarchive/forum.php?thread_id=6549863forum_id=13070
On Mon, 28 Feb 2005, James Lentini wrote:
Below are my meeting notes:
Porting DAPL to OpenIB
==
Meeting Notes
Date:
On Sun, Feb 27, 2005 at 12:44:41PM +0200, Michael S. Tsirkin wrote:
Quoting r. Libor Michalek [EMAIL PROTECTED]:
On Thu, Feb 24, 2005 at 11:49:28PM +0200, Michael S. Tsirkin wrote:
OK, now what about things like these:
if (0 result) {
may I change them all to
On Mon, Feb 28, 2005, Libor Michalek [EMAIL PROTECTED] wrote:
@@ -1302,7 +1301,7 @@ static int _sdp_inet_shutdown(struct soc
* 1 - send shutdown
* 2 - send/recv shutdown.
*/
- if (0 flag || 2 flag)
+ if (flag 0 || flag 2)
-Original Message-
From: [EMAIL PROTECTED] [mailto:openib-general-
[EMAIL PROTECTED] On Behalf Of Libor Michalek
Sent: Monday, February 28, 2005 8:55 PM
To: Roland Dreier
Cc: openib-general@openib.org
Subject: Re: [openib-general] IB Address Translation service
SDP does
Signed-off-by: Tom Duffy [EMAIL PROTECTED]
Index: drivers/infiniband/ulp/sdp/sdp_conn.h
===
--- drivers/infiniband/ulp/sdp/sdp_conn.h (revision 1929)
+++ drivers/infiniband/ulp/sdp/sdp_conn.h (working copy)
@@ -534,7
Signed-off-by: Tom Duffy [EMAIL PROTECTED]
Index: drivers/infiniband/ulp/sdp/sdp_event.c
===
--- drivers/infiniband/ulp/sdp/sdp_event.c (revision 1929)
+++ drivers/infiniband/ulp/sdp/sdp_event.c (working copy)
@@ -198,9
Signed-off-by: Tom Duffy [EMAIL PROTECTED]
Index: drivers/infiniband/ulp/sdp/sdp_inet.c
===
--- drivers/infiniband/ulp/sdp/sdp_inet.c (revision 1929)
+++ drivers/infiniband/ulp/sdp/sdp_inet.c (working copy)
@@ -39,18
Signed-off-by: Tom Duffy [EMAIL PROTECTED]
Index: drivers/infiniband/ulp/sdp/sdp_proc.c
===
--- drivers/infiniband/ulp/sdp/sdp_proc.c (revision 1929)
+++ drivers/infiniband/ulp/sdp/sdp_proc.c (working copy)
@@ -34,22
Signed-off-by: Tom Duffy [EMAIL PROTECTED]
Index: drivers/infiniband/ulp/sdp/sdp_proto.h
===
--- drivers/infiniband/ulp/sdp/sdp_proto.h (revision 1929)
+++ drivers/infiniband/ulp/sdp/sdp_proto.h (working copy)
@@ -476,7
Signed-off-by: Tom Duffy [EMAIL PROTECTED]
Index: drivers/infiniband/ulp/sdp/sdp_rcvd.c
===
--- drivers/infiniband/ulp/sdp/sdp_rcvd.c (revision 1929)
+++ drivers/infiniband/ulp/sdp/sdp_rcvd.c (working copy)
@@ -38,7 +38,7
Signed-off-by: Tom Duffy [EMAIL PROTECTED]
Index: drivers/infiniband/ulp/sdp/sdp_read.c
===
--- drivers/infiniband/ulp/sdp/sdp_read.c (revision 1929)
+++ drivers/infiniband/ulp/sdp/sdp_read.c (working copy)
@@ -39,9 +39,9
Signed-off-by: Tom Duffy [EMAIL PROTECTED]
Index: drivers/infiniband/ulp/sdp/sdp_send.c
===
--- drivers/infiniband/ulp/sdp/sdp_send.c (revision 1929)
+++ drivers/infiniband/ulp/sdp/sdp_send.c (working copy)
@@ -39,9 +39,9
Hi Ron,
On Mon, 2005-02-28 at 17:06, Ronald G. Minnich wrote:
If ibnetdiscover can do stuff like this:
hcaguids=0xc074660801c90200
Hca 2 H-0002c901086674c0 # MT23108 InfiniHost Mellanox
Technologies
[1] S-0002c90112c08b40[2] # lid 0 lmc 0
etc. etc.
i.e.,
On Mon, 2005-02-28 at 17:11, Yaron Haviv wrote:
Ron, I believe netdiscover uses direct route MADs
So does OpenSM.
So it can work also when the fabric is not fully initialized
OpenSM is responsible for initializing the fabric (and needs to work
with an uninitialized fabric).
-- Hal
Yaron
This is slightly updated after revision 1930 was checked in.
Signed-off-by: Tom Duffy [EMAIL PROTECTED]
Index: drivers/infiniband/ulp/sdp/sdp_recv.c
===
--- drivers/infiniband/ulp/sdp/sdp_recv.c (revision 1930)
+++
On Tue, 1 Mar 2005, Yaron Haviv wrote:
Ron, I believe netdiscover uses direct route MADs
So it can work also when the fabric is not fully initialized
ok, that makes sense.
So this brings up another question. ibnetdiscover is plenty fast, and
opensm is plenty slow. What kind of messaging
On Mon, 28 Feb 2005, Hal Rosenstock wrote:
OpenSM is responsible for initializing the fabric (and needs to work
with an uninitialized fabric).
??
You mean, if you have an initialized fabric, opensm can't work?
Is there useful material on the web that explains this? I keep looking for
On Mon, 28 Feb 2005, Hal Rosenstock wrote:
In what state is the subnet stuck in ?
how should I tell?
Was this a dead switch or did it have redundant power supplies ?
redundant; it was not dead.
ron
___
openib-general mailing list
Ronald So this brings up another question. ibnetdiscover is
Ronald plenty fast, and opensm is plenty slow. What kind of
Ronald messaging could I do once i have a network all worked out
Ronald via ibnetdiscover?
Unfortunately, even if you know the topology of your network, the only
On Mon, 2005-02-28 at 17:46, Ronald G. Minnich wrote:
On Mon, 28 Feb 2005, Hal Rosenstock wrote:
In what state is the subnet stuck in ?
how should I tell?
opensm logs. Also, I would be curious to see what ibstat showed about
all endport LIDs in the network. Are all the ports active that
On Mon, 2005-02-28 at 17:46, Ronald G. Minnich wrote:
On Mon, 28 Feb 2005, Hal Rosenstock wrote:
OpenSM is responsible for initializing the fabric (and needs to work
with an uninitialized fabric).
??
You mean, if you have an initialized fabric, opensm can't work?
No, I mean that
On Mon, 2005-02-28 at 17:40, Ronald G. Minnich wrote:
On Mon, 28 Feb 2005, Hal Rosenstock wrote:
What is the definition of opensm won't work at all ? I am presuming
that somehow the ports are not brought to active. Is that it or
something else ?
[1109361464:000221781][411FF970] -
On Mon, 28 Feb 2005, Hal Rosenstock wrote:
The opensm log preferably in verbose (-V) mode.
It's a long log :-)
Here is the point at which it goes to pieces.
[1109360115:000609200][40BFF970] - osm_pkey_rcv_process: Got
GetResp(PKey) block:1 port_num 1 with GUID = 0x2c90108d192e0 for parent
On Mon, 28 Feb 2005, Hal Rosenstock wrote:
opensm logs. Also, I would be curious to see what ibstat showed about
all endport LIDs in the network. Are all the ports active that should be
(plugged into subnet) ?
They all look like this:
CA 'mthca0':
CA type: MT23108
Number
On Mon, 28 Feb 2005, Hal Rosenstock wrote:
Also, wasn't that the same failure as a while ago when one of those 96
port switches kept forwarding but didn't terminate MADs ? (Yes, I know
you recycled everything which would seem to be inconsistent with this).
yeah, something has gone south and
On Mon, Feb 28, 2005 at 11:34:06PM +0200, Michael S. Tsirkin wrote:
Quoting r. Libor Michalek [EMAIL PROTECTED]:
Subject: Re: [PATCH] sdp conditional code cleanup
On Sun, Feb 27, 2005 at 12:44:41PM +0200, Michael S. Tsirkin wrote:
Quoting r. Libor Michalek [EMAIL PROTECTED]:
On Thu,
On Mon, Feb 28, 2005 at 02:02:53PM -0800, Tom Duffy wrote:
Signed-off-by: Tom Duffy [EMAIL PROTECTED]
Index: drivers/infiniband/ulp/sdp/sdp_queue.h
===
--- drivers/infiniband/ulp/sdp/sdp_queue.h(revision 1929)
+++
ok, here you go. THis is the first one that appears to fail.
YOu can probably guess why :-)
[1109632561:000646260][411FF970] - __osm_sm_mad_ctrl_process_get_resp: [
[1109632561:000646268][411FF970] - __osm_sm_mad_ctrl_update_wire_stats: [
[1109632561:000646277][411FF970] -
On Mon, 2005-02-28 at 15:24 -0800, Libor Michalek wrote:
-#define sdp_desc_q_size(x) __sdp_desc_q_size(x)
-#define sdp_desc_q_member(x) __sdp_desc_q_member(x)
+#define sdp_desc_q_size(x) sdp_desc_q_size(x)
+#define sdp_desc_q_member(x) sdp_desc_q_member(x)
In this case wouldn't
On Mon, Feb 28, 2005 at 03:37:55PM -0800, Tom Duffy wrote:
On Mon, 2005-02-28 at 21:47 +0200, Yaron Haviv wrote:
And as you mentioned there is value to have the same API for different
resolution mechanisms, the SDP code can be altered in future to ride
over the proposed API, so it can be
Sean,
Is it ever allowed to call ib_destroy_cm_id() from a CM callback?
For some reason I thought that this was OK from only the IDLE callback,
but if I destroy from IDLE I get a hang on cm_id_priv-lock, I believe.
Should the normal mode of operation in the case be to return an error
from IDLE
Hi Greg,
Here's a device ID for the new HCA that Mellanox just introduced.
Please queue this up for 2.6.12.
Thanks,
Roland
Add PCI device ID for new Mellanox Sinai InfiniHost III Lx HCA.
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
--- linux-svn.orig/include/linux/pci_ids.h
-Original Message-
From: Tom Duffy [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 01, 2005 1:38 AM
To: Yaron Haviv
Cc: Paul Baxter; openib-general@openib.org
Subject: RE: [openib-general] IB Address Translation service
On Mon, 2005-02-28 at 21:47 +0200, Yaron Haviv wrote:
And as
-Original Message-
From: Libor Michalek [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 01, 2005 2:04 AM
To: Yaron Haviv
Cc: Paul Baxter; openib-general@openib.org
Subject: Re: [openib-general] IB Address Translation service
On Mon, Feb 28, 2005 at 09:55:50PM +0200, Yaron Haviv
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael Krause
Sent: Tuesday, March 01, 2005 2:07 AM
To: openib-general@openib.org
Subject: RE: [openib-general] IB Address Translation service
At 11:47 AM 2/28/2005, Yaron Haviv wrote:
It
Roland Memory windows are not implemented for mthca. It wouldn't be a lot of
Roland work for someone with access to Mellanox documentation to implement
Roland them, but they're not particularly useful due to their performance
characteristics.
By performance characteristics do you mean the
Title: RE: [openib-general] Question
Hal wrote:
So this looks like a workaround for a bug. Not sure what any of the other symptoms
are but I'm real curious now. Can someone comment more on this ?
The ERR 3610 is really just a warning. It is caused by the Anafa1 chip responding with a
Yaron Haviv [EMAIL PROTECTED] writes:
-Original Message-
From: [EMAIL PROTECTED] [mailto:openib-general-
[EMAIL PROTECTED] On Behalf Of Roland Dreier
Sent: Monday, February 28, 2005 7:13 PM
To: shaharf
Cc: openib-general@openib.org
Subject: Re: [openib-general] IB Address
66 matches
Mail list logo
