Title: when executing sminfo with a port in down state, there is a return value 0
Hi.
I'm working with gen2 svn rev. 3155 with 2 Mellanox HCAs (23108) (1 on each host; they are connected b2b: port 1 to port 1).
I executed opensm on host 1, port 1.
When i executed sminfo on host 2 port 1 eve
Title: RE: executing the ibv_srq_pingpong with many QPs sometimes causes to a test failure
>
> Thanks, I'll try to track this down. Can you get a backtrace of the
> seg fault to see where it is?
>
> - R.
>
Hi.
Here is a backtrace of the seg fault:
Loaded symbols for //usr/local/lib
On Mon, Aug 22, 2005 at 01:22:55PM +0300, Dan Bar Dov wrote:
> We have begun a cleanup of ISER based on the inputs we received.
> Mostly cosmetic cleanups were already commited.
yup - good progress and some more cosmetic stuff noted below.
Then need to start looking at addressing Christoph's (hch)
On Aug 22, 2005, at 7:17 AM, Michael S. Tsirkin wrote:
The following is not yet applied. Opinions on othis?
Is there a reason to do this? Other than just to have smaller
functions. Not that it is a bad thing, just wanted to know if you
plan on reusing the smaller subroutines elsewhere.
If your EVD typically has hundreds of entries, let alone
thousands, then you should be notification driven. You
should be time-driven and simply use evd_dequeue().
The whole point of having control of notifications is to
ensure that upcalls are used to wake up the consumer.
If there is no need to
Roland Dreier wrote:
Sean> I think that the issue that Arlin is hitting is that once he
Sean> calls blah_get_event() he doesn't have an easy way to
Sean> release the thread. This may turn out to be a uCM / uAT
Sean> issue, and not a verbs issue.
I thought about this some
Thanks Micheal.
Can I confirm that no memory beyond that specified in the WR for the
Send op is not actually written to.
The reason I'm interested in this is that I'm thinking about
registering a large Memory Region to receive lots of smaller data
messages. This is to avoid the overhead of re
Sean Hefty wrote:
The RMPP code returns the size of the receive as sizeof MAD header + sizeof RMPP
header + optional sizeof other header (e.g. SA header) + actual payload. This
size can be used to allocate a data buffer large enough to hold the reassembled
MAD. You should be able to use this
Sean> I think that the issue that Arlin is hitting is that once he
Sean> calls blah_get_event() he doesn't have an easy way to
Sean> release the thread. This may turn out to be a uCM / uAT
Sean> issue, and not a verbs issue.
I thought about this some more. I think the real issue i
On Aug 22, 2005, at 8:47 AM, Michael S. Tsirkin wrote:
Hi!
I was getting the following oopsen in sdp_link.c
I plan to commit the fix (below) tomorrow, after some more testing.
Comments?
Yeah, looks good. This is why people hate goto's.
-tduffy
>The number of records is an SA thing and not RMPP thing. This is transparent to
>RMPP itself.
>
>The need to determine the number of records is a consumer issue (SA or SA
>client). To do this, AttributeOffset and (at least the last) PayloadLength
>field is needed (as one can't rely on the first Pa
One cant currently build opensm if one does not have
management libraries checked out in the same directory.
The reason is that management libs are installed in
/usr/local/include/infiniband now.
The following patch applies to Yael's branch as well.
---
Fix opensm to include files from include/i
Dotan> When I'm executing the ibv_srq_pingpong with many QPs(255)
Dotan> each executable is a different HCA (on different node)
Dotan> there is a completion with error in the server side and a
Dotan> seg fault in the client side.
Thanks, I'll try to track this down. Can you get a
Hi!
I was getting the following oopsen in sdp_link.c
I plan to commit the fix (below) tomorrow, after some more testing.
Comments?
Unable to handle kernel NULL pointer dereference at 0090 RIP:
{arp_send+4}
PGD 17c8f4067 PUD 17cfa3067 PMD 0
Oops: [1] SMP
CPU 0
Modules linked in: i
Hi Steve,
Quoting r. Steve Wooding <[EMAIL PROTECTED]>:
> I was wondering what happens if the message being received (for a Send
> operation) is larger than the length of the recieve buffer that was
> specified in the receive WR?
You'll get a completion with error when you poll the cq.
> Where is
Hi,
I was wondering what happens if the message being received (for a Send
operation) is larger than the length of the recieve buffer that was
specified in the receive WR? Where is this error caught? Is is the same
for an RDMA Write?
Thanks,
Steve.
__
Hal Rosenstock wrote:
Hi again Eitan,
The transparency to the RMPP is an RMPP implementation choice.
Having incorrect paylen in the first segment is a compliancy violation.
It should be either 0 or correct value.
Yes, is that what is going on ? I haven't had a chance to look at the GIF yo
The following is not yet applied. Opinions on othis?
---
Split the sdp_inet_send to smaller subroutines.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Index: linux-2.6.12.2/drivers/infiniband/ulp/sdp/sdp_send.c
===
--- linu
Hi again Eitan,
> The transparency to the RMPP is an RMPP implementation choice.
> Having incorrect paylen in the first segment is a compliancy violation.
> It should be either 0 or correct value.
Yes, is that what is going on ? I haven't had a chance to look at the GIF you
sent
and analyze it
Hal Rosenstock wrote:
The number of records is an SA thing and not RMPP thing. This is
transparent to RMPP itself.
The transparency to the RMPP is an RMPP implementation choice.
Having incorrect paylen in the first segment is a compliancy violation.
It should be either 0 or correct value.
T
Hi Eitan,
>I hope you will be able to collect valuable inputs to the OpenSM
TODO.
I hope so too (but there already is more than enough to do here).
> Also Yael has posted the branch with the merge of the 1.8.0 to the
> current trunk.
Yes, I saw this.
> It might be worthwhile to try mergin
At 11:11 AM 8/19/2005, Roland Dreier wrote:
Arlin>
Yes, this is certainly another option; albeit one that
Arlin> requires more system resources. Why not take
full advantage
Arlin> of the FD resource we already have? It's
your call, but
Arlin> uDAPL and other multi-thread applicati
Hal Rosenstock wrote:
I will deal with the osm_vendor_umad patches later in the week upon
return from the OpenIB workshop.
Thanks I will be waiting patiently. I wish I could come to the workshop
too. I hope you will be able to collect valuable inputs to the OpenSM
TODO.
I believe there are 3
Hi Eitan,
I will deal with the osm_vendor_umad patches later in the week upon return from
the OpenIB workshop. I believe there are 3 patches currently outstanding.
-- Hal
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mai
Hi Eitan,
All Sean is saying is that the RMPP code itself only uses the last bit.
The number of records is an SA thing and not RMPP thing. This is transparent to
RMPP itself.
The need to determine the number of records is a consumer issue (SA or SA
client). To do this, AttributeOffset and
Hi Yael,
I will start the merge of this back to the trunk later in the week when I
return from the OpenIB workshop and IDF. I also have some other patches and
issues to investigate queued up.
-- Hal
___
openib-general mailing list
openib-general@o
Title: OpenSM: new branch
Hello all,
I have created a new branch for the osm under: https://openib.org/svn/gen2/branches/osm-1.8.0-merge/
This branch includes the merging between the gen2 OpenSM code and the
gen1 1.8.0 Mellanox version of OpenSM.
You are all welcome to try the new OpenSM ver
We have begun a cleanup of ISER based on the inputs we received.
Mostly cosmetic cleanups were already commited.
These include:
C++ style comments changed to C
Removed DAT 1.2 comments
Reomoved DAT 1.2 API support file
Removed all platform dependencies
Removed vi comments
Removed CONFIG_INFINIBAND
28 matches
Mail list logo
