This email was generated automatically, please do not reply
Common build parameters: --with-ipoib-mod --with-sdp-mod --with-srp-mod
--with-user_mad-mod --with-user_access-mod --with-mthca-mod --with-core-mod
--with-addr_trans-mod --with-cxgb3-mod
Passed:
Passed on i686 with 2.6.15-23-server
On Sun, 2007-02-11 at 13:44, Scott Weitzenkamp (sweitzen) wrote:
I'm using install.sh on RHEL4 U3 x86_64
Preparing...
##
kernel-ib-devel
##
kernel-ib
https://bugs.openfabrics.org/show_bug.cgi?id=351
Summary: Routing table problem in SLES10 when using port #2
Product: OpenFabrics Linux
Version: 1.2
Platform: All
OS/Version: SLES 10
Status: NEW
Severity: major
On Mon, 2007-02-12 at 06:36 -0500, Hal Rosenstock wrote:
On Sun, 2007-02-11 at 13:44, Scott Weitzenkamp (sweitzen) wrote:
I'm using install.sh on RHEL4 U3 x86_64
Preparing...
##
kernel-ib-devel
Hal:
Ref: comment on mad.c (ib_mad_recv_done_handler().
Even if I make the relevant changes to smi.c functions how do I get the
packet to get forwarded, without making additional changes in this
function?
Meaning, when smi_handle_dr_smp_send(),smi_check_forward_dr_smp() are
called
BTW: We need this for the alpha1 build or DAPL applications won't work
over iWARP devices.
Steve.
On Sun, 2007-02-11 at 13:58 -0600, Steve WIse wrote:
IWCM - Set initiator depth and responder resources to device max values.
For OFED 1.2, the IWCM will set the initiator depth and responder
1. process A and process B is connected with QP. A first
post a send
to B, B does not post receive. Then A and B are doing a long time
RDMA_WRITE each other, A and B just check memory for the RDMA_WRITE
message. Finally B will post a receive. Does the first
pending send in
A
On Mon, 2007-02-12 at 08:19 -0800, Sean Hefty wrote:
This design is based on the RDMA_CM and IB_CM behavior. If the app
issues the destroy via rdma_destroy_cm_id, then we block that thread
until all references are gone. If the app returns non-zero in a
callback for a given cm_id, then
Hi,
after building the latest ofed build package we recognized that on PPC64 only
64-bit libaries were build.
Because we have customers using older userpace apllications which are
certified for 32-bit we think additional 32bit support is a requirement for
64bit builds.
If OFED 1.2 supports 32
This is the full OFED 1.2 components list that we will review in the meeting
Tziporet
# Kernel
ib_verbs (core)
ib_mthca
ib_ipoib
ib_ipath - currently works on 2.6.20 only. Backport patches cannot applied
ib_iser
ib_sdp
ib_srp
ib_ehca - PPC only
cxgb3
vnic
rds - currently works on kernel 2.6.20
On Mon, 2007-02-12 at 11:42, Tziporet Koren wrote:
This is the full OFED 1.2 components list that we will review in the meeting
Tziporet
# Kernel
ib_verbs (core)
ib_mthca
ib_ipoib
ib_ipath - currently works on 2.6.20 only. Backport patches cannot applied
ib_iser
ib_sdp
ib_srp
I only backported to RHEL4U4 since that was the supported platform.
Is OFED 1.2 supporting U3 too?
I can add the backport if needed.
On Mon, 2007-02-12 at 18:06 +0200, Vladimir Sokolovsky wrote:
Hi Steve,
I got the following compilation failure on RHEL4.0U3 (2.6.9-34.ELsmp):
gcc
Ah, I think I missed the key step in your scheme.. You plan to query
the local SM for SGID=remote DGID=local? (ie reversed from 'normal'. I
was thinking only about the SGID=local DGID=remote query direction)
I'm not sure that the query needs the GIDs reversed, as long as the path is
BTW.
Is the ibdiagui code going to be part of this release.
I did not see it in the list below or is it just part of
the openib-diags ?
I thought that we discussed this as an OFED 1.2 feature.
I have someone that is interested in trying it out.
woody
-Original Message-
From: [EMAIL
On Mon, 2007-02-12 at 19:56 +0200, Vladimir Sokolovsky wrote:
On Mon, 2007-02-12 at 10:55 -0600, Steve Wise wrote:
I only backported to RHEL4U4 since that was the supported platform.
Is OFED 1.2 supporting U3 too?
I can add the backport if needed.
RHEL4U3 is not officially
From: Sean Hefty
Sent: Monday, February 12, 2007 12:23 PM
To: Jason Gunthorpe; Hal Rosenstock
Cc: openib-general@openib.org
Subject: Re: [openib-general] Problem is routing CM REQ
There has been a lot of good discussion and proposed designs for this
solution. I think it would be very helpful
Good day
Todays market started and we have the latest news for investors:
MHII at OBB
Last: 0.02
We know that you have a stake in fresh and live data only.The effectiveness of
your and our work depends on truthful information and live data. That is why we
offer you only online news which is
Thanks, applied as 2 separate patches.
___
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
On Mon, 2007-02-12 at 12:58, Woodruff, Robert J wrote:
BTW.
Is the ibdiagui code going to be part of this release.
I did not see it in the list below or is it just part of
the openib-diags ?
It's part of ibutils.
-- Hal
I thought that we discussed this as an OFED 1.2 feature.
I have
Roland, can you review this?
-
From: Steve Wise [EMAIL PROTECTED]
Currently iw_cxgb3 uses the physical address as the key/offset to return
to the user process for maping kernel memory into userspace. The user
process then calls mmap() using this key as the offset. Because the
physical
Looks mostly sane (assuming it works on 32-bit userspace on 64-bit
kernel now), but:
-context = kmalloc(sizeof(*context), GFP_KERNEL);
+context = kzalloc(sizeof(*context), GFP_KERNEL);
Why do you need this? Is this an unrelated change?
- R.
On Mon, 2007-02-12 at 11:58 -0800, Roland Dreier wrote:
Looks mostly sane (assuming it works on 32-bit userspace on 64-bit
kernel now), but:
- context = kmalloc(sizeof(*context), GFP_KERNEL);
+ context = kzalloc(sizeof(*context), GFP_KERNEL);
Why do you need this? Is this an
Because the key generator u32 is in the context now, and the kzalloc()
initializes it. I could have done:
context-key = 0;
But km - kz was less typing. ;-)
OK, got it. Anyway as I said, from a quick read the changes look
sane, with the assumption that they work.
On Mon, 2007-02-12 at 12:08 -0800, Roland Dreier wrote:
Because the key generator u32 is in the context now, and the kzalloc()
initializes it. I could have done:
context-key = 0;
But km - kz was less typing. ;-)
OK, got it. Anyway as I said, from a quick read the changes
Steve I tested and it works. Do you want to pull this in before
Steve you push the driver upstream? Do I need to repost it?
I'll grab it and merge it in. I expect to ask Linus to pull later
today.
- R.
___
openib-general mailing list
Actually, that patch doesn't apply because of the %llx warning fixes
I pushed out. And git-apply also complains about trailing
whitespace. Can you resend a version that applies to the my
for-2.6.21 branch?
Thanks
___
openib-general mailing list
+sg_set_buf(mem, buf, PAGE_SIZE order);
+BUG_ON(mem-offset);
+sg_dma_len(mem) = PAGE_SIZE order;
What am I missing? Any reason to set sg_dma_len() again after sg_set_buf()?
___
openib-general mailing list
openib-general@openib.org
On Mon, Feb 12, 2007 at 09:23:06AM -0800, Sean Hefty wrote:
Ah, I think I missed the key step in your scheme.. You plan to query
the local SM for SGID=remote DGID=local? (ie reversed from 'normal'. I
was thinking only about the SGID=local DGID=remote query direction)
I'm not sure that the
Steve Wise wrote:
Dunno if this has already been resolved?
Building the 20070208-1508 OFED 1.2 kit.
RHEL3U4 with that distro's kernel.
Ran build.sh and selected all.
ipath drive does not have any backport patch. I hope they will have some
today.
Tziporet
At 07:29 AM 2/9/2007, Kanevsky, Arkady wrote:
Mike,
this is not a DAPL issue.
There are 2 ways to deal with it.
One is for all ULPs to use private data to exchange CM info.
yes, some ULPs, like SDP do that in hello world message.
Another is to let CM handle it.
This way ULP does not have to deal
At 09:10 PM 2/11/2007, Devesh Sharma wrote:
On 2/10/07, Tang, Changqing [EMAIL PROTECTED] wrote:
Not for the receiver, but the sender will be severely slowed down by
having to wait for the RNR timeouts.
RNR = Receiver Not Ready so by definition, the data flow
isn't going to
progress
On Mon, 2007-02-12 at 12:23 -0800, Roland Dreier wrote:
Actually, that patch doesn't apply because of the %llx warning fixes
I pushed out. And git-apply also complains about trailing
whitespace. Can you resend a version that applies to the my
for-2.6.21 branch?
Thanks
Here it is...
Hal Rosenstock wrote:
On Mon, 2007-02-12 at 12:58, Woodruff, Robert J wrote:
BTW.
Is the ibdiagui code going to be part of this release.
I did not see it in the list below or is it just part of
the openib-diags ?
It's part of ibutils.
And already part of OFED 1.2
I thought
Suri,
On Mon, 2007-02-12 at 09:27, Suresh Shelvapille wrote:
Hal:
Ref: comment on mad.c (ib_mad_recv_done_handler().
Even if I make the relevant changes to smi.c functions how do I get the
packet to get forwarded, without making additional changes in this
function?
Meaning,
1) What does the TClass and FlowLabel returned from SGID=local
DGID=remote mean?
Do you use it in the Node1 - Node2 direction or the Node2 - Node1
direction
or both?
Maybe it would help if we can agree on a set of expectations. These are what I
am thinking:
1. An SA should be
Queued for 2.6.21, although I think a further cleanup would be:
mdev-mr_table.mpt_table = mthca_alloc_icm_table(mdev,
init_hca-mpt_base,
dev_lim-mpt_entry_sz,
I still get this error building on rhel5b2 with the latest from the ofa
git trees:
ERROR: The sysfsutils-devel package is required to build libibverbs_devel RPM
[EMAIL PROTECTED] OFED-1.2-stevo]# rpm -qa|grep sysfs
libsysfs-2.0.0-6
libsysfs-devel-2.0.0-6
libsysfs-2.0.0-6
sysfsutils-2.0.0-6
At 12:56 PM 2/12/2007, Jason Gunthorpe wrote:
On Mon, Feb 12, 2007 at 09:23:06AM -0800, Sean Hefty wrote:
Ah, I think I missed the key step in your scheme.. You plan to query
the local SM for SGID=remote DGID=local? (ie reversed from 'normal'. I
was thinking only about the SGID=local
Ok, I hacked around this by changing the build_env.sh.
But I think build_env.sh will have to distinguish between rhel5 and all
other redhat releases so it can correctly set the prerequisite rpms...
Steve.
On Mon, 2007-02-12 at 17:24 -0600, Steve Wise wrote:
I still get this error building
An endnode look up should be to find the address
vector to the remote. A look up may return multiple vectors. The
SLID would correspond to each local subnet router port that acts as a
first-hop destination to the remote subnet.I don't see why the
router protocol would not simply
At 02:47 PM 2/12/2007, Sean Hefty wrote:
1) What does the TClass and FlowLabel returned from SGID=local
DGID=remote mean?
Do you use it in the Node1 - Node2 direction or the Node2 - Node1
direction
or both?
Maybe it would help if we can agree on a set of expectations. These
On Mon, Feb 12, 2007 at 02:47:42PM -0800, Sean Hefty wrote:
Maybe it would help if we can agree on a set of expectations. These are
what I am thinking:
1. An SA should be able to respond to a valid PR query if at least one of
the GIDs in the path record is local.
2. The LIDs in a PR
On Mon, Feb 12, 2007 at 03:31:15PM -0800, Michael Krause wrote:
TClass is intended to communicate the end-to-end QoS desired. TClass is
then mapped to a SL that is local to each subnet. A flow label is
intended to much the same as in the IP world and is left, in essence, to
routers to
4. A PR from the local SA with reversible=1 indicates that data sent from
the remote GID to the local GID using the PR TC and FL will route locally
using the specified LID pair. This holds whether the PR SGID is local or
remote.
5. A PR from a remote SA with reversible=1 indicates that data
On Mon, Feb 12, 2007 at 04:45:33PM -0800, Sean Hefty wrote:
4. A PR from the local SA with reversible=1 indicates that data sent from
the remote GID to the local GID using the PR TC and FL will route locally
using the specified LID pair. This holds whether the PR SGID is local or
remote.
Steve,
I was doing random%5 == 0 or some such and failing in
iw_conn_req_handler(). There was
no other explicit test case other than running rdma_bw using this hack.
thanks,
- KK
Steve Wise [EMAIL PROTECTED] wrote on 02/10/2007 04:16:57 AM:
All 4 above cases were tested by injecting random
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 will add the new cxgb3 RDMA driver for Chelsio
Hi Steve,
Thanks for the explanation. I reviewed the patch and had two
comments :
1. When the set_bit(CALLBACK_DESTROY) was done, the
refcount could be such so that the free_cm_id is not called,
resulting in cm_id having work entries. But there are two
places where a
OK, I already merged this but now I'm thinking it's somewhat buggy:
+if (coherent)
+ret = mthca_alloc_icm_coherent(dev-pdev-dev,
+
chunk-mem[chunk-npages],
+
Tziporet Koren wrote:
This is the full OFED 1.2 components list that we will review in the meeting
Tziporet
# Kernel
ib_verbs (core)
ib_mthca
ib_ipoib
ib_ipath - currently works on 2.6.20 only. Backport patches cannot applied
ib_iser
ib_sdp
ib_srp
ib_ehca - PPC only
cxgb3
vnic
rds
[EMAIL PROTECTED] wrote:
This email was generated automatically, please do not reply
Common build parameters: --with-ipoib-mod --with-sdp-mod --with-srp-mod
--with-user_mad-mod --with-user_access-mod --with-mthca-mod --with-core-mod
--with-addr_trans-mod --with-cxgb3-mod
Vlad,
We
On Sat, 2007-02-10 at 14:25 -0500, Shaun Rowland wrote:
I updated the latest MVAPICH2 SRPM:
https://www.openfabrics.org/~rowland/ofed_1_2/
I am including a patch to the latest ofed_1_2_scripts git files. Since
these files are the same as those used in the OFED-1.2-20070208-1508.tgz
52 matches
Mail list logo
