Roland Dreier [EMAIL PROTECTED] writes:
Definitely makes sense. I queued the following version for 2.6.20,
which gets the max CDB size directly from struct srp_cmd. Does this
look OK to you?
Looks good to me. I guess there's no way to sneak it into 2.6.19
anymore, right? ;)
Thanks,
Arne
Am Freitag, den 21.07.2006, 09:42 -0700 schrieb Sean Hefty:
Arne Redlich wrote:
I only took a rather superficial look at the code. But since the invalid
GID REJ is treated with such care, I guess it's intentional and not a
bug?
I would lean more towards it being a bug. The data
Am Donnerstag, den 20.07.2006, 18:44 +0300 schrieb Michael S. Tsirkin:
Quoting r. Arne Redlich [EMAIL PROTECTED]:
Subject: Re: [openib-general] [PATCH 2/2] ib_cm: fix REJ due to invalid GID
Am Mittwoch, den 19.07.2006, 20:05 +0300 schrieb Michael S. Tsirkin:
Quoting r. Arne Redlich
Am Mittwoch, den 19.07.2006, 20:05 +0300 schrieb Michael S. Tsirkin:
Quoting r. Arne Redlich [EMAIL PROTECTED]:
Subject: Re: [openib-general] [PATCH 2/2] ib_cm: fix REJ due to invalid GID
Am Dienstag, den 18.07.2006, 12:21 -0700 schrieb Sean Hefty:
Arne Redlich wrote:
Yep - the Gen1
Am Dienstag, den 18.07.2006, 10:09 -0700 schrieb Sean Hefty:
Arne Redlich wrote:
@@ -1354,6 +1354,7 @@ static int cm_req_handler(struct cm_work
id.local_id);
if (IS_ERR(cm_id_priv-timewait_info)) {
ret = PTR_ERR
Am Dienstag, den 18.07.2006, 12:21 -0700 schrieb Sean Hefty:
Arne Redlich wrote:
Yep - the Gen1 SRP initiator does. It sends a REQ with an invalid DGID.
If rejected with the correct code (INVALID GID), it will retry after
looking up the GID.
Didn't it have a DGID from a path record
the reject param.
Arne
--
Arne Redlich
Xiranet Communications GmbH
___
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
as
expected.
Thanks,
Arne
--
Arne Redlich
Xiranet Communications GmbH
___
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
Reject a REQ containing invalid GID(s) with appropriate reason codes
instead of IB_CM_CONSUMER_REJ.
Signed-off-by: Arne Redlich [EMAIL PROTECTED]
Index: infiniband/core/cm.c
===
--- infiniband/core/cm.c(revision 8556
In its current incarnation, cm_destroy_id() will not send a REJ if fed a
magic number (err = -ENOMEM). This patch replaces this magic number with
a more generic reject parameter.
Signed-off-by: Arne Redlich [EMAIL PROTECTED]
Index: infiniband/core/cm.c
.
Signed-off-by: Arne Redlich [EMAIL PROTECTED]
Index: infiniband/core/cm.c
===
--- infiniband/core/cm.c(revision 8565)
+++ infiniband/core/cm.c(working copy)
@@ -702,7 +702,7 @@ static void cm_reset_to_idle(struct
Am Dienstag, den 18.07.2006, 17:31 +0300 schrieb Michael S. Tsirkin:
Quoting r. Arne Redlich [EMAIL PROTECTED]:
Subject: Re: [PATCH 1/2] ib_cm: cm_destroy_id() cleanup
Am Dienstag, den 18.07.2006, 06:59 -0700 schrieb Roland Dreier:
+ cm_destroy_id(cm_id_priv-id, (ret
Am Dienstag, den 18.07.2006, 17:43 +0300 schrieb Michael S. Tsirkin:
Quoting r. Arne Redlich [EMAIL PROTECTED]:
Reject a REQ containing invalid GID(s) with appropriate reason codes
instead of IB_CM_CONSUMER_REJ.
Signed-off-by: Arne Redlich [EMAIL PROTECTED]
Are there actual
Roland Dreier [EMAIL PROTECTED] writes:
I'm afraid it *does* have an effect, unfortunately.
Hmm, go ahead and forward the fix from 2.6.17 to the stable team for
kernel 2.6.16 if this bug affects your target.
Thanks,
Roland
It doesn't affect our target during regular operation, as
+
sizeof *buf);
So if a target actually RDMA Reads the indirect descriptor table, it will use a
wrong address.
Arne
--
Arne Redlich
Xiranet Communications GmbH
___
openib-general mailing list
openib-general@openib.org
http://openib.org
Ishai Rabinovitz [EMAIL PROTECTED] writes:
On Tue, May 23, 2006 at 10:10:05AM +0300, Arne Redlich wrote:
Roland Dreier [EMAIL PROTECTED] writes:
Roland, maybe this means we need scsi/srp.h in svn for now?
svn is supposed to work on 2.6.16 ...
As far as I can tell the bug
Am Dienstag, den 28.06.2005, 15:32 -0700 schrieb Libor Michalek:
On Tue, Jun 28, 2005 at 09:15:21AM +0200, Arne Redlich wrote:
Am Montag, den 27.06.2005, 11:35 -0700 schrieb Libor Michalek:
On Wed, Jun 22, 2005 at 10:39:43AM +0200, Arne Redlich wrote:
Hi,
I'm trying to use SDP
Am Montag, den 27.06.2005, 11:35 -0700 schrieb Libor Michalek:
On Wed, Jun 22, 2005 at 10:39:43AM +0200, Arne Redlich wrote:
Hi,
I'm trying to use SDP from within the kernel. My problem is that the
code relies on sk_data_ready() (this callback is modified to wake up a
Rx thread before
Hi,
I'm trying to use SDP from within the kernel. My problem is that the
code relies on sk_data_ready() (this callback is modified to wake up a
Rx thread before executing the original function), but sk_data_ready()
apparently never gets called. Is there any way to fix this?
Thanks,
Arne
--
Arne
19 matches
Mail list logo
