Fix a crasher bug in IPoIB CM: once QP is in RTR, an RX completion (and even an
asynchronous error) might be observed on this QP, so we have to initialize all
RX fields beforehand.
This fixes bug https://bugs.openfabrics.org/show_bug.cgi?id=662
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED
Quoting Jeremy Brown [EMAIL PROTECTED]:
Subject: Re: Issue with IPoIB-CM being enabled at boot
I apologize for replying to myself, but I just set up two em64t systems
with Mellanox HCAs, Fedora 4, and a fresh build and installation of OFED
1.2, and the IPoIB interfaces came up in datagram
Quoting Doug Ledford [EMAIL PROTECTED]:
Subject: Re: RFC OFED-1.3 installation
On Tue, 2007-07-17 at 19:27 +0300, Michael S. Tsirkin wrote:
Quoting Doug Ledford [EMAIL PROTECTED]:
Subject: Re: RFC OFED-1.3 installation
On Tue, 2007-07-17 at 18:25 +0300, Michael S. Tsirkin wrote
Quoting Doug Ledford [EMAIL PROTECTED]:
Subject: Re: RFC OFED-1.3 installation
On Tue, 2007-07-17 at 19:45 +0300, Michael S. Tsirkin wrote:
Quoting Doug Ledford [EMAIL PROTECTED]:
Subject: Re: RFC OFED-1.3 installation
On Tue, 2007-07-17 at 19:27 +0300, Michael S. Tsirkin wrote
There are lots of things that we as a distributor have to care about
that upstream generally does not. The spec file and patches are how we
solve our customer's problems. They are what make a stable
distribution, as opposed to a bleeding edge, must always update to
latest upstream version
So you need to be able to
tell the difference between a customer running libibverbs-1.0.4 from
OFED-1.3-beta1 and libibverbs-1.0.4 from OFED-1.3 final.
I don't really think we want customers to run beta code, or intend to support
such configurations.
--
MST
Quoting Arthur Jones [EMAIL PROTECTED]:
Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
hi michael, ...
On Tue, Jun 12, 2007 at 11:41:08AM +0300, Michael S. Tsirkin wrote:
For whom it may concern,
I have created an ofed git tree updated with kernel bits from 2.6.22
Quoting Arthur Jones [EMAIL PROTECTED]:
Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
hi michael, ...
On Tue, Jul 24, 2007 at 06:03:41AM +0300, Michael S. Tsirkin wrote:
[...]
But I also see a serious problem with addressing: basically
git tracks content
Quoting Arthur Jones [EMAIL PROTECTED]:
Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
hi michael, ...
On Tue, Jul 24, 2007 at 06:32:28PM +0300, Michael S. Tsirkin wrote:
[...]
For example, git pull can only merge one branch at a time.
how
Quoting Arthur Jones [EMAIL PROTECTED]:
Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
hi michael, ...
On Tue, Jul 24, 2007 at 06:09:09PM +0300, Michael S. Tsirkin wrote:
Quoting Arthur Jones [EMAIL PROTECTED]:
Subject: Re: [ofa-general] ANNOUNCE ofed
Because you only have your driver to maintain.
no, i have to maintain quite a few of the
ofed backport branches as well for our release.
if i started getting pull requests from people
with changes to 15 backport branches in one go,
i'd probably want to script it...
Yea. Happens all the
i'd _really_ like to see a list of the advantages of
patches over branches. it's hard for me to know if
i'm just missing something if the case is not laid out...
Here's a short list off the top of my head
- A single git pull merges any number of backport changes
- A single git reset
Quoting Sean Hefty [EMAIL PROTECTED]:
Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
Here's a short list off the top of my head
- A single git pull merges any number of backport changes
- A single git reset ORIG_HEAD recovers from a conflicting merge
- A single
- A single git reset ORIG_HEAD recovers from a conflicting merge
handling conflicts is a big part of a maintainer's job!
Because you are a driver maintainer.
That's what's different here from regular merge.
Please understand: we have upstream code and we have changes against it.
Upstream
Quoting Stefan Roscher [EMAIL PROTECTED]:
Subject: [PATCH ofed-1.2-rc3 2/4] ehca: backport for rhel-4.5 - mmap
functonality
Signed-off-by: Stefan Roscher [EMAIL PROTECTED]
---
backport_ehca_2_rhel45_umap.patch | 850
++
1 files changed, 850
Erez, add_open_iscsi_h currently does:
-#include scsi/iscsi_if.h
+#include iscsi_if.h
why is ths bit needed?
--
MST
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Quoting Erez Zilber [EMAIL PROTECTED]:
Subject: Re: add_open_iscsi_h.patch
Michael S. Tsirkin wrote:
Quoting Erez Zilber [EMAIL PROTECTED]:
Subject: Re: add_open_iscsi_h.patch
Michael S. Tsirkin wrote:
Quoting Erez Zilber [EMAIL PROTECTED]:
Subject: Re
also, if the upstream
changes touch code that conflicts with a backport
patch, you get to fix the problem as it happens
That's exactly the thing that I do not want to do.
you don't want to know about a problem a patch
until days or weeks later when the auto build
keeps failing
Quoting Hoang-Nam Nguyen [EMAIL PROTECTED]:
Subject: Re: [PATCH ofed-1.2-rc3 2/4] ehca: backport for rhel-4.5 - mmap
functonality
Hi Michael,
Below is the version without conflicts. And it should compile.
Seems to apply fine. I pushed it out. Vlad, can you take it pls?
As soon as the
object
as a value.
Please comment.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
---
diff --git a/include/infiniband/verbs.h b/include/infiniband/verbs.h
index acc1b82..503f201 100644
--- a/include/infiniband/verbs.h
+++ b/include/infiniband/verbs.h
@@ -370,6 +370,11 @@ struct ibv_ah_attr
On Sun, Jul 29, 2007 at 05:04:31PM +0300, Michael S. Tsirkin wrote:
Hello!
Here is an API proposal for support of the SRC
(scalable reliable connected) protocol extension in libibverbs.
This adds APIs to:
- manage SRC domains
- share SRC domains between processes,
by means
Some code examples:
/* create a domain and share it: */
struct ibv_src_domain * d = ibv_get_new_src_domain(ctx);
int fd = open(path, O_CREAT | O_RDWR, mode);
ibv_share_src_domain(d, fd);
/* get a reference to a shared domain: */
int fd =
More code examples:
Create an SRC QP, part of SRC domain:
attr.qp_type = IBV_QPT_SRC;
attr.src_domain = d;
qp = ibv_create_qp(pd, attr);
Given remote SRQ number, send data to this SRQ over an SRC QP:
wr.src_remote_srq_num = src_remote_srq_num;
Quoting Gleb Natapov [EMAIL PROTECTED]:
Subject: Re: [ofa-general] RFC: SRC API
On Mon, Jul 30, 2007 at 12:16:39PM +0300, Michael S. Tsirkin wrote:
More code examples:
Create an SRC QP, part of SRC domain:
attr.qp_type = IBV_QPT_SRC;
attr.src_domain = d;
qp
It seems what you are missing is what SRC is, not how to use the API.
So tell us.
This calls for a separate document. From feedback from Sonoma I really assumed
people have it figured out.
Let's open a separate thread, and there I will try writing up
what SRC is from the protocol point of
Here's some background on what SRC is. This is basically slide 6 in Dror's
talk, for those that missed the talk.
* * *
SRC is an extension supported by recent Mellanox hardware
which is geared toward reducing the number of QPs
required for all-to-all communication on systems
with a high
The following patches add kfifo to ibcore (for SLES9 RH4). kfifo is taken
from upstream code.
Thanks, applied to 1.2.c and ofed_kernel.
Vlad already took 1.2.c, and will I guess take ofed_kernel
after it passes his checks.
--
MST
___
ewg mailing
Quoting Gleb Natapov [EMAIL PROTECTED]:
Subject: Re: Scalable reliable connection
On Mon, Jul 30, 2007 at 03:50:54PM +0300, Michael S. Tsirkin wrote:
With SRC:
O(N ^ 2 * J)
This is achived by using a single send queue (per job, out of O(N * J)
jobs)
to send
Quoting Tang, Changqing [EMAIL PROTECTED]:
Subject: RE: Scalable reliable connection
A send queue can only serve max J jobs within a node. Is it possible to
make a single send queue to serve all jobs on all nodes ?
How do you propose to do this?
--
MST
Quoting Steve Wise [EMAIL PROTECTED]:
Subject: patches for 1.2.c
Guys,
I have 2 more patches to go in ofed_1_2/ofed_1_2_c.
Is there some grand scheme to the naming of kernel_patches/fixes/* for
1.2.c? I noticed a slew of new files for the post-2.6.22 fixes, and
wondered if there is
Quoting Erez Zilber [EMAIL PROTECTED]:
Subject: [PATCH 0/2] IB/iser: move open-iscsi crypto functions to
kernel_addons
The following patches move open-iscsi crypto functions from kernel_patches to
kernel_addons. By doing so, we also solve a bug in iscsi tx hash that caused
an oops when
Quoting Roland Dreier [EMAIL PROTECTED]:
Subject: Re: [ofa-general] Re: OFED 1.2.c-9 is available
Why under drivers/net rather than drivers/infiniband like all the
other drivers ? Does this really need special casing (in libibumad) ?
Tziporet is incorrect. There's nothing from the
Quoting Steve Wise [EMAIL PROTECTED]:
Subject: Re: [ofa-general] Re: ofa_1_2_c_kernel 20070802-0201 daily build
status
Also,
Is something broken in the ofed_1_2 branch? I cannot even build against
the local kernel on the ofa server using the ~vlad/ofed_1_2/linux-2.6
repository.
Looke here:
/home/vlad/scripts/ofed_1_2
Quoting Steve Wise [EMAIL PROTECTED]:
Subject: Re: [ewg] Re: [ofa-general] Re: ofa_1_2_c_kernel 20070802-0201 daily
build status
I'm havin' a bad day.
Can you all help me?
My normal process is to use the build_ofa_kernel.sh script from the
ofabuild
Vlad?
Quoting Erez Zilber [EMAIL PROTECTED]:
Subject: Re: [PATCH 0/2] IB/iser: move open-iscsi crypto functions
to?kernel_addons
Michael S. Tsirkin wrote:
Quoting Erez Zilber [EMAIL PROTECTED]:
Subject: [PATCH 0/2] IB/iser: move open-iscsi crypto functions to
kernel_addons
The following
. tmpfile can be used).
- I envision implementing this sharing mechanism in kernel by means
of a per-device tree, with inode as a key and domain object
as a value.
Please comment.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
diff --git a/SRC.txt b/SRC.txt
new file mode 100644
index
Quoting Hoang-Nam Nguyen [EMAIL PROTECTED]:
Subject: Re: ofa_1_2_c_kernel 20070802-0201 daily build status
Hello Michael and Vladimir!
ehca backports for kernel.org kernels seem to be broken.
1. Does anyone care enough to fix them? If not we'll disable
ehca in build for these
Let's not do it this way.
I think the right thing is to implement kmem_cache_zalloc
by means of kmem_cache_allocand memset in kernel_addons.
Quoting Hoang-Nam Nguyen [EMAIL PROTECTED]:
Subject: [PATCH ofed-1.2.c] ehca: backport kmem_cache_zalloc() for
2.6.10/sles10/sles10_sp1
Hello Michael
Only of the job among j2, j3, j4 on remote node n need to create a
receiving qp2 for j1, right ?
Correct. A single QP can be used to send data to any SRQ that shares the
same domain.
--
MST
___
ewg mailing list
ewg@lists.openfabrics.org
Quoting Tang, Changqing [EMAIL PROTECTED]:
Subject: RE: RFCv2: SRC API
OK, I was wrong before, here is my question.
if remote node n has j2, j3, and j4, and j2 is the job to
create qp2
and make connection with qp1 in j1.
if j2 is done before j3 and j4, then we can not
Quoting Tang, Changqing [EMAIL PROTECTED]:
Subject: RE: RFCv2: SRC API
Cleanup:
When job j1 does not need to communicate to any jobs on node
n, it disconnects qp1 from qp2, and asks j2 to destroy qp2.
+
+Note: both qp1 and qp2 must exist for the communication to
take place.
Quoting Ramachandra K [EMAIL PROTECTED]:
Subject: [PATCH 0/5 VNIC] VNIC patch series for OFED-1.2 and OFED-1.2.c
Vlad,
Please apply this VNIC patch series to both the OFED-1.2 and OFED-1.2.c
branches.
This series contains changes to the VNIC driver for supporting iPath and the
new
Quoting Kuchimanchi, Ramachandra [EMAIL PROTECTED]:
Subject: RE: [PATCH 0/5 VNIC] VNIC patch series for OFED-1.2 and OFED-1.2.c
-Original Message-
From: Michael S. Tsirkin [mailto:[EMAIL PROTECTED]
Sent: Mon 8/6/2007 11:48 PM
To: Kuchimanchi, Ramachandra
Cc: [EMAIL PROTECTED]; ewg
Hmm, I thought about it some more.
kmem_cache struct is not exported on recent kernels,
so this might br hard to do.
So I think the patch is probably the right approach, after all.
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: [PATCH ofed-1.2.c] ehca: backport kmem_cache_zalloc
I'm happy with stuff as it is: the ifdefs make it easy to figure
which version does the backport apply.
BTW, I think the same backport will be needed for older kernels as well, no?
Quoting Hoang-Nam Nguyen [EMAIL PROTECTED]:
Subject: Re: [PATCH ofed-1.2.c] ehca: backport kmem_cache_zalloc() for
Quoting Hoang-Nam Nguyen [EMAIL PROTECTED]:
Subject: Re: [PATCH ofed-1.2.c] ehca: backport kmem_cache_zalloc() for
2.6.10/sles10/sles10_sp1
On Tuesday 07 August 2007 15:23, Michael S. Tsirkin wrote:
Quoting Hoang-Nam Nguyen [EMAIL PROTECTED]:
Subject: Re: [PATCH ofed-1.2.c] ehca
Quoting Hoang-Nam Nguyen [EMAIL PROTECTED]:
Subject: Re: [PATCH ofed-1.2.c] ehca: backport kmem_cache_zalloc() for
2.6.10/sles10/sles10_sp1
On Tuesday 07 August 2007 15:23, Michael S. Tsirkin wrote:
Quoting Hoang-Nam Nguyen [EMAIL PROTECTED]:
Subject: Re: [PATCH ofed-1.2.c] ehca
* ehca patches for 2.6.23-rcX were incorporated, which is not acceptable
for us to support in 1.2.c. Upstream code of ehca in kernel contains
major changes in order to support ehca2 with new features, which is
targeted for ofed-1.3. We have not requested to have those new
features for
Quoting Doug Ledford [EMAIL PROTECTED]:
Subject: Re: ofa_1_2_c_kernel 20070802-0201 daily build status
On Sat, 2007-08-11 at 21:13 +0300, Michael S. Tsirkin wrote:
Quoting Hoang-Nam Nguyen [EMAIL PROTECTED]:
Subject: Re: ofa_1_2_c_kernel 20070802-0201 daily build status
Hello
1. OFED 1.2.5 (was 1.2.c) is ready for release:
An issue with ehca: There are patches form kernel 2.6.23 that were
inserted by mistake and must be removed before the release
There aren't, really. The snapshot generating scripts seem
to be broken and seem to put code from ofed_kernel branch
Quoting Doug Ledford [EMAIL PROTECTED]:
Subject: Re: [ofa-general] Re: ofa_1_2_c_kernel 20070802-0201 daily build
status
On Tue, 2007-08-14 at 09:59 +0200, Hoang-Nam Nguyen wrote:
Hi Doug!
On Sat, 2007-08-11 at 21:13 +0300, Michael S. Tsirkin wrote:
Quoting Hoang-Nam Nguyen [EMAIL
Quoting Stefan Roscher [EMAIL PROTECTED]:
Subject: Re: [ewg] Re: OFED Aug 13 meeting summary
On Tuesday 14 August 2007 14:06, Tziporet Koren wrote:
Michael S. Tsirkin wrote:
1. OFED 1.2.5 (was 1.2.c) is ready for release:
An issue with ehca: There are patches form kernel 2.6.23
IIRC this tree includes new local sa bits from Sean which
are interated as part of sa module.
Quoting Erez Zilber [EMAIL PROTECTED]:
Subject: ib_local_sa.ko is not created
Vlad,
I'm trying to build run ofa_kernel from
git://git.openfabrics.org/~vlad/ofed_kernel.git ofed_kernel
I'm running
It disagrees about the symbol version because my machine still has the
original ib_local_sa module that comes with RH4 up4. How can we solve
this problem?
Reboot the machine.
--
MST
___
ewg mailing list
ewg@lists.openfabrics.org
Quoting Erez Zilber [EMAIL PROTECTED]:
Subject: Re: [PATCH] stop OFED before uninstalling it
Tziporet Koren wrote:
Erez Zilber wrote:
stop OFED before uninstalling it
Signed-off-by: Erez Zilber [EMAIL PROTECTED]
---
uninstall.sh |5 +
1 files changed, 5 insertions(+),
Quoting Yosef Etigin [EMAIL PROTECTED]:
Subject: Re: RFC: OFED-1.3-20070823-1130 - first build
Hi Vlad,
I have some comments regarding install.pl.
Overall, I think it's too long for a perl script.
So ... what's your point?
1. The first ~1K lines are a database of the existing packages.
commit:
commit b054b6c133aa89907ee93e5d105c0d44774e9e6a
Author: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Tue May 29 16:07:56 2007 +0300
Update fixes for kernel 2.6.21-rc3: remove applied patches,
update patches dma_map_sg.patch and zap_ipoib_5_cm_drain_by_send_wr.patch
Quoting Arlin Davis [EMAIL PROTECTED]:
Subject: Re: [ofa-general] OFED 1.2.5 - GA release
How can I build/install OFED 1.2.5 with ib_local_sa.ko? It seems to
build but does not install and I need SA caching options.
Can anyone tell me how to get ib_local_sa.ko installed with OFED
Quoting Erez Zilber [EMAIL PROTECTED]:
Subject: RE: [PATCH 0/2] IB/iser: iSCSI iSER fixes for RH4 in OFED 1.3
Quoting Erez Zilber [EMAIL PROTECTED]:
Subject: [PATCH 0/2] IB/iser: iSCSI iSER fixes for RH4 in OFED 1.3
The following patches fix bugs in open-iscsi over iSER for the RH4
Quoting Erez Zilber [EMAIL PROTECTED]:
Subject: RE: [PATCH 0/2] IB/iser: iSCSI iSER fixes for RH4 in OFED 1.3
Quoting Erez Zilber [EMAIL PROTECTED]:
Subject: [PATCH 0/2] IB/iser: iSCSI iSER fixes for RH4 in OFED 1.3
The following patches fix bugs in open-iscsi over iSER for the RH4
Done. I'll push soon.
Quoting Steve Wise [EMAIL PROTECTED]:
Subject: [GIT PULL ofed_1_2_c] cxgb3 bug fixes
Vlad (Michael/Tziporet in Vlad's absence),
Please integrate the following cxgb3 bug fixes into ofed-1.2.5. All of
these patches are either in 2.6.23 or merged into Jeff Garzik's upstream
Quoting Roland Dreier [EMAIL PROTECTED]:
Subject: Re: RFC: modify upstream code to make backporting easier
I wonder whether it's acceptable in cases such as this to add
a wrapper in upstream code. For example, upstream could have:
#ifndef pci_get_revision
#define
Quoting Yosef Etigin [EMAIL PROTECTED]:
Subject: building userspace on ppc64 is broken
While building user-space binaries on ppc64, the libs are placed
in /usr/lib64, but they are built as 32 bit. This happens because
in ofed 1.2 CFLAGS=-m64 was passed by the environment from the
install
Quoting Hoang-Nam Nguyen [EMAIL PROTECTED]:
Subject: ofed-1.3 daily build package's content
Hello Vlad and Michael!
Just downloaded daily build package OFED-1.3-20070917-0600 and saw
in SRPMS:
localhost:/home/nguyen/tmp/OFED-1.3-20070917-0600/SRPMS # ls -l
ofa_kernel-1.3-ofed2007091*
Oren Kladnitsky [EMAIL PROTECTED] is taking over
maintaining mstflint and imgen tools from me.
His trees:
git://git.openfabrics.org/~orenk/mstflint.git
git://git.openfabrics.org/~orenk/imgen.git
are, starting now, the authoritative source for these tools.
Oren is the internal maintainer of
Will it break build of 32 bit libraries on ppc64?
Quoting Yosef Etigin [EMAIL PROTECTED]:
Subject: [PATCH] installer: fix build environment for ppc64
On ppc64, binaries are compiled as 32 bit by default unless the -m64
flag is specified. When libs are built for ppc64 they are placed in
Quoting Erez Zilber [EMAIL PROTECTED]:
Subject: Re: [ewg] Re: [PATCH 0/2] IB/iser: iSCSI iSER fixes for RH4 in
OFED?1.3
Erez Zilber wrote:
What about
kernel_patches/backport/2.6.9_U5/iser_cmd_to_2_6_22.patch
given the name, isn't it needed in other kernels up to
Quoting Steve Wise [EMAIL PROTECTED]:
Subject: [GIT PULL] ofed-1.2.5 / ofed-1.3 - new libcxgb3 release v1.0.2
Please pull the latest from my libcxgb3 git repos to update the
ofed-1.2.5 and ofed-1.3 libcxgb3 release. This will update to version
1.0.2 of libcxgb3 which fixes a doorbell
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: [GIT PULL] ofed-1.2.5 / ofed-1.3 - new libcxgb3 release v1.0.2
Quoting Steve Wise [EMAIL PROTECTED]:
Subject: [GIT PULL] ofed-1.2.5 / ofed-1.3 - new libcxgb3 release v1.0.2
Please pull the latest from my libcxgb3 git repos
Quoting Steve Wise [EMAIL PROTECTED]:
Subject: Re: [GIT PULL] ofed-1.2.5 / ofed-1.3 - new libcxgb3 release v1.0.2
Michael S. Tsirkin wrote:
Quoting Steve Wise [EMAIL PROTECTED]:
Subject: [GIT PULL] ofed-1.2.5 / ofed-1.3 - new libcxgb3 release v1.0.2
Please pull the latest from my
Quoting Hoang-Nam Nguyen [EMAIL PROTECTED]:
Subject: Please pull libehca.git/libehca ofed_1_3 branch
Hi Michael and Vlad!
Please pull from git://git.openfabrics.org/~hnguyen/libehca.git
branch ofed_1_3 to get the fixes below.
done
--
MST
___
Quoting Or Gerlitz [EMAIL PROTECTED]:
Subject: [for OFED 1.3 PATCH 2/2] IB/ipoib: enable IGMP for userpsace
multicast IB apps
Michael,
This patch needs to go to all the directories under kernel_patches/backport
that contain the
ipoib_class_device_to_2_6_20.patch, I suggest it would be
Please note that my email address is changing.
You can contact me at my new address
m dot s dot tsirkin at gmail dot com
(address mangled to confuse spambots, replace dot with . and at with @ to
get the actual mail address)
Near term, I might not have time for openfabrics related
On Mon, Jan 10, 2011 at 10:51:13AM -0800, Roland Dreier wrote:
Maybe we can use MST's current email to ask him... Michael, do you have
any memory of the issue we worked around here?
I have question regarding workaround introduced in commit 559ce8f1 of
the mainline tree:
74 matches
Mail list logo
