At 02:58 PM 8/24/2006, Sean Hefty wrote:
>We're trying to create
*inter-operable* hardware and
>software in this community. So we follow the IB standard.
Atomic operations and RDD are optional, yet still part of the IB
"standard". An
application that makes use of either of these isn't guaranteed
At 10:14 AM 8/23/2006, Ralph Campbell wrote:
On Wed, 2006-08-23 at 09:47
-0700, Caitlin Bestler wrote:
> [EMAIL PROTECTED] wrote:
> > Quoting r. john t <[EMAIL PROTECTED]>:
> >> Subject: basic IB doubt
> >>
> >> Hi
> >>
> >> I have a very basic doubt. Suppose Host A is doing RDMA
write (say 8
>
Sounds good to me.
- Original Message -
From: "Roland Dreier" <[EMAIL PROTECTED]>
To: "Steve Wise" <[EMAIL PROTECTED]>
Cc: ;
Sent: Monday, August 28, 2006 6:07 PM
Subject: Re: [PATCH v4 7/7] AMSO1100 Makefiles and Kconfig changes.
> I'm finally getting around to merging this up, and:
Sean> Roland, Not sure if you've had a chance to review the SA
Sean> patches, but any comments on any of the SA related patches?
Sean> (SA registration, generic RMPP query support, or userspace
Sean> SA)
I haven't really read the later patches but I am planning on merging
at least
Thanks, I applied all 6 to for-2.6.19 (although I folded 0004 and 0005
into a single patch)
> Let me know if you'd prefer these in another format (such as inline).
I handled it all myself this time, but in the future it is easier for
me if each patch is inline in a separate email. A couple of o
Roland,
Not sure if you've had a chance to review the SA patches, but any comments on
any of the SA related patches? (SA registration, generic RMPP query support,
or
userspace SA)
- Sean
___
openib-general mailing list
openib-general@openib.org
htt
http://openib.org/bugzilla/show_bug.cgi?id=214
Summary: IB Stack ASSERTS while handling stale connections.
Product: OpenFabrics Windows
Version: unspecified
Platform: X86
OS/Version: Other
Status: NEW
Severity: critical
Fab> Is git supported in Windows? Right now, with MTHCA in SVN,
Fab> it's possible to do all development under Windows. I don't
Fab> know jack about git, so if there's a Windows client that
Fab> concern is moot.
Yes, I believe there is a cygwin package of it, although I've never
Sean Hefty wrote:
> Modify the libibcm API to provide better support for multi-threaded
> event processing. CM devices are no longer tied to verb devices
> and hidden from the user. This should allow an application to direct
> events to specific threads for processing.
>
> This patch also remove
> -Original Message-
> From: Roland Dreier [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 28, 2006 4:17 PM
>
> With that said, why would maintaining mthca exclusively
> in git make it harder to track? If anything I would think
> it would make it slightly easier, since "git log rev1..rev
Roland,
Attached are 6 git patches pulled from SVN to queue for 2.6.19. They're from
SVN versions:
4578 - include atomic as default QP attribute
8628 - fix reject message if GID is invalid
8434 - add dual-sided RMPP
8826 - remove unnecessary include
8827 - remove unnecessary include
9088 - rando
Fabian> Mellanox is currently tracking the MTHCA code base for
Fabian> Windows, and moving it out of SVN could make that harder,
Fabian> even impossible if it were to lose the BSD license.
There's no thought of changing the license. I'm sure that would be a
discussion at a much higher
Hi Roland,
On 8/28/06, Roland Dreier <[EMAIL PROTECTED]> wrote:
>Roland> You can't guarantee that someone won't come along and
>Roland> write some IB driver and get it merged upstream without a
>Roland> BSD license. So there's not much we can do anyway.
>
>Sean> Such a driver woul
I'm finally getting around to merging this up, and:
> --- /dev/null
> +++ b/drivers/infiniband/hw/amso1100/README
> @@ -0,0 +1,11 @@
> +This is the OpenFabrics provider driver for the
> +AMSO1100 1Gb RNIC adapter.
> +
> +This adapter is available in limited quantities
> +for development
>Well, what is an "OpenFabrics driver" anyway? I'm interesting in
>writing Linux drivers to be honest.
It's often ignored, but OpenFabrics does include Windows.
My understanding is that the requirement for lower level components is that they
must be licensed using dual GPL / BSD. This agreement
[...snip...]
> I think that using git makes it much easier for the developers,
I'm using stg on git. It's absolutely beautiful for tracking the kernel.
If I had to go back to SVN, I'd shoot myself.
My 2 cents...
> since
> merges with the trunk and handled far better than with svn. And in a
>
Roland> You can't guarantee that someone won't come along and
Roland> write some IB driver and get it merged upstream without a
Roland> BSD license. So there's not much we can do anyway.
Sean> Such a driver wouldn't be an OpenFabrics driver though.
Well, what is an "OpenFabrics d
Michael S. Tsirkin wrote:
> I believe communication id should be checked to detect duplicates. Right?
Can you clarify this? Check the remote comm id of an incoming REQ against a
value in timewait?
> Remote QPN stale connection rule is only to avoid a case where we keep
> connection in establish
Michael S. Tsirkin wrote:
> Another problem that I see is that CMA currently seems to completely
> mask timewait exit.
This is correct.
> So there's no way to properly handle timewait on top of cma that I can see.
I don't think so, which is what brought up the problem with Arlin. (He's using
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: drop mthca from svn?
>
> Roland Dreier wrote:
> > James> If the code is moved, how can the OpenFabrics community be
> > James> guaranteed that the entire software stack will remain under
> > James> a dual BSD/GPL license?
> >
>
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH ] RFC IB/cm do not track remote QPN in timewait state
>
> Michael S. Tsirkin wrote:
> >>The CM tracks the remote QP, not the local.
> >
> >
> > I might not have been clear.
> > For connection in timewait state, spec explicitly says
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH ] RFC IB/cm do not track remote QPN in timewait state
>
> Michael S. Tsirkin wrote:
> >>The CM tracks the remote QP, not the local.
> >
> >
> > I might not have been clear.
> > For connection in timewait state, spec explicitly says
Michael S. Tsirkin wrote:
>>The CM tracks the remote QP, not the local.
>
>
> I might not have been clear.
> For connection in timewait state, spec explicitly says local QP
> must be in reset, error or init.
> Only after it goes out of timewait can you destroy the QP.
> That's the tracking I thin
> Date: Mon, 28 Aug 2006 10:22:52 -0600> From: [EMAIL PROTECTED]> To: [EMAIL PROTECTED]> CC: [EMAIL PROTECTED]; openib-general@openib.org> Subject: Re: [openib-general] basic IB doubt> > On Mon, Aug 28, 2006 at 10:38:43AM -0400, Talpey, Thomas wrote:> > > Will turning on the Opteron's IOMMU int
Anybody run into this compiling dapltest?
gcc -g3 -Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations
-Werror -pipe
-I/home/swise/openib/intel_demo1b_userspace/dapl/test/dapltest/udapl/../../../dat/include/
-I../mdep/linux -I../include -D__LINUX__ -D__PENTIUM__ -o
Obj/d
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH ] RFC IB/cm do not track remote QPN in timewait state
>
> Michael S. Tsirkin wrote:
> > So, you must somehow detect that the remote QP is in timewait state.
> > I don't see any way to do this, and this is not what the CM
> > currentl
http://openib.org/bugzilla/show_bug.cgi?id=213
--- Comment #1 from [EMAIL PROTECTED] 2006-08-28 12:35 ---
Created an attachment (id=39)
--> (http://openib.org/bugzilla/attachment.cgi?id=39&action=view)
Fix for use of dead function
This would need to be slightly modified to check for
http://openib.org/bugzilla/show_bug.cgi?id=213
Summary: librdmacm uses deprecated libsysfs function
Product: OpenFabrics Linux
Version: 1.1rc4
Platform: Other
OS/Version: Other
Status: NEW
Severity: blocker
Priority
http://openib.org/bugzilla/show_bug.cgi?id=212
Summary: librdmacm is unversioned
Product: OpenFabrics Linux
Version: 1.1rc4
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component:
http://openib.org/bugzilla/show_bug.cgi?id=211
Summary: libibcm.so is unversioned
Product: OpenFabrics Linux
Version: 1.1rc4
Platform: All
OS/Version: All
Status: NEW
Severity: blocker
Priority: P2
Componen
Roland Dreier wrote:
> James> If the code is moved, how can the OpenFabrics community be
> James> guaranteed that the entire software stack will remain under
> James> a dual BSD/GPL license?
>
> You can't guarantee that someone won't come along and write some IB
> driver and get it mer
Michael S. Tsirkin wrote:
> So, you must somehow detect that the remote QP is in timewait state.
> I don't see any way to do this, and this is not what the CM
> currently does.
>
> Our CM tracks local QPs in timewait state, which is obviously not
> what the spec intends since remote QP could be re
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> The CM should track remote QPs that are either:
>
> 1. Part of an active connection, or
> 2. A connection that has been placed into timewait.
Agree here.
> The CM should detect attempts to connect such remote QPs, and reject them.
That's stretching w
James> Given how many levels down this is, I'm going to change my
James> mind. I think the current explicit include is better than
James> what I suggested.
Thanks, I agree. No sense introducing such a fragile dependency on an
implicit include for such a minimal gain.
- R.
_
On Mon, 28 Aug 2006, Roland Dreier wrote:
> > -#include
>
> that file declares a function as __devinit, so is
> definitely needed. What is pulling it in implicitly?
Here's the include sequence:
mthca_mcg.c includes
mthca_cmd.h includes
rdma/ib_verbs.h includes
linux/device.h incl
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: [openib-general] CMA oops
>
> Michael S. Tsirkin wrote:
> > Apparently, list->prev pointer in CMA id_priv structure is NULL
> > which causes a crash in list_del.
> >
> > I note that rdma_destroy_id tests outside the mutex lock.
> > Could t
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: [openib-general] [PATCH ] RFC IB/cm do not track remote QPN in
> timewait state
>
> Michael S. Tsirkin wrote:
> > IB spec, section 12.4, says:
> >
> > CMs shall maintain enough connection state information to detect an
> > attempt
>
On Mon, Aug 28, 2006 at 01:49:27PM -0400, Talpey, Thomas wrote:
> Okay, that's good. However, doesn't it delay reads and writes until the
> necessary table walk / mapping is resolved? Because it passes all other
> cycles through, it seems to me that an interrupt may pass data, meaning
> that order
At 12:22 PM 8/28/2006, Jason Gunthorpe wrote:
>On Mon, Aug 28, 2006 at 10:38:43AM -0400, Talpey, Thomas wrote:
>
>> Will turning on the Opteron's IOMMU introduce some of these
>> issues to x86?
>
>No, definately not. The Opteron IOMMU (the GART) is a pure address
>translation mechanism and doesn't
Michael S. Tsirkin wrote:
> IB spec, section 12.4, says:
>
> CMs shall maintain enough connection state information to detect an
> attempt
> to initiate a connection on a remote QP/EEC that has not been released
> from a connection with a local QP/EEC, or that is in the TimeWait
Thanks, applied all 3 to for-2.6.19, and pushed out my git tree.
___
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
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: [openib-general] [PATCH ] RFC IB/cm do not track remote QPN in
> timewait state
>
> Michael S. Tsirkin wrote:
> > Comments appreciated.
>
> I will look at the spec in more details, but I thought that timewait was
> included as part of th
> -#include
that file declares a function as __devinit, so is
definitely needed. What is pulling it in implicitly?
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe,
Michael S. Tsirkin wrote:
> Comments appreciated.
I will look at the spec in more details, but I thought that timewait was
included as part of the life of a connection. I.e. the connection wasn't
released until it returned to idle. Also, isn't the purpose behind timewait to
prevent re-connect
Michael S. Tsirkin wrote:
> Apparently, list->prev pointer in CMA id_priv structure is NULL
> which causes a crash in list_del.
>
> I note that rdma_destroy_id tests outside the mutex lock.
> Could that be the problem?
> The problem is not unfortunately easily reproducible.
I'll see if I see a pr
On Mon, Aug 28, 2006 at 08:23:00AM -0700, Felix Marti wrote:
> Might be a typo: dcbf does flush & invalidate and is a non-privileged
> instruction. dcbi does invalidate only but it is privileged.
Er yes, this is correct, sorry about the typo.
Jason
On Mon, Aug 28, 2006 at 10:38:43AM -0400, Talpey, Thomas wrote:
> Will turning on the Opteron's IOMMU introduce some of these
> issues to x86?
No, definately not. The Opteron IOMMU (the GART) is a pure address
translation mechanism and doesn't change the operation of the caches.
If Sun has a pro
Incorrect number of bits was taken for static_rate field.
Signed-off-by: Jack Morgenstein <[EMAIL PROTECTED]>
Index: ofed_1_1/drivers/infiniband/hw/mthca/mthca_qp.c
===
--- ofed_1_1.orig/drivers/infiniband/hw/mthca/mthca_qp.c
port_num was not being returned for unconnected QPs.
Signed-off-by: Jack Morgenstein <[EMAIL PROTECTED]>
Index: ofed_1_1/drivers/infiniband/hw/mthca/mthca_qp.c
===
--- ofed_1_1.orig/drivers/infiniband/hw/mthca/mthca_qp.c2006-
When default static rate is returned for Tavor, need to translate it
to an ib rate value.
Signed-off-by: Jack Morgenstein <[EMAIL PROTECTED]>
Index: ofed_1_1/drivers/infiniband/hw/mthca/mthca_av.c
===
--- ofed_1_1.orig/drivers/infini
[EMAIL PROTECTED] wrote:
> At 03:39 AM 8/26/2006, Gleb Natapov wrote:
>> On Fri, Aug 25, 2006 at 03:53:12PM -0400, Talpey, Thomas wrote:
>>> Flush (sync for_device) before posting.
>>> Invalidate (sync for_cpu) before processing.
>>>
>> So, before touching the data that was RDMAed into the buffer
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:openib-general-
> [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
> Sent: Monday, August 28, 2006 1:11 AM
> To: Jason Gunthorpe
> Cc: Roland Dreier; openib-general@openib.org
> Subject: Re: [openib-general] basic IB doubt
>
> On Mon
At 09:00 AM 8/28/2006, Gleb Natapov wrote:
>> 2) user must deregister any mapping before inspecting the result. I
>> doubt any of them do this, for that reason anyway.
>>
>This may have big performance impact.
You think? :-)
>> MO is that this will bite us in the a** some day. If anybody was
>>
Index: hw/mthca/mthca_mcg.c
===
--- hw/mthca/mthca_mcg.c(revision 9120)
+++ hw/mthca/mthca_mcg.c(working copy)
@@ -32,8 +32,6 @@
* $Id$
*/
-#include
-
#include "mthca_dev.h"
#include "mthca_cmd.h"
_
IB spec, section 12.4, says:
CMs shall maintain enough connection state information to detect an
attempt
to initiate a connection on a remote QP/EEC that has not been released
from a connection with a local QP/EEC, or that is in the TimeWait
state. Such an event co
On Mon, Aug 28, 2006 at 08:24:26AM -0400, Talpey, Thomas wrote:
> At 03:39 AM 8/26/2006, Gleb Natapov wrote:
> >On Fri, Aug 25, 2006 at 03:53:12PM -0400, Talpey, Thomas wrote:
> >> Flush (sync for_device) before posting.
> >> Invalidate (sync for_cpu) before processing.
> >>
> >So, before touching
At 03:39 AM 8/26/2006, Gleb Natapov wrote:
>On Fri, Aug 25, 2006 at 03:53:12PM -0400, Talpey, Thomas wrote:
>> Flush (sync for_device) before posting.
>> Invalidate (sync for_cpu) before processing.
>>
>So, before touching the data that was RDMAed into the buffer application
>should cache invalida
I've observed the following oops with CMA
Unable to handle kernel NULL pointer dereference at RIP:
[] :rdma_cm:cma_detach_from_dev+0x1a/0x58
PGD 135abd067 PUD 133ed3067 PMD 0
Oops: 0002 [1] SMP
CPU 1
Modules linked in: ib_sdp rdma_cm ib_addr i2c_dev i2c_core ib_ipoib ib_mthca
ib_
Hi Hal.
I noticed that there are some unused defaults:
OSM_DEFAULT_MGRP_MTU and OSM_DEFAULT_MGRP_RATE.
The corresponding values in the code are hadcoded.
Fixed the code to use these defaults, and updated the
OSM_DEFAULT_MGRP_MTU to the value that was hardcoded.
Yevgeny
Signed-off-by: Yevgen
On Mon, Aug 28, 2006 at 12:18:49AM -0600, Jason Gunthorpe wrote:
> On Sun, Aug 27, 2006 at 03:30:56PM -0700, Roland Dreier wrote:
> > glebn> So, before touching the data that was RDMAed into the
> > glebn> buffer application should cache invalidate the buffer, is
> > glebn> this even po
On Sun, Aug 27, 2006 at 03:30:56PM -0700, Roland Dreier wrote:
> glebn> So, before touching the data that was RDMAed into the
> glebn> buffer application should cache invalidate the buffer, is
> glebn> this even possible from user space? (Not on x86, but it
> glebn> isn't needed the
J> Why not copy what most ethernet drivers do and just log a message on
> link negotiation state changes? ie like the:
>
> eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
>
> Maybe something like:
>
> ib0: link up, 10Gbps, port active, lid 0x10/16
That's a neat idea.
__
62 matches
Mail list logo
