Hello Troy,
On 29.04.2006, at 01:15, Troy Benjegerdes wrote:
So, how do I start debugging this?
ibv_devinfo reports the port as active.. what else would cause this?
(I am running the userspace modules from http://openib.red-bean.com/
rc2/SOURCES/ , and kernel 2.6.16.11)
[EMAIL PROTECTED] ne
On Fri, 2006-04-28 at 21:24 +0200, Or Gerlitz wrote:
> Yes, i can reproduce this at will, no local modifications, my system
> is amd dual x86_64, i have attached my .config to the first email of
> this thread, and also mentioned that some CONFIG_DEBUG_ options are
> set, including one related to sl
Hello,
On 28.04.2006, at 08:32, Pekka Enberg wrote:
The problem I see with pr_debug() is that it could only activated via
a compile flag. To use the debug outputs you have to re-compile /
compile your own kernel.
Do you really need this heavy debug logging in the first place? You
can use kpro
>You can't add this kind of thing piecemeal to a protocol and have it
>work. If the sender doesn't see a response (perhaps the response was
>lost, or was slow coming), and sends another MAD, this 2nd MAD will
>have a different sequence number. How does the recipient know it's the
If a MAD is sent
On Fri, Apr 28, 2006 at 03:20:13PM -0700, Sean Hefty wrote:
> I'd like to propose that the MAD layer detect duplicate requests.
Sean,
You can't add this kind of thing piecemeal to a protocol and have it
work. If the sender doesn't see a response (perhaps the response was
lost, or was slow coming
Hi,
I downloaded and
compiled the MVAPICH2 v0.9.3-RC0 using make.mvapich2.gen2 script. The
script finished without any errors. However, I received "mpdboot: error
while loading shared libraries: libibverbs.so.1: cannot open shared object file:
No such file or directory" error while execu
So, how do I start debugging this?
ibv_devinfo reports the port as active.. what else would cause this?
(I am running the userspace modules from
http://openib.red-bean.com/rc2/SOURCES/ , and kernel 2.6.16.11)
[EMAIL PROTECTED] netpipe3-dev]# ibv_rc_pingpong -n 1 node4
local address: LID 0x00
>+static int iser_free_device_ib_res(struct iser_device *device)
>+{
>+ BUG_ON(device->mr == NULL);
>+
>+ tasklet_kill(&device->cq_tasklet);
>+
>+ (void)ib_dereg_mr(device->mr);
>+ (void)ib_destroy_cq(device->cq);
>+ (void)ib_dealloc_pd(device->pd);
>+
>+ device->mr =
Sean Hefty wrote:
I'd like to propose that the MAD layer detect duplicate requests. After a
request MAD has been handed to a client, its context would be maintained until
the user calls ib_free_recv_mad(), allowing duplicate requests to be discarded.
I should add that this also provides contex
Today, a request MAD received by the MAD layer is handed to a client. The
client processes the MAD, and generates a response. If the client is slow to
process the MAD, the request may have been resent. The duplicate request is
also handed to the client. The result is that clients perform duplic
[EMAIL PROTECTED] wrote:
> Steve Wise wrote:
>> The Chelsio RNIC has this issue. If the server sends the first FPDU
>> _before_ the client driver has moved the connection/qp into RDMA
>> mode, then the data is placed as streaming data and the connection
>> must be terminated (dapltest 6 exposes th
Let SDP determine which version of the SDP headers to use. The
CMA will check that it can support that version, and set the
address fields appropriately.
The CMA will also verify that the major SDP and IP versions are
supported on received REQ and REP messages. If an unsupported
version is recei
[EMAIL PROTECTED] wrote:
>> I'm confused. Is this an iWARP requirement or a Chelsio requirement?
>> It sounds like iWARP supports data transfers being initiated by the
>> server but the Chelsio implementation does not.
>>
>
> This is an iWARP requirement. (I will _not_ argue that its a
> reasona
How this requirement is enforced is really the issue, I guess...
On Fri, 2006-04-28 at 15:42 -0500, Steve Wise wrote:
> > I'm confused. Is this an iWARP requirement or a Chelsio requirement?
> > It sounds like iWARP supports data transfers being initiated by the
> > server but the Chelsio imple
> I'm confused. Is this an iWARP requirement or a Chelsio requirement?
> It sounds like iWARP supports data transfers being initiated by the
> server but the Chelsio implementation does not.
>
This is an iWARP requirement. (I will _not_ argue that its a reasonable
requirement, however :)
See
On Fri, 2006-04-28 at 12:00 -0700, Sean Hefty wrote:
> Steve Wise wrote:
> > The Chelsio RNIC has this issue. If the server sends the first FPDU
> > _before_ the client driver has moved the connection/qp into RDMA mode,
> > then the data is placed as streaming data and the connection must be
> > t
On Fri, 28 Apr 2006, Steve Wise wrote:
> On Fri, 2006-04-28 at 11:32 -0700, Sean Hefty wrote:
> > Steve Wise wrote:
> > > This patch changes the dapltest transaction test to force the client
> > > side (the side that dat_ep_connect()) to send the first RDMA message.
> > > This ensures that the I
On 4/28/06, Pekka J Enberg <[EMAIL PROTECTED]> wrote:
On 4/27/06, Or Gerlitz <[EMAIL PROTECTED]> wrote:
> > > With 2.6.17-rc3 I'm running into something which seems as a bug related
> > > to kmem_cache. Doing some allocations/deallocations from a kmem_cache and
> > > later attempting to destroy i
Steve Wise wrote:
The Chelsio RNIC has this issue. If the server sends the first FPDU
_before_ the client driver has moved the connection/qp into RDMA mode,
then the data is placed as streaming data and the connection must be
terminated (dapltest 6 exposes this intermittently). Ammasso doesn't
On Fri, 2006-04-28 at 11:32 -0700, Sean Hefty wrote:
> Steve Wise wrote:
> > This patch changes the dapltest transaction test to force the client
> > side (the side that dat_ep_connect()) to send the first RDMA message.
> > This ensures that the IWARP MPA protocol requirements are met.
> >
> > I'm
Steve Wise wrote:
This patch changes the dapltest transaction test to force the client
side (the side that dat_ep_connect()) to send the first RDMA message.
This ensures that the IWARP MPA protocol requirements are met.
I'm presenting this for discussion and possible inclusion in the
trunk.
James,
This patch changes the dapltest transaction test to force the client
side (the side that dat_ep_connect()) to send the first RDMA message.
This ensures that the IWARP MPA protocol requirements are met.
I'm presenting this for discussion and possible inclusion in the
trunk.
A transport i
On Sun, 2006-04-23 at 10:26, Sasha Khapyorsky wrote:
> Send changed pkey table blocks to ports only after full update and not
> after each pkey value change/update.
>
> Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]>
Thanks. Applied (to trunk only) with some cosmetic changes.
-- Hal
___
On Thu, 27 Apr 2006, Arlin Davis wrote:
> Here is a new patch with your recommended changes.
Thanks Arlin. Committed in revision 6736 of the trunk and revision
6737 of the 1.0 release tree.
___
openib-general mailing list
openib-general@openib.org
ht
On 4/27/06, Or Gerlitz <[EMAIL PROTECTED]> wrote:
> > > With 2.6.17-rc3 I'm running into something which seems as a bug related
> > > to kmem_cache. Doing some allocations/deallocations from a kmem_cache and
> > > later attempting to destroy it yields the following message and trace
On Thu, 27 Apr
On Fri, 2006-04-28 at 09:32 +0300, Pekka Enberg wrote:
> Hi Heiko,
>
> On 4/28/06, Heiko J Schick <[EMAIL PROTECTED]> wrote:
> > The problem I see with pr_debug() is that it could only activated via
> > a compile flag. To use the debug outputs you have to re-compile /
> > compile your own kernel.
26 matches
Mail list logo
