http://openib.org/bugzilla/show_bug.cgi?id=17
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #2 from [EMAIL
http://openib.org/bugzilla/show_bug.cgi?id=12
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #2 from [EMAIL
http://openib.org/bugzilla/show_bug.cgi?id=11
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #3 from [EMAIL
http://openib.org/bugzilla/show_bug.cgi?id=8
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #3 from [EMAIL P
http://openib.org/bugzilla/show_bug.cgi?id=10
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #2 from [EMAIL
http://openib.org/bugzilla/show_bug.cgi?id=9
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #2 from [EMAIL P
Due to unfortunate timing, the ipath driver in OFED 1.0-rc6 does not
work correctly. You can download an updated tarball from here, for
which the ipath driver works fine:
http://openib.red-bean.com/OFED-1.0-rc6+ipath.tar.bz2
Alternatively, pull the necessary patches from SVN.
http://ope
Betzy wrote,
>Woody - The short answer is yes - Bryan has created patches in
>the subversion tree, which will install on top of what Tziporet
>pulled from Roland's tree. These will be in the 1.0 release (and,
>we will be testing an early version of that on Monday). We've
>tested the ipath driver c
Woody - The short answer is yes - Bryan has created patches in
the subversion tree, which will install on top of what Tziporet
pulled from Roland's tree. These will be in the 1.0 release (and,
we will be testing an early version of that on Monday). We've
tested the ipath driver code pretty thorough
James,
I cleaned up the connection error events to report the proper events during
address resolution
errors and timeouts. It was returning incorrect DAT event codes.
-arlin
Signed-off by: Arlin Davis <[EMAIL PROTECTED]>
Index: dapl_ib_cm.c
===
Sean Hefty wrote:
> This patch series enhances support for joining and leaving multicast groups,
> providing the following functionality:
>
> 1. Users identify a multicast group by a multicast IP address.
> 2. A user binds to a local RDMA device based on resolving the IP address.
> 3. A new multic
Expose multicast abstraction through the CMA to userspace.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
--- svn3/gen2/trunk/src/linux-kernel/infiniband/include/rdma/rdma_user_cm.h
2006-06-06 16:53:46.0 -0700
+++ svn/gen2/trunk/src/linux-kernel/infiniband/include/rdma/rdma_user_cm
Add IB multicast abstraction to the CMA.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
--- svn3/gen2/trunk/src/linux-kernel/infiniband/include/rdma/rdma_cm.h
2006-06-06 16:53:56.0 -0700
+++ svn/gen2/trunk/src/linux-kernel/infiniband/include/rdma/rdma_cm.h
2006-06-02 10:22:29.0
On Fri, 9 Jun 2006, Arlin Davis wrote:
> James Lentini wrote:
>
> > On Thu, 8 Jun 2006, Jack Morgenstein wrote:
> >
> >
> > > On Wednesday 07 June 2006 18:26, James Lentini wrote:
> > >
> > > > On Wed, 7 Jun 2006, Jack Morgenstein wrote:
> > > >
> > > > > This (bug fix) can still b
On Fri, 2006-06-09 at 17:18, Sean Hefty wrote:
> Hal Rosenstock wrote:
> > What does mesh mean in this instance ? How do you know the multicast
> > routing tables are indeed valid and that the SM didn't corrupt them ?
> > (Why did the SM need restarting ?)
>
> I meant that the values agree with ea
James Lentini wrote:
>On Thu, 8 Jun 2006, Jack Morgenstein wrote:
>
>
>
>>On Wednesday 07 June 2006 18:26, James Lentini wrote:
>>
>>
>>>On Wed, 7 Jun 2006, Jack Morgenstein wrote:
>>>
>>>
This (bug fix) can still be included in next-week's release, if you
think it is important
Export a call to initialize an ib_ah_attr structure based on an
MCMemberRecord returned from a multicast join request.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
--- svn3/gen2/trunk/src/linux-kernel/infiniband/include/rdma/ib_sa.h
2006-06-06 15:21:05.0 -0700
+++ svn/gen2/trunk/s
Add an API to allow retrieving an MCMemberRecord from the local cache
based on an MGID.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
This allows an existing MCMemberRecord to be used as a template for
creating other multicast groups.
--- svn3/gen2/trunk/src/linux-kernel/infiniband/include/rd
Extract the MGID used by ipoib for broadcast traffic from the device
address.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
This will be used to get the MCMemberRecord for the ipoib broadcast group.
--- svn3/gen2/trunk/src/linux-kernel/infiniband/include/rdma/ib_addr.h
2006-05-25 11:18:47.0
This patch series enhances support for joining and leaving multicast groups,
providing the following functionality:
1. Users identify a multicast group by a multicast IP address.
2. A user binds to a local RDMA device based on resolving the IP address.
3. A new multicast group is created. The par
Hal Rosenstock wrote:
> What does mesh mean in this instance ? How do you know the multicast
> routing tables are indeed valid and that the SM didn't corrupt them ?
> (Why did the SM need restarting ?)
I meant that the values agree with each other, and there are no conflicts.
> The MLID is suppli
On Fri, 2006-06-09 at 16:35, Sean Hefty wrote:
> Hal Rosenstock wrote:
> > The other issue is whether you trust the state of the network or not
> > when the SM comes up. That's sometimes a dangerous proposition.
>
> I considered this, but I think there's a difference between trusting one of
> the
http://openib.org/bugzilla/show_bug.cgi?id=122
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- You are receiving
http://openib.org/bugzilla/show_bug.cgi?id=126
Summary: RDMA_CM and UCM not loaded on boot
Product: OpenFabrics Linux
Version: 1.0rc6
Platform: Other
OS/Version: Other
Status: NEW
Severity: normal
Priority: P2
Hal Rosenstock wrote:
The other issue is whether you trust the state of the network or not
when the SM comes up. That's sometimes a dangerous proposition.
I considered this, but I think there's a difference between trusting one of the
systems on the network, versus the network as a whole. For
Is there any plan to release an RC6 package (or an RC7)
that has a Pathscale driver that
compiles on RHEL4 - U3 that we can test before the release
?
woody
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tziporet
KorenSent: Wednesday, June 07, 2006 7:59 AMTo: Tziporet
K
On Fri, 2006-06-09 at 12:46, Sean Hefty wrote:
> Hal Rosenstock wrote:
> > Note the MGRPs are MGIDs and switches are programmed with MLIDs and
> > these can be 1:1 or many:1 depending on the implementation. Most do not
> > do the many:1 but this is allowed by the spec. Also, note that switches
> >
Well it's almost a puzzle at this point. just hard coding 10 with a
comment is probably easier to read. But ... for the curious, this will
do what you want ... but may cause you to lose your breakfast.
#define _stringify( _x ) # _x
#define stringify( _x ) _stringify( _x )
Then
printf("
Scott Weitzenkamp (sweitzen) wrote:
While we're talking about MTUs, is the IB MTU tunable in uDAPL and/or
Intel MPI via env var or config file?
Looks like Intel MPI 2.0.1 uses 2K for IB MTU like MVAPICH does in
OFED 1.0 rc4 and rc6, I'd like to try 1K with Intel MPI.
Scott
There is no me
Sean Hefty wrote:
Ipoib already checks for events that require rejoining multicast groups.
We just need to add code to handle (i.e. ignore) multicast group reset
notifications.
Roland,
Any issue committing this?
- Sean
___
openib-general mailing li
Michael S. Tsirkin wrote:
These should eliminate any races with ipoib leaving,
then quickly re-joining a group as a result of an event.
Is there a chance this will fix the crashes me and Or were seeing?
It shouldn't. The race that I was referring to only involved whether or not a
MAD is sen
While we're talking about MTUs, is the IB MTU tunable
in uDAPL and/or Intel MPI via env var or config file?
Looks like Intel MPI 2.0.1 uses 2K for IB MTU like
MVAPICH does in OFED 1.0 rc4 and rc6, I'd like to try 1K with Intel
MPI.
Scott
From: [EMAIL PROTECTED]
[mailto:[EMAIL
Hal Rosenstock wrote:
Note the MGRPs are MGIDs and switches are programmed with MLIDs and
these can be 1:1 or many:1 depending on the implementation. Most do not
do the many:1 but this is allowed by the spec. Also, note that switches
know nothing about the groups themselves (only MLIDs and which
ibnetdiscover: Indicate SP0 type
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
Index: diags/src/ibnetdiscover.c
===
--- diags/src/ibnetdiscover.c (revision 7842)
+++ diags/src/ibnetdiscover.c (working copy)
@@ -126,7 +126,9 @
ibnetdiscover: Add LMC display to switch port 0
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
Index: src/ibnetdiscover.c
===
--- src/ibnetdiscover.c (revision 7841)
+++ src/ibnetdiscover.c (working copy)
@@ -158,6 +158,7 @@ get_n
Whether iWARP or IB, there is a fixed number of RDMA Requests allowed to
be outstanding at any given time. If one posts more RDMA Read
requests than the fixed number, the transmit queue is stalled. This
is documented in both technology specifications. It is something
that all ULP should be aw
On Fri, 2006-06-09 at 06:43, Hal Rosenstock wrote:
> On Thu, 2006-06-08 at 18:00, Sean Hefty wrote:
> > Hal Rosenstock wrote:
> > > 2. There is lazy deletion of MC groups allowed so the reclamation may be
> > > difficult.
> >
> > I'm not familiar with the switch programming.
>
> Note the MGRPs ar
osmtest: Support LMC > 0
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
Index: osmtest/osmtest.c
===
--- osmtest/osmtest.c (revision 7839)
+++ osmtest/osmtest.c (working copy)
@@ -1609,6 +1609,74 @@ osmtest_stress_port_recs_sm
On Fri, 2006-06-09 at 00:38, Sean Hefty wrote:
> Modify ib_multicast module to detect events that require clients to rejoin
> multicast groups. Add tracking of clients which are members of any groups,
> and provide notification to those clients when such an event occurs.
>
> This patch tracks all
ibroute: When multiple paths, indicate port GUID on alternate paths
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
Index: diags/src/ibroute.c
===
--- diags/src/ibroute.c (revision 7646)
+++ diags/src/ibroute.c (working copy)
@@ -2
Hi,
Here is some info:
Attached are
the SysRq messages.
The relation
of MADs to ARP is that after ARP resolves a hardware address it is
required to use an SM query to resolve the path to the host bearing the
hardware address.
How to invoke
the tests: Attached
On Thu, 2006-06-08 at 18:00, Sean Hefty wrote:
> Hal Rosenstock wrote:
> > 2. There is lazy deletion of MC groups allowed so the reclamation may be
> > difficult.
>
> I'm not familiar with the switch programming.
Note the MGRPs are MGIDs and switches are programmed with MLIDs and
these can be 1:1
I find the following helpful for debug. Pls consider for 2.6.18
--
While IP spec does not require opcode to be valid in error CQEs, Mellanox HCAs
differentiate between send/receive errors, which is useful for debugging
purposes.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Index: last_
Pradipta Kumar Banerjee wrote:
rping didn't checked correctly for the minimum size of the ping
buffer resulting in the following error from glibc
"*** glibc detected *** free(): invalid next size (fast)"
Signed-off-by: Pradipta Kumar Banerjee <[EMAIL PROTECTED]>
---
Index: rping.c
44 matches
Mail list logo
