Michael> What specifically would you like to know?
What kind of CPU, motherboard, PCI host bridge, etc.
"lspci -vvv" output would be interesting. Maybe /proc/cpuinfo too.
- R.
___
openib-general mailing list
openib-general@openib.org
http://openi
Ranjit> Commenting out call to mthca_reset() in mthca_main.c
Ranjit> worked around the problem on my system, and as far as I
Ranjit> can tell, did not have any negative impact.
Yes, that should work fine in most cases. The reset is done to get
the HCA into a known state, since it migh
On Tue, 2006-02-07 at 09:29 -0800, Roland Dreier wrote:
> Thanks, I broke this when I merged Or's FMR patch.
> I checked in this fix:
>
> --- infiniband/hw/ipath/ipath_verbs.c (revision 5330)
> +++ infiniband/hw/ipath/ipath_verbs.c (working copy)
> @@ -5756,7 +5756,7 @@ static struct ib_fmr *ipath
>-static inline u64 get_seg_addr(struct ib_mad_send_wr_private *mad_send_wr)
>+static inline void *get_seg_addr(struct ib_mad_send_wr_private *mad_send_wr)
> {
>- return mad_send_wr->sg_list[0].addr + mad_send_wr->data_offset +
>- (sizeof(struct ib_rmpp_mad) - mad_send_wr->data_off
Hi Everyone,
Now I am using OpenIB Gen2 on SuSE10. I got a strange problem when I
tried to bring up/down ib interface, I put the ib interface startup
script ifcfg-ib0/ifcfg-ib1 under /etc/sysconfig/network directory, when
I use the command 'ifdown ib0', and from the message shown, it will pick
up
>+static int data_offset(u8 mgmt_class)
>+{
>+ if (mgmt_class == IB_MGMT_CLASS_SUBN_ADM)
>+ return IB_MGMT_SA_HDR;
>+ else if ((mgmt_class >= IB_MGMT_CLASS_VENDOR_RANGE2_START) &&
>+ (mgmt_class <= IB_MGMT_CLASS_VENDOR_RANGE2_END))
>+ return IB_MGMT
Based on what you've done, I'd like to suggest changing interface similar to
that shown below. I believe that this could be done with minor changes to the
current patches. Detailed comments that led to suggesting this change are
inline in my responses.
struct ib_mad_segments {
u32
Anyway, I've (finally) applied this patch.
- 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
[EMAIL PROTECTED] wrote:
> We have problem no matter which option we choose.
> The current Transport Level Requirement state:
>
> There is a one-to-one correspondence between send operation
> on one Endpoint of the Connection and recv operations on the
> other Endpoint of the Connection.
> There i
We have problem no matter which option we choose.
The current Transport Level Requirement state:
There is a one-to-one correspondence between send operation on one
Endpoint of the Connection and recv operations on the other Endpoint of
the Connection.
There is no correspondence between RDMA operat
What specifically would you like to know?
On 2/7/06, Roland Dreier <[EMAIL PROTECTED]> wrote:
> > Feb 7 16:59:48 linux14-ts kernel: ib_mthca :07:00.0: PCI device did
> > not come back after reset, aborting.
>
> Can you give more details on the system where you saw this?
>
> - R.
>
_
> Feb 7 16:59:48 linux14-ts kernel: ib_mthca :07:00.0: PCI device did not
> come back after reset, aborting.
Can you give more details on the system where you saw this?
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.
[EMAIL PROTECTED] wrote:
>
> I was under the assumption that the DAT community defined the
> APIs and semantics through an open process. Given that the
> IB write immediate data facility does not break the
> implementation or semantics of the currently defined RDMA
> write facility, I see no rea
>>> Completing a transaction, complete with supplying a transaction
>>> response and releasing the advertised STag associated with the
>>> transaction is something that makes sense in the application domain
>>> and conforms to normal DAT ordering rules.
>>>
>>
>> I don't disagree. And unambiguous
Michael,
I have seen this problem before..
See following mail thread
http://www.mail-archive.com/openib-general@openib.org/msg13861.html
Commenting out call to mthca_reset() in mthca_main.c worked around the
problem on my system, and as far as I can tell, did not have any
negative impact.
It wi
Larsen, Roy K wrote:
>
>> Completing a transaction, complete with supplying a transaction
>> response and releasing the advertised STag associated with the
>> transaction is something that makes sense in the application domain
>> and conforms to normal DAT ordering rules.
>>
>
> I don't disagre
I'm trying to build a system using the openib drivers with a mellanox
hca card. I don't have much information about the card itself, it's
in a server right now...
But I downloaded openib today from the svn source, installed it onto a
fresh copy of Fedora Core 4 with Kernel version 2.6.15.3...
Ev
>>> What is proposed in a definition of
>>> 'dat_ep_post_rdma_write_with_immediate'
>>> that can be implemented over iWARP using the sequence of messages
>>> that were intended to support the same purpose (i.e., letting the
>>> other side know that an RDMA Write transfer has been fully
received).
>
>IB does optionally support send_with_invalidate as defined in IBTA 1.2
>spec.
>OpenIB does not support this yet but this is a different matter.
>So this is bad analogy.
>
>The better analogy is socket based CM.
>
>But I am still not clear what you are advocating:
>extensions, IB specific API or so
[EMAIL PROTECTED] wrote:
> Caitlin Bestler wrote:
>>
>> Arlin Davis wrote:
>>> Sean Hefty wrote:
>>>
> The requirement is to provide an API that supports RDMA writes
> with immediate data. A send that follows an RDMA write is not
> immediate data, and the API should not be constructe
IB does optionally support send_with_invalidate as defined in IBTA 1.2
spec.
OpenIB does not support this yet but this is a different matter.
So this is bad analogy.
The better analogy is socket based CM.
But I am still not clear what you are advocating:
extensions, IB specific API or something
Caitlin Bestler wrote:
>
>Arlin Davis wrote:
>> Sean Hefty wrote:
>>
The requirement is to provide an API that supports RDMA writes with
immediate data. A send that follows an RDMA write is not immediate
data, and the API should not be constructed around trying to make
it so.
>
> +rmpp_mad = (struct ib_rmpp_mad *)seg_buf->mad;
Trivial, but I prefer a space after cast operators.
> +static struct ib_umad_packet *alloc_packet(void)
> +{
> +struct ib_umad_packet *packet;
> +int length = sizeof *packet + sizeof(struct ib_mad);
> +
> +packet = k
Arlin Davis wrote:
> Sean Hefty wrote:
>
>>> The requirement is to provide an API that supports RDMA writes with
>>> immediate data. A send that follows an RDMA write is not immediate
>>> data, and the API should not be constructed around trying to make
>>> it so.
>>>
>>>
>>
>> To be clear, I
Sean Hefty wrote:
The requirement is to provide an API that supports RDMA writes with immediate
data. A send that follows an RDMA write is not immediate data, and the API
should not be constructed around trying to make it so.
To be clear, I believe that write with immediate should be par
All 3 options: proposed APIs, extensions, or IB semantic API
all provide the same performance benefit on IB.
But the last option is the easiest to use.
Arkady Kanevsky email: [EMAIL PROTECTED]
Network Appliance Inc. phone: 781-768-5395
1601 Trapelo Rd. - Suite 1
On Tue, 2006-02-07 at 09:29 -0800, Roland Dreier wrote:
> Thanks, I broke this when I merged Or's FMR patch.
Thanks.
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Thanks, I broke this when I merged Or's FMR patch.
I checked in this fix:
--- infiniband/hw/ipath/ipath_verbs.c (revision 5330)
+++ infiniband/hw/ipath/ipath_verbs.c (working copy)
@@ -5756,7 +5756,7 @@ static struct ib_fmr *ipath_alloc_fmr(st
fmr->mr.offset = 0;
fmr->mr.access
On Tue, 2006-02-07 at 09:07 -0800, Woodruff, Robert J wrote:
> I get the following build error when compiling
> SVN5330.
We'll commit a fix later today. Robert is in Sonoma at the OpenIB
workshop, and he's our svn committer, so it might take a little while.
Thanks for pointing this out.
I get the following build error when compiling
SVN5330.
CC [M] drivers/infiniband/hw/ipath/ipath_verbs.o
drivers/infiniband/hw/ipath/ipath_verbs.c: In function
`ipath_alloc_fmr':
drivers/infiniband/hw/ipath/ipath_verbs.c:5759: error: structure has no
member named `page_size'
make[3]: *** [driver
Hi Steve,
This looks similar to the ibping problem. Could you update libibcommon.map and
rebuild libibcommon ?
Thanks.
-- Hal
From: [EMAIL PROTECTED] on behalf of Steve Wise
Sent: Tue 2/7/2006 11:01 AM
To: openib-general
Subject: [openib-general] ibstat pro
Sean Hefty wrote:
>> And further it is only on the receiving side.
>> And only if the receiving side cares about the data
>> (sometimes it only needs the notification).
>
> The send size cares about this check because it must size its SQ
> appropriately. I disagree with the
>Why would any Consumer hook itself on "proprietary" features and
>APIs is a different question.
Because it provides a real performance benefit. This is the same reason apps
code to DAPL versus standard sockets.
- Sean
___
openib-general mailing list
>Large RMPP support: changes/additions to underlying data structures and
>prototypes.
Thanks. I'm at the OpenIB conference currently, but should be able to review
this by the end of the week.
- Sean
___
openib-general mailing list
openib-general@openi
Anyone see this before?
-
vic17:~ # ibstat
ibstat: relocation error: ibstat: symbol argv0, version IBCOMMON_1.0 not
defined in file libibcommon.so.1 with link time reference
vic17:~ # uname -a
Linux vic17 2.6.15.2-kdb #4 SMP PREEMPT Mon Feb 6 17:24:41 CST 2006 i686
i686 i386 GNU/Linux
vic17:~
But each of the multiple work requests follow the semantic of single
completion per work request. It can be controlled by completion_flags
but it still not a semantic of a "single" post.
Arkady Kanevsky email: [EMAIL PROTECTED]
Network Appliance Inc. phone: 781-
It is much simplier to handle immediate data as DAT extension.
Spec changes are minimal. One extra field for DTO completion and for
DAT_DTOS. One fix in redirection.
The rest is up to a provider to define in dat_providername_extensions.
How each provider defines analogous features are outside the
> And further it is only on the receiving side.
> And only if the receiving side cares about the data
> (sometimes it only needs the notification).
The send size cares about this check because it must size its SQ appropriately.
I disagree with the assumption that a "trans
Sean Hefty wrote:
>> I am not clear what you are proposing?
>> A transport specific API?
>>
>> The current proposal provides on sending side:
>> single post, and single completion in the error free case.
>> This is commonality that simplify ULP.
>
> App 1 - transport aware:
>
> if (transport ==
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: ipoib_mcast_send.patch
>
> Michael> I agree. Do you want to fix it or should I?
>
> If you get a chance that would be great. I'm at the OpenIB workshop
> now so I probably can't seriously look at it until tomorrow at the
> earliest
Michael> I agree. Do you want to fix it or should I?
If you get a chance that would be great. I'm at the OpenIB workshop
now so I probably can't seriously look at it until tomorrow at the
earliest.
- R.
___
openib-general mailing list
openib-gener
bugfix for connect error flow when getting RDMA_CM_EVENT_ADDR_ERROR
Signed-off-by: Or Gerlitz <[EMAIL PROTECTED]>
Index: iser_verbs.c
===
--- iser_verbs.c(revision 5329)
+++ iser_verbs.c(revision 5330)
@@ -626,7 +626,
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: mthca: gid index bug?
>
> > Roland, in mthca_qp.c we have
> >
> > path->mgid_index = ah->grh.sgid_index;
> >
> > Shouldnt the port number be taken into account, like it
> > is with mthca_av, where we have
> > av-
r5329 | ogerlitz | 2006-02-07 11:01:04 +0200 (Tue, 07 Feb 2006) | 5 lines
refined conn term flow, removed two cases from iser_conn_sync_terminate,
made iser_complete_conn_termination and iser_conn_async_terminate void
Signed
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Related to this, the way priv->broadcast is initialized
> in ipoib_mcast_join_task() looks somewhat unsafe, since there's no
> lock and conceivable a send-only join could complete before
> priv->broadcast is fully set up. What do you think?
I agree.
Hi Hal,
The following patch includes some fixes for the windows stack:
1. Add needed __cdecl.
2. Change the default directories/files names.
Thanks,
Yael
Signed-off-by: Yael Kalka <[EMAIL PROTECTED]>
Index: include/opensm/osm_base.h
Michael> But hopefully, not (yet) the svn tree - svn tree is
Michael> explicitly targeting the last stable kernel from
Michael> kernels.org?
Hmm, good point. I actually already reverted it in svn...
...but now I'm not sure it's worth worrying about. The only
problematic arch (x86_64
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: [git patch review 2/2] IB: Don't doublefree pages from
> scatterlist
>
> Hugh> It's now looking like this change won't be needed after all:
> Hugh> Andi has just posted a patch in the "ipr" thread which
> Hugh> should stop x
48 matches
Mail list logo
