Eric Barton wrote:
> I've had a report of rdma_connect() failing with a callback event type of
> RDMA_CM_EVENT_UNREACHABLE and status -ETIMEDOUT although the peer node was
> up and running at the time.
>
> It seems this can be reproduced as follows...
>
> 1. Establish a connection between nodes A
>I guess the function to read from the iterator does need to do the
>copying out. I wonder if it's worth trying to get really tricky and
>do the unpacking in the same step?
Internally, I copy a split attribute into an intermediate buffer that is
allocated as part of the cursor / iterator, then un
I've had a report of rdma_connect() failing with a callback event type of
RDMA_CM_EVENT_UNREACHABLE and status -ETIMEDOUT although the peer node was
up and running at the time.
It seems this can be reproduced as follows...
1. Establish a connection between nodes A and B
2. Reboot node A
3. Star
Or Gerlitz wrote:
> + not 2.6.19 material to allow more testing
I meant to say, it not 2.6.18 but rather 2.6.19 material to allow for
more testing.
Or.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/ope
Sean Hefty wrote:
> Just to make sure, here's my summary of the discussions so far. Anyone who
> disagrees can jump in.
> There was discussion on this being 2.6.18 material. The consensus is to let
> it
> get wider testing in svn first. The fix / feature isn't critical enough to
> push
> upst
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: hotplug support in mthca
>
> Michael> How about fixing it by blocking remove_one in uverbs
> Michael> until all contexts are closed and device refcount drops
> Michael> to 0?
>
> That seems kind of horrible, because there's
Sean> Note that an SA attribute can span across two different
Sean> MADs, so some sort of intermediate buffer is needed in
Sean> certain cases.
Umm... good point.
I guess the function to read from the iterator does need to do the
copying out. I wonder if it's worth trying to get real
>I think I would rather see this called an "iterator". The word "cursor"
>tends to mean that blinky thing on your screen these days.
That's easy enough to change.
> > +int ib_sa_get_next_attr(struct ib_sa_attr_cursor *cursor, void *attr);
>
>How does the consumer know how big the buffer has to b
This is the sort of thing that needs to be clearly documented
for the library. We currently don't have a useable set of
documents (some collection of reading the code and the IB spec.).
On Tue, 2006-08-01 at 16:50 -0700, Roland Dreier wrote:
> I guess this is pretty uncontroversial, so I'll check
I guess this is pretty uncontroversial, so I'll check this in
tomorrow. But one last call for comments: in particular, does anyone
object to libibverbs being fork-unsafe by default unless ibv_fork_init
is called?
> +/**
> + * ibv_fork_init - Prepare data structures so that fork() may be used
>
Michael> How about fixing it by blocking remove_one in uverbs
Michael> until all contexts are closed and device refcount drops
Michael> to 0?
That seems kind of horrible, because there's no guarantee that all the
contexts will ever be freed.
I think the real answer is to revoke all th
> Hmm. Since we are lockless, could ipoib_start_xmit run even after we call
> netif_stop_queue? Since interrupts are disabled anyway, can we just just
> take
> tx_lock? How does the following look?
ipoib_start_xmit() can run after netif_stop_queue() but it will return
immediately (before to
>Using the iwarp branch of r8688, with linux-2.6.17.7 on up to date
>x86_64 FC4 SMP with Ammasso cards, I can hang the client side during
>RDMA CM connection setup.
Do you know or have any way to check if this hang also occurs with IB devices?
- Sean
_
Convert local SA to use the new SA cursor routines for walking a
list of attributes in an RMPP response returned by the SA. This
replaces a local SA specific implementation.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
Index: core/local_sa.c
==
The following patch adds a generic interface to send MADs to the SA.
The primary motivation of adding these calls is to expand the SA query
interface to include RMPP responses for users wanting more than a
single attribute returned from a query (e.g. multipath record queries).
The design for retri
On Tue, Aug 01, 2006 at 05:39:49PM -0400, Makia Minich wrote:
> So, after flailing about with my IPOIB issue on the XT3, I decided that
> perhaps a firmware upgrade (from 3.3.3 to 3.4.0) might be in order. Prior
> to the upgrade, I was able to bring the entire stack online and see the
> infiniband
So, after flailing about with my IPOIB issue on the XT3, I decided that
perhaps a firmware upgrade (from 3.3.3 to 3.4.0) might be in order. Prior
to the upgrade, I was able to bring the entire stack online and see the
infiniband network (provided I refrained from ifconfig'ing the ipoib
interfaces)
Using the iwarp branch of r8688, with linux-2.6.17.7 on up to date
x86_64 FC4 SMP with Ammasso cards, I can hang the client side during
RDMA CM connection setup.
The scenario is:
start server side process on some other node
start client process
have server die after RDMA_CM_EVENT_CONN
So, let's suppose I build ibverbs, libecha/libmthca, and dapl from
subversion trunk.. what should my /etc/dat.conf file look like so things
actually work?
Right now I have:
OpenIB-cma-ip u1.2 nonthreadsafe default /usr/local/lib/libdaplcma.so
mv_dapl.1.2 "10.40.4.56 0" ""
OpenIB-cma-ip u1.2 nonth
> I am testing APM with kernel module which directly interfaces with
>ib_verbs.ko and ib_cm.ko.
>Yes, I do receive IB_MIG_MIGRATED event, but the QP's mig_state is not
>actually changed to MIGRATED. So I had to do this from my module.
The ib_cm does not perform QP state transitions. That is left
I am testing APM with kernel module which directly interfaces with
ib_verbs.ko and ib_cm.ko.
Yes, I do receive IB_MIG_MIGRATED event, but the QP's mig_state is not
actually changed to MIGRATED. So I had to do this from my module.
It could be a bug with ib_cm code, which may not be transitionin
opensm: management/Makefile: osm and diags build order reversal
osm and diags build order reversal in management/Makefile. It is needed
since saquery diag tool uses osm libraries.
Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]>
---
Makefile |2 +-
1 files changed, 1 insertions(+), 1 del
On Tuesday 01 August 2006 17:22, Michael S. Tsirkin wrote:
> Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> > Subject: Re: hotplug support in mthca
> >
> > Michael> Roland, what happends today if an mthca device is removed
> > Michael> while a userspace applcation still keeps a reference t
Mohit hi,You are correct that the iser initiator code is now based on openIB stack and follows the open-iscsi APIs instead of the datamover API. If you dig in the iser-initiator history, you'll find that it too was originaly based on datamover API on top of kDAPL.
The datamover API was a nice conce
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: hotplug support in mthca
>
> Michael> Roland, what happends today if an mthca device is removed
> Michael> while a userspace applcation still keeps a reference to
> Michael> it?
>
> Something bad.
How about fixing it by blo
> You forgot to include buf.c in the patch.
Oops, forgot to do svn add before generating the diff. Updated diff below:
Index: libibverbs/include/infiniband/driver.h
===
--- libibverbs/include/infiniband/driver.h (revision 8793
Michael> Roland, what happends today if an mthca device is removed
Michael> while a userspace applcation still keeps a reference to
Michael> it?
Something bad.
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.or
Hi all,
I was looking at iSER initiator and target code. I
noticed that iSER target code available is based on Datamover architecture but
the initiator code is not based on Datamover Architecture. Why the iSER
initiator code is not based on Datamover Architecture? What are the future plan
On Mon, Jul 31, 2006 at 11:52:18AM -0700, Roland Dreier wrote:
> Here's an initial cut (based on Gleb Natapov's work) at using
> madvise(MADV_DONTFORK) to support fork() from libibverbs. The main
> changes from Gleb's earlier work are:
>
> - I added code to handle doorbell pages in libmthca. As
On Tuesday 01 August 2006 05:19, Venkatesh Babu wrote:
> Configuration2: Node1 and Node 2 conneected through two switches for
> each port.
> Node1, port1 -> switch1 -> Node2, port1
> Node1, port2 -> switch2 -> Node2, port2
>
> Node 1:
> 1. Call ib_cm_listen() to wait for connection requests
> 2.
On Tue, 2006-08-01 at 07:04, Sven-Arne Reinemo wrote:
> Anno Domini 22-07-2006 20:25, Eitan Zahavi wrote:
> > Hi Sven,
> >
> >>> Currently there is no way to scale simulation time to real time.
> >>> The main reason is that the time scale is mixed: * OpenSM
> >>> calculation time is about the sam
On Mon, Jul 31, 2006 at 11:28:46AM -0700, Greg Lindahl wrote:
> On Mon, Jul 31, 2006 at 11:18:16AM -0700, Roland Dreier wrote:
>
> > My gut reaction is negative. The whole idea of "verbs" is a bit of
> > technical jargon that makes no sense unless you've lived in the RDMA
> > world for a while,
>
On Mon, Jul 31, 2006 at 10:45:39AM -0700, Roland Dreier wrote:
> > That's much better than rdma_, but do you really think the Linux folks
> > are going to be happy about OpenFabrics calls with a prefix that
> > doesn't look anything like "Open Fabrics"?
>
> I don't think Linux folks care about
Anno Domini 22-07-2006 20:25, Eitan Zahavi wrote:
> Hi Sven,
>
>>> Currently there is no way to scale simulation time to real time.
>>> The main reason is that the time scale is mixed: * OpenSM
>>> calculation time is about the same (if you run the simulator on
>>> remote node)
>> So this means t
Hi Hal
This was reported to me by Ishai R.
Consider function umad_recv line 810:
if ((n = read(port->dev_fd, umad, sizeof *mad + *length)) <=
sizeof *mad + *length) {
DEBUG("mad received by agent %d length %d", mad->agent_id, n);
*length = n
Roland, what happends today if an mthca device is removed
while a userspace applcation still keeps a reference to it?
I understand uverbs remove_one will get called, but I don't see
what prevents it from exiting while userspace still has open
resources.
--
MST
__
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: Fwd: issues in ipoib
>
> > 1. pkey cache issues
> > http://thread.gmane.org/gmane.linux.drivers.openib/26684/focus=26692
>
> I thought we fixed the P_Key cache issues by correcting the oversight
> in retrying the P_Key query?
>
> >
37 matches
Mail list logo
