OK Thanks. This will give us some time to find and remove all these
gracefully.
> -Original Message-
> From: Hal Rosenstock [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 23, 2006 7:03 PM
> To: openib-general@openib.org
> Cc: Eitan Zahavi
> Subject: [PATCH] OpenSM/complib: Restore cl_mem*
Eric Barton wrote:
In my ULP (lustre networking) I maintain a common pool of send descriptors and
per-connection receive descriptors. So it seems reasonable to have a single CQ
for all sends and one CQ per-connection for receives.
Please note that since completions for each CQ make the HCA to
Hello all,
In the krping test utility get_dma_mr is called with access premissions
IB_ACCESS_LOCAL_WRITE|IB_ACCESS_REMOTE_WRITE|IB_ACCESS_REMOTE_READ, But
the lkey we get from get_dma_mr is similar to reserved lkey with which
only Local operations are allowed, but here it seems violating that
stat
Eric,
I have no problem with splitting CQ,
you can refer my IPoIB splitting CQ patch.
Could you share your code here so we
can give you some suggestions?
Thanks
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone(Fax): (503) 578-7638___
Hi Tom,
I have downloaded your release 5 of the NFS/RDMA and am having trouble
mounting the rdma nfs, the
"./nfsrdmamount -o rdma on16-ib:/mnt/rdma /mnt/rdma" command never
returned. and the dmesg for client and server are:
-- demsg from client -
RPCRDMA Module Init, register RPC RDMA tr
Roland,
Thanks for your question. First of all, the two uDAPL implementations
are different. MVAPICH2 code is mostly same for both these
implementations. Also, these numbers have been taken on two different
platforms. Even though the processor speed is the same on both
platforms, other components
Bryan> How do you feel about taking one code motion patch for
Bryan> 2.6.17? :-)
It's probably OK as long as it's pure code motion. In other words
separate the actual fixes from moving code around. What I want to
avoid is the giant combo patch that does several different things,
because
On Tue, 2006-05-23 at 14:09 -0700, Roland Dreier wrote:
> Thanks, I've put 1 through 10 into my git tree and asked Linus to pull.
Thanks.
> BTW, I just tried SRP with 2.6.17-rc4 + my for-2.6.18 tree + all of
> these patches, and immediately after connecting to a storage target I
> get the followi
Thanks, I've put 1 through 10 into my git tree and asked Linus to pull.
BTW, I just tried SRP with 2.6.17-rc4 + my for-2.6.18 tree + all of
these patches, and immediately after connecting to a storage target I
get the following:
Kernel BUG at drivers/infiniband/hw/ipath/ipath_layer.c:761
invalid
Linus, please pull from
master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
This tree is also available from kernel.org mirrors at:
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
for-linus
This contains fixes for the new ipath driver. The c
They should work, that's what they do internally.
Quoting r. Paul <[EMAIL PROTECTED]>:
Subject: Re: Compilation issues on rhel4 u3 ppc64 sysfs.o
Michael,
Thanks. I will try this if the build scripts from the OFED tarball dont
work. (I was unaware that such a thing existed.)
Thanks.
On
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: [openib-general] Re: Plans for libibverbs 1.1
>
> Michael> Assuming development is done in git, won't we just have
> Michael> two git trees - for 1.0 and for 1.1?
>
> I think that misses the point of git. By keeping multiple br
Michael> Assuming development is done in git, won't we just have
Michael> two git trees - for 1.0 and for 1.1?
I think that misses the point of git. By keeping multiple branches in
the same git repository then we have full history information, merging
patches to both branches becomes easi
Michael, Thanks. I will try this if the build scripts from the OFED tarball dont work. (I was unaware that such a thing existed.)Thanks.On 5/23/06,
Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
Quoting r. Paul Lundin <[EMAIL PROTECTED]>:> Subject: Compilation issues on rhel4 u3 ppc64 sysfs.
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: Plans for libibverbs 1.1
>
> Michael> What is meant by canonical repository? I assume
> Michael> development will be done in git and svn will track some
> Michael> git tree since early tasters seem to like it.
>
> Yeah, I gu
Michael> What is meant by canonical repository? I assume
Michael> development will be done in git and svn will track some
Michael> git tree since early tasters seem to like it.
Yeah, I guess that could work. But it doesn't really address the
issue of where to put libibverbs 1.0 vs. 1.
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: Plans for libibverbs 1.1
>
> Michael> Couldn't parse this. Could you explain?
>
> Just that git-svn doesn't really help all that much if the canonical
> upstream repository is still svn. You can't do anything beyond the
> svn model
Quoting r. Paul Lundin <[EMAIL PROTECTED]>:
> Subject: Compilation issues on rhel4 u3 ppc64 sysfs.o
>
> Hi All,
> I just started working with openIB in the past week. I am having an
> issue getting the kernel modules to compile with the stock rhel4 u3 kernel. I
> have applied the patches fo
Michael> Couldn't parse this. Could you explain?
Just that git-svn doesn't really help all that much if the canonical
upstream repository is still svn. You can't do anything beyond the
svn model of linear history anyway.
- R.
___
openib-general ma
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: Plans for libibverbs 1.1
>
> Michael> I'm playing with git-svn a bit - seems to work so far.
> Michael> Is it possible to use it to develop in git and keep svn
> Michael> in sync?
>
> Yes, but obviously what happens in the s
Michael> I'm playing with git-svn a bit - seems to work so far.
Michael> Is it possible to use it to develop in git and keep svn
Michael> in sync?
Yes, but obviously what happens in the svn tree cannot be something
that can't be represented in svn.
- R.
__
No clue, I know if you grab OFED 1.0 rc4 tarball and run
install.sh, it should work.
Scott
Weitzenkamp
SQA and Release
Manager
Server Virtualization
Business Unit
Cisco Systems
From: Paul [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 23, 2006 12:42 PMTo: Scott
Weitzenkamp (
Scott, Thanks for the confirmation and the quick reply. Any ideas as to what might be causing the error in question ?Regards.On 5/23/06, Scott Weitzenkamp (sweitzen)
<[EMAIL PROTECTED]> wrote:
OFED 1.0 rc4 does compile and run on RHEL4 U3
ppc64.
Scott
Weitzenkamp
SQA and Release
Manager
OFED 1.0 rc4 does compile and run on RHEL4 U3
ppc64.
Scott
Weitzenkamp
SQA and Release
Manager
Server Virtualization
Business Unit
Cisco Systems
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paul
LundinSent: Tuesday, May 23, 2006 12:34 PMTo:
openib-gene
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: Plans for libibverbs 1.1
>
> Michael> Might some place under branches be better?
>
> Someplace under git would be better of course ;)
>
> But I don't think I want to move the libibverbs-1.0 tree too far out
> of the way. After all
Hi All, I just started working with openIB in the past week. I am having an issue getting the kernel modules to compile with the stock rhel4 u3 kernel. I have applied the patches found at
https://openib.org/svn/gen2/branches/backport/2.6.9_U3/ and followed the instructions from https://openib.
The problem was that node A's sending thread, which handles sending RDMA
read response data, would write the trigger word, the last packet would
be sent, node B would send a new RDMA read request, node A's interrupt
handler would initialize s_rdma_sge, then node A's sending thread would
update s_rd
This is required for even semi-decent performance on OpenIB.
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 6bf52c0f0f0d -r 5d7e365286b3 drivers/infiniband/hw/ipath/ipath_eeprom.c
--- a/drivers/infiniband/hw/ipath/ipath_eeprom.cTue May 23 11:29:15
2006 -0700
+++ b/drivers/in
Fixed so it works on the PE-800. It had not previously been updated to
match PE-800 receive interrupt differences from HT-400.
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 5d7e365286b3 -r 8d87788e21b1
drivers/infiniband/hw/ipath/ipath_file_ops.c
--- a/drivers/infiniband/hw/ipath/
This fixes an oops.
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 8d87788e21b1 -r 551717ecc3db drivers/infiniband/hw/ipath/ipath_verbs.c
--- a/drivers/infiniband/hw/ipath/ipath_verbs.c Tue May 23 11:29:16 2006 -0700
+++ b/drivers/infiniband/hw/ipath/ipath_verbs.c Tue May 23 11:29:16
At this point, the core QP structure hasn't been initialized, so what's
in there isn't valid. Get the same information elsewhere.
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 3d844dee2f61 -r c892bcb21ac1 drivers/infiniband/hw/ipath/ipath_qp.c
--- a/drivers/infiniband/hw/ipath/ipat
Fix NULL deref due to pcidev being clobbered before dd->ipath_f_cleanup()
was called.
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r c7cf56636dd1 -r 6bf52c0f0f0d drivers/infiniband/hw/ipath/ipath_driver.c
--- a/drivers/infiniband/hw/ipath/ipath_driver.cTue May 23 11:29:15
20
Per Andrew's request.
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 386fe7306b31 -r c7cf56636dd1 drivers/infiniband/hw/ipath/ipath_qp.c
--- a/drivers/infiniband/hw/ipath/ipath_qp.cTue May 23 11:29:15 2006 -0700
+++ b/drivers/infiniband/hw/ipath/ipath_qp.cTue May 23 11:29:15
The local loopback path for RC can lock the rkey table lock without
blocking interrupts. The receive interrupt path can then call
ipath_rkey_ok() and deadlock. Remove the redundant lock.
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r abcc41d46f4c -r bc968dacc860 drivers/infiniband/
Fix the interface version that gets exported to userspace.
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r bb640dcf4d9d -r 386fe7306b31
drivers/infiniband/hw/ipath/ipath_file_ops.c
--- a/drivers/infiniband/hw/ipath/ipath_file_ops.c Tue May 23 11:29:15
2006 -0700
+++ b/drivers/i
Make sure modify_qp won't modify the QP if any of the changes failed.
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r bc968dacc860 -r bb640dcf4d9d drivers/infiniband/hw/ipath/ipath_qp.c
--- a/drivers/infiniband/hw/ipath/ipath_qp.cTue May 23 11:29:15 2006 -0700
+++ b/drivers/infini
Hi, Roland -
Here are some patches for 2.6.17. They all fix kernel or userspace
crasher bugs. I may have a few more for you in a while, too.
Regards,
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo
Eric> My code worked OK with a single CQ per connection, but when
Eric> I try separate send and receive CQs, I don't see any send
Eric> completions.
Eric> Has anyone else tried separate send and receive CQs?
Yes, for example I know Shirley Ma is working on patches that change
IPoI
On Tue, 2006-05-23 at 14:14, Ishai Rabinovitz wrote:
> Hi,
>
> I understand that there is a way to be informed by mail when there is a
> commit to the svn repository.
> How can I register?
See http://openib.org/mailman/listinfo/openib-commits
> Can I register to get notification only on svn com
Hi,
More dumb questions :)
In my ULP (lustre networking) I maintain a common pool of send descriptors and
per-connection receive descriptors. So it seems reasonable to have a single CQ
for all sends and one CQ per-connection for receives.
My code worked OK with a single CQ per connection, but
Hi,
I understand that there is a way to be informed by mail when there is a commit
to the svn repository.
How can I register?
Can I register to get notification only on svn commit to specific directories?
Thanks
--
Ishai Rabinovitz
___
openib-general
On 09:14 Tue 23 May , Eitan Zahavi wrote:
> >
> > I would be agree with your last example, but it is not the case - what
> > you will actually find in osm_pkey_mgr.h is some object with no
> related
> > to pkey management fields, but instead with four duplicated from
> > somewhere pointers (an
Michael> Might some place under branches be better?
Someplace under git would be better of course ;)
But I don't think I want to move the libibverbs-1.0 tree too far out
of the way. After all it will still be required for low-level driver
libraries that haven't been converted yet.
- R.
___
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Plans for libibverbs 1.1
>
> I'm planning on branching the libibverbs tree so that I can open a 1.1
> development branch where ABI/API stability is not a requirement. My
> current plan is to copy the current src/userspace/libibverbs tree in
Roland Dreier <[EMAIL PROTECTED]> wrote on 05/23/2006
09:09:05 AM:
> Did you send the other 6 patches in this series?
Yes, I am splitting these patches.
> I was waiting to comment until I had all the patches, but there is
one
> really bad thing here:
>
> > + IPOIB_NUM_SEND_WC
= 3
I'm planning on branching the libibverbs tree so that I can open a 1.1
development branch where ABI/API stability is not a requirement. My
current plan is to copy the current src/userspace/libibverbs tree in
svn to src/userspace/libibverbs-1.0. The libibverbs-1.0 tree would be
used for stable mai
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: [openib-general] RE: [PATCH] multiple RDMA_CM_EVENT_DISCONNECTED
> callbacks
>
> Roland Dreier wrote:
> >Sean> Thanks for testing this. I've committed this patch to svn.
> >
> >Should this be merged into what I have queued for 2.6.18?
Sean> I think so. I was going to send another update later today
Sean> that included the patches that Michael wanted for SDP
Sean> support as well. (I didn't see that he had posted those
Sean> yet.)
OK, I'll wait for that.
Thanks,
Roland
___
Roland Dreier wrote:
Sean> Thanks for testing this. I've committed this patch to svn.
Should this be merged into what I have queued for 2.6.18?
I think so. I was going to send another update later today that included the
patches that Michael wanted for SDP support as well. (I didn't se
Jack Morgenstein wrote:
Prevent opening multiple RMPP MAD transaction sessions at responder side
with the same TID, GID/LID, class.
Could happen if RMPP requests are retried while response is in progress.
My preference for handling this is to detect and discard duplicate requests, and
verify
Sean> Thanks for testing this. I've committed this patch to svn.
Should this be merged into what I have queued for 2.6.18?
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubsc
> +struct ib_device_attr device_attr;
How big is struct ib_device_attr? I've usually been reluctant to put
this type of thing on the stack to avoid bloating stack usage too
much.
- R.
___
openib-general mailing list
openib-general@openib.org
http
Eric Barton wrote:
I just tested your patch and checked that it prevents the double
DISCONNECT event callback (it does :).
Thanks for testing this. I've committed this patch to svn.
- Sean
___
openib-general mailing list
openib-general@openib.org
ht
Or> Also, if the patch makes sense and the memfree issue is
Or> resolved, i'd like to change the name of the device attribute
Or> from max_map_per_fmr to max_remaps_per_fmr, i can resend this
Or> patch series with this fix.
The patch makes sense, although of course you need to make
Or> When "requests" come fast enough, there's a window in time
Or> when there's an unmapping of N FMRs running at batch, but out
Or> of the remaining N FMRs some are already dirty and can't be
Or> used to serve a credit. So the app fails temporally... So,
Or> setting the waterma
OpenSM/complib: Restore cl_mem* routines as deprecated rather than
removing them altogether
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
Note: If this approach is acceptable, I will be doing the same with
cl_malloc, cl_zalloc, cl_free, and friends.
Index: include/complib/cl_memory.h
===
Did you send the other 6 patches in this series?
I was waiting to comment until I had all the patches, but there is one
really bad thing here:
> + IPOIB_NUM_SEND_WC = 32,
> +void ipoib_ib_send_completion(struct ib_cq *cq, void *dev_ptr)
> +{
> + struct net_device *dev = (
>>> I'm afraid it *does* have an effect, unfortunately.
Hmm, go ahead and forward the fix from 2.6.17 to the stable team for
kernel 2.6.16 if this bug affects your target.
Thanks,
Roland
___
openib-general mailing list
openib-general@openib.org
ht
Sean,
I just tested your patch and checked that it prevents the double
DISCONNECT event callback (it does :).
Cheers,
Eric
---
|Eric BartonBarton Software |
|9 York Gardens Tel:
http://openib.org/bugzilla/show_bug.cgi?id=92
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Additional Comments From
On Mon, 22 May 2006, zhu shi song wrote:
> I won't wait sdp OK. I hope to use another method to
> port squid. I know VAPI, uDAP can do this. But can
> you suggest me which is best way I should adopt? And
> How can I get more info about how to program using
> these methods?
uDAPL was defined
Ishai> As I told you before, your patch looks correct. Are you
Ishai> going to apply it?
Sorry, I committed it to git but forgot to check it into svn. (One
more reason to stop maintaining kernel drivers in svn)
- R.
___
openib-general mailing
On Wed, May 17, 2006 at 02:55:57AM +0300, Roland Dreier wrote:
> > + /*
> > + * We need 2 scsi_host_put becuase there are two get:
> > + * in scsi_host_alloc and in scsi_add_host
> > + */
> > + scsi_host_p
Prevent opening multiple RMPP MAD transaction sessions at responder side
with the same TID, GID/LID, class.
Could happen if RMPP requests are retried while response is in progress.
Signed-off-by: Jack Morgenstein <[EMAIL PROTECTED]>
Index: openib_branch1.0/drivers/infiniband/core/mad.c
=
Talpey, Thomas wrote:
Doesn't this change only *increase* the window of vulnerability
which FMRs suffer? I.e. when you say "dirty", you mean "still mapped",
right?
I am not sure i can quantify how much vulnerability is increased,
however please recall that the openib fmr pool is ment to be for
Doesn't this change only *increase* the window of vulnerability
which FMRs suffer? I.e. when you say "dirty", you mean "still mapped",
right?
Tom.
At 07:11 AM 5/23/2006, Or Gerlitz wrote:
>Or Gerlitz wrote:
>> The max fmr remaps device attribute is not set by the driver, so the generic
>> fmr_po
Ishai Rabinovitz <[EMAIL PROTECTED]> writes:
> On Tue, May 23, 2006 at 10:10:05AM +0300, Arne Redlich wrote:
>> Roland Dreier <[EMAIL PROTECTED]> writes:
>>
>> > > Roland, maybe this means we need scsi/srp.h in svn for now?
>> > > svn is supposed to work on 2.6.16 ...
>> >
>> > As far as I can
Or Gerlitz wrote:
The max fmr remaps device attribute is not set by the driver, so the generic
fmr_pool uses a default of 32. Enlaring this quantity would make the amortized
cost of remaps lower. With the current mthca "default profile" on memfull HCA
17 bits are used for MPT addressing so an F
This patch ports the generic fmr pool to query the ib device and use the
device attribute as for the max number of fmr remaps. If the device does
not suport the attribute, the code reverts to use the IB_FMR_MAX_REMAPS
(32) default.
Or.
Signed-off-by: Or Gerlitz <[EMAIL PROTECTED]>
Index: core/f
The max fmr remaps device attribute is not set by the driver, so the generic
fmr_pool uses a default of 32. Enlaring this quantity would make the amortized
cost of remaps lower. With the current mthca "default profile" on memfull HCA
17 bits are used for MPT addressing so an FMR can be remapped
On Tue, May 23, 2006 at 10:10:05AM +0300, Arne Redlich wrote:
> Roland Dreier <[EMAIL PROTECTED]> writes:
>
> > > Roland, maybe this means we need scsi/srp.h in svn for now?
> > > svn is supposed to work on 2.6.16 ...
> >
> > As far as I can tell the bug in the header has no effect on how the IB
Roland Dreier <[EMAIL PROTECTED]> writes:
> > Roland, maybe this means we need scsi/srp.h in svn for now?
> > svn is supposed to work on 2.6.16 ...
>
> As far as I can tell the bug in the header has no effect on how the IB
> SRP initiator works.
Roland,
I'm afraid it *does* have an effect, unf
72 matches
Mail list logo
