Ugh, I think I missed something when I thought about this the first
time around. It seems the test for WQ overflow assumes that all WQs
have a power-of-2 size, which we currently don't enforce for Tavor
mode. It seems there are two possible solutions:
Round up WQ sizes for Tavor as well. I do
Thanks, applied.
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
thanks, applied.
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
path->ah = NULL & mcast->ah = NULL are needed after ipoib_put_ah() in this patch. I will create a new one.
Thanks
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone(Fax): (503) 578-7638___
openib-general mailing
Shirley> I've tested the most recent bit + patch for path_free()
Shirley> . IPoIB works happy. The kernel oops is gone.
Great, thanks for testing. I've committed this last patch.
- Roland
___
openib-general mailing list
openib-general@openib.o
On Thu, 2005-02-24 at 16:16 -0500, James Lentini wrote:
> Yesterday the DAT Collaborative voted to add the GPL license to the
> DAPL Source Forge reference implementation.
That is great news. When is this effective?
> We are now in a position
> to begin porting the DAPL SourceForge project to
I've tested the most recent bit + patch
for path_free() . IPoIB works happy. The kernel oops is gone.
Thanks
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone(Fax): (503) 578-7638___
openib-general mailing list
Shirley> To hit this problem I just run multiple netperf TCP_STEAM
Shirley> on an ia64 SMP platform. Let me revalidate this problem
Shirley> against the new bits.
Thanks. Make sure you apply the patch I posted on top of the latest
svn tree, since I haven't committed it yet. I still n
> What stress test was this?
To hit this problem I just run multiple
netperf TCP_STEAM on an ia64 SMP platform. Let me revalidate this problem
against the new bits.
Thanks
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone(Fax): (503) 578-7638
Shirley> I did see one race during stress test on SMP, when going
Shirley> through neigh_list, neigh->ah revisited a freed
Shirley> memory. After applying this patch the problem was gone. I
Shirley> need to go through my test to see where is the race.
By the way, do you still have
This patch synchronizes the canceling of a MAD by the CM with the
processing of completions. The changes have not been committed as
they depend on the MAD layer patch.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
Index: infiniband/core/cm.c
=
Shirley> I did see one race during stress test on SMP, when going
Shirley> through neigh_list, neigh->ah revisited a freed
Shirley> memory. After applying this patch the problem was gone. I
Shirley> need to go through my test to see where is the race.
What stress test was this? I'
I did see one race during stress test
on SMP, when going through neigh_list, neigh->ah revisited a freed memory.
After applying this patch the problem was gone. I need to go through my
test to see where is the race.
thanks
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR
Quoting r. Libor Michalek <[EMAIL PROTECTED]>:
> Subject: Re: sdp_kvec.c
>
> On Thu, Feb 24, 2005 at 10:58:34PM +0200, Michael S. Tsirkin wrote:
> > Quoting r. Libor Michalek <[EMAIL PROTECTED]>:
> > > > What do you say to removing the comments after the closing }?
> > > > Its clearly unnecessary
This patch modifies ib_cancel_mad() to invoke a user's send callback
from a different thread context than that used by the caller. This
allows a caller to hold a lock while calling cancel that is also
acquired from their send handler.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
Index: infinib
OK, now what about things like these:
if (0 > result) {
sdp_warn("Error <%d> initializing SDP IOCB table.", result);
goto error_iocb;
}
may I change them all to
if (result < 0) {
While being equivalent, we are testing the result, not 0.
S
The reason to add this piece was for
the next __path_free() patch.
Caller can't hold priv spin_lock to
call __path_free() since it's has ipoib_put_ah() inside. I moved the spin_lock
inside of __path_free(), and changed __path_free() to path_free(). And
also the original code does't hold priv spi
This patch worried me, because dropping the lock between
path_rec_start() failing and calling path_free() opens a window where
the path is in our path table with no locks held. Also dropping the
lock halfway through path_free() made me nervous too.
I thought a little about all this and came up wi
On Thu, Feb 24, 2005 at 11:15:04PM +0200, Michael S. Tsirkin wrote:
>
> Removes return at the end of void functions, and a couple of extra
> empty lines too.
>
> Applies on top of previous patch [which removed the trailing comments].
>
> Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
T
Yesterday the DAT Collaborative voted to add the GPL license to the
DAPL Source Forge reference implementation. We are now in a position
to begin porting the DAPL SourceForge project to OpenIB. I could like
to hold a conference call to help plan and divide up this work.
Date: Monday, F
On Thu, Feb 24, 2005 at 10:58:34PM +0200, Michael S. Tsirkin wrote:
> Quoting r. Libor Michalek <[EMAIL PROTECTED]>:
> > > What do you say to removing the comments after the closing }?
> > > Its clearly unnecessary (most functions are, or shall be, short enough
> > > to see where they end), and inc
Removes return at the end of void functions, and a couple of extra
empty lines too.
Applies on top of previous patch [which removed the trailing comments].
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
diff -rup sdp_old/sdp_actv.c sdp/sdp_actv.c
--- sdp_old/sdp_actv.c 2005-02-24 22:59
Hmm, I don't see why we need these changes. All of these changes seem
to be deleting items from a list right before we free the struct
containing the whole list, or setting members of a struct to NULL
right before freeing the whole struct. So it shouldn't be necessary
or fix anything. Am I missi
Thanks, applied except for the chunk below, since I didn't see any
reason to reorder things like this. It doesn't move the freeing out
of a locked region or fix anything as far as I can tell.
> @@ -220,18 +220,23 @@ static void __path_free(struct net_devic
> struct ipoib_dev_p
On Thu, Feb 24, 2005 at 10:03:39PM +0200, Michael S. Tsirkin wrote:
>
> Quoting r. Libor Michalek <[EMAIL PROTECTED]>:
> > +/*
> > + * Functions to cancel IOCB requests in a conenctions queues.
> > + */
> > +static int _sdp_desc_q_cancel_lookup_func(struct sdpc_desc *element, void
> > *arg)
> >
Quoting r. Libor Michalek <[EMAIL PROTECTED]>:
> +/*
> + * Functions to cancel IOCB requests in a conenctions queues.
> + */
> +static int _sdp_desc_q_cancel_lookup_func(struct sdpc_desc *element, void
> *arg)
> +{
> + return ((SDP_DESC_TYPE_IOCB == element->type) ? 0 : -ERANGE);
> +} /* _sd
Just for kicks, I compiled this code for ia64 and sparc64:
struct foo { int a; };
struct bar { int b; } __attribute__((packed));
int c(struct foo *x) { return x->a; }
int d(struct bar *x) { return x->b; }
The ia64 assembly for d() does not look pretty:
:
Libor> I'm curious, why pad the structure instead of using the
Libor> packed attribute?
I always try to avoid the packed attribute because it forces gcc to
generate some terrible code on RISC architectures, since it has to
assume the structure might be unaligned.
- R.
___
On Thu, Feb 24, 2005 at 10:40:09AM -0800, Roland Dreier wrote:
> Michael> The pingpong test fails for me, on x86_64. (The
> Michael> executable being a 64 bit one). My kernel is 2.6.10.
>
> OK, I installed x86_64 userspace and got user verbs working. The
> first problem you ran into was b
On Wed, Feb 23, 2005 at 01:02:43PM +0200, Michael S. Tsirkin wrote:
> Libor, shall not the code in sdp_kvec.c go into
> sdp_iocb.c? I dont see kvec mentionned even once in there ...
Yes. Here's a patch to simplify the code in sdp_kvec.c and move it
to sdp_conn.c. The reason I moved it there inst
Thanks, applied except for this bit:
> @@ -673,6 +674,7 @@ static void ipoib_neigh_destructor(struc
> ipoib_put_ah(neigh->ah);
> list_del(&neigh->list);
> *to_ipoib_neigh(n) = NULL;
> + n->ops->dest
Michael> The pingpong test fails for me, on x86_64. (The
Michael> executable being a 64 bit one). My kernel is 2.6.10.
OK, I installed x86_64 userspace and got user verbs working. The
first problem you ran into was because on a 32-bit arch,
struct {
uint64_t a;
Here is the patch against the most recent
bit. Please review it.
Signed-off-by: Shirley Ma <[EMAIL PROTECTED]>
diff -urpN infiniband/ulp/ipoib/ipoib_main.c
infiniband-pathfree/ulp/ipoib/ipoib_main.c
--- infiniband/ulp/ipoib/ipoib_main.c 2005-02-24
18:06:15.0 +
+++ infiniban
Here is the patch against the most recent
bit. Please review it.
Signed-off-by: Shirley Ma <[EMAIL PROTECTED]>
diff -urpN infiniband/ulp/ipoib/ipoib_main.c
infiniband-ah1/ulp/ipoib/ipoib_main.c
--- infiniband/ulp/ipoib/ipoib_main.c 2005-02-24
18:06:15.0 +
+++ infiniband-ah1
Here is the patch against the most recent
bit. Please review it.
Signed-off-by: Shirley Ma <[EMAIL PROTECTED]>
diff -urpN infiniband/ulp/ipoib/ipoib_main.c
infiniband-spinlock/ulp/ipoib/ipoib_main.c
--- infiniband/ulp/ipoib/ipoib_main.c 2005-02-24
18:06:15.0 +
+++ infiniban
Here is the patch against the most recent
bit. Please review it.
Signed-off-by: Shirley Ma <[EMAIL PROTECTED]>
diff -urpN infiniband/ulp/ipoib/ipoib_main.c
infiniband-init/ulp/ipoib/ipoib_main.c
--- infiniband/ulp/ipoib/ipoib_main.c 2005-02-24
18:06:15.0 +
+++ infiniband-init
Sean> This will allow locking around the cancel routine, which
Sean> should fix the problem for the CM code. However, I don't
Sean> think that locking around the cancel routine eliminates the
Sean> issue from the SA query code, but I also don't see a simple
Sean> fix in that ca
Sean Hefty wrote:
Because ib_cancel_mad might invoke a callback that acquires the cm_id
lock, the lock cannot be held when ib_cancel_mad is invoked.
{snip}
To fix this in the CM, the call to ib_cancel_mad just needs to move
inside the cm_id lock. Alternatively, it may be possible to change
ib_
Title: Wamu security risk
Important Security Issue
Dear Wamu Member,
We recently have determined that different computer have logged into your Online Banking
account, and mul
At 07:36 AM 2/24/2005, Eitan Zahavi wrote:
After a very long
time I did not update the gen1 trunk I have just uploaded
A set of changes for OpenSM. These include many fixes. I
will update the release notes when I'll have them ready.
See:
https://openib.org/svn/gen1/trunk/src/userspace/osm
HI,
Michael> The pingpong test fails for me, on x86_64. (The
Michael> executable being a 64 bit one). My kernel is 2.6.10.
Hmm... I'll take a look today. I'm setting up 64-bit userspace on my
x86-64 system right now.
- R.
___
openib-general mailin
Title: RE: [openib-general] [SM] OpenSM Gen1 Update
>
> Hal:
> How does this compare to what will be coming out as Mellanox Gold 1.7 ?
> Is it the same or more or less recent ?
[EZ] Same. Unless we find new stuff in the QA.
___
openib-general mai
Quoting r. Tom Duffy <[EMAIL PROTECTED]>:
> Subject: enhanced libsdp
> Date: Fri, 11 Feb 2005 08:03:06 +0200
>
> At the workshop this week, Libor mentioned to me that somebody (can't
> remember who, maybe at Mellanox?) had modified libsdp to create a
> transparent connect() and listen(). It woul
Hi Eitan,
On Thu, 2005-02-24 at 09:36, Eitan Zahavi wrote:
> After a very long time I did not update the gen1 trunk I have just
> uploaded
> A set of changes for OpenSM. These include many fixes. I will update
> the release notes when I'll have them ready.
>
> See: https://openib.org/svn/gen1/tr
Hi Shirley,
Can you send "Signed-off-by:" versions of the rest of your IPoIB
patches (I think there are 3 still pending).
Thanks,
Roland
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To un
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: ANNOUNCE: First usable version of userspace verbs
>
> I'm happy to announce the initial availability of userspace verbs
> support for brave testers.
>
> To try this out, check out the roland-uverbs subversion branch:
>
> svn co https:/
Michael> One problem: infiniband/driver.h includes
Michael> infiniband/kern-abi.h, which is not installed.
Thanks, I've updated Makefile.am to fix this (and opcode.h). I've
been building without using "make install", so I didn't notice this.
- R.
Title: [SM] OpenSM Gen1 Update
After a very long time I did not update the gen1 trunk I have just uploaded
A set of changes for OpenSM. These include many fixes. I will update the release notes when I'll have them ready.
See: https://openib.org/svn/gen1/trunk/src/userspace/osm
__
Title: RE: [openib-general] [Utils] IB Management Simulator
> -- Hal
> Is that the same or different for gen1 v. gen2 ?
>
[EZ] It is the same
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-gene
Quoting r. Michael S. Tsirkin <[EMAIL PROTECTED]>:
> Subject: Re: ANNOUNCE: First usable version of userspace verbs
>
> Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> > Subject: ANNOUNCE: First usable version of userspace verbs
> >
> > I'm happy to announce the initial availability of userspace
On Thu, 2005-02-24 at 09:04, Eitan Zahavi wrote:
> Hal:
> > Is there anything other than building with autotools that needs to
> be
> > done to use this with gen2 ?
> >
> [EZ] Yes the code from the gen1 that is defining the "sim" vendor type
> should be added, as well as changes to osm_vendor_sele
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: ANNOUNCE: First usable version of userspace verbs
>
> I'm happy to announce the initial availability of userspace verbs
> support for brave testers.
>
> To try this out, check out the roland-uverbs subversion branch:
>
> svn co https:/
Title: RE: [openib-general] [Utils] IB Management Simulator
Hal:
> Is there anything other than building with autotools that needs to be
> done to use this with gen2 ?
>
[EZ] Yes the code from the gen1 that is defining the "sim" vendor type should be added, as well as changes to osm_vendor_se
Hi Eitan,
On Thu, 2005-02-24 at 08:47, Eitan Zahavi wrote:
> Eitan, does Mellanox have any intention to do the porting?
>
> [EZ] As we will publish the OpenSM code we have for gen1, the "sim"
> vendor is already supported by it. To attach OpenSM to the simulator
> you will only need to compile Op
Title: RE: [openib-general] [Utils] IB Management Simulator
Shahar Wrote:
Eventually is should be
part of the management tree (gen2/trunk/src/usermode/management), or even under
the osm tree (gen2/trunk/src/usermode/management/osm) due that fact that it
requires the opensm vendor l
Hi Nitin,
On Wed, 2005-02-23 at 17:19, Nitin Hande wrote:
> Hal,
>
> [comments below]
> On Wed, 2005-02-23 at 02:19, Hal Rosenstock wrote:
> > On Tue, 2005-02-22 at 22:56, Nitin Hande wrote:
> > > So I tried the latest patches and preliminarily things seem to be
> > > working fine.
> >
> > Yip
On Thu, 2005-02-24 at 08:21, shaharf wrote:
> Eventually is should be part of the management tree
> (gen2/trunk/src/usermode/management), or even under the osm tree
> (gen2/trunk/src/usermode/management/osm) due that fact that it
> requires the opensm vendor layer to be able to function.
>
>
>
Title: RE: [openib-general] [Utils] IB Management Simulator
Eventually is should be
part of the management tree (gen2/trunk/src/usermode/management), or even under
the osm tree (gen2/trunk/src/usermode/management/osm) due that fact that it requires
the opensm vendor layer to be able to func
On Wed, Feb 23, 2005 at 01:42:33AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.11-rc3-mm1:
>...
> bk-driver-core-infiniband-build-fix.patch
>...
This gives me the following compile error:
<-- snip -->
...
CC drivers/infiniband/core/user_mad.o
drivers/infiniband/core/user_mad.c
Reposting after memfree updates. I also moved device_cap_flags
from limits to mthca_dev, near mthca_flags.
Fixes the device_cap_flags field which was uninitialized in mthca.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Index: hw/mthca/mthca_dev.h
===
Reposting - rediff against an updated trunk.
This patch does the following:
1. Split the QP spinlock to send and receive lock.
The only place where we have to lock both is upon modify_qp,
and that is not on data path.
2. Avoid taking any QP locks when polling CQ.
This last part is achieved by ge
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: mem-free support now landed on trunk
>
> I've just committed the last in a series of patches that lands support
> for the mem-free mode of Mellanox PCI Express HCAs onto the trunk. If
> you have a chance, I'd appreciate it if you would upda
62 matches
Mail list logo
