need to perform rebase.
Sorry for any inconvenient.
Thanks
Ishai
___
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
Applied,
Thanks
Ishai
___
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
Applied,
Thanks
Ishai
___
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
reset_device call send_tsk_mgmt that waits for the timeout).
The following patch solves this problem by identifying the failure
and returning an immediate error code.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
---
Hi Roland,
This is an old patch. We thought at first that the timeout is b
This patch checks if the kmalloc in match_strdup was successful.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
---
Index: gen2_devel_kernel/drivers/infiniband/ulp/srp/ib_srp.c
===
--- gen2_devel_kernel.orig/drivers/infi
hat the higher layers (e.g., SRP) do not know what was the
exact status and therefore treat status 1 (busy) as an error.
Am I missing something?
Ishai
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listin
a different initiator_ext, but you
should add a new flag for actually setting the initiator_ext and leave -n
untouched.
You are welcome to send such a patch.
Ishai
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/li
not be a part of the coming OFED
release.
Ishai
-Original
Message-From: Sharma,
Karun [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 17, 2006 5:11
AMTo: Tziporet Koren; Open
FabricsCc: openibSubject: RE: [openfabrics-ewg] OFED 1.1
release schedule
The plan is OK with
providing the
target attributes.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
---
Roland, Madhu and MST,
I think this summarizes our discussion.
Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
===
--- last_stabl
allows the load of ib_cm module with a limit on the timeout.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
---
Index: last_stable/drivers/infiniband/core/cm.c
===
--- last_stable.orig/drivers/infiniband/core/cm.c 2
scsi_host_alloc already sets the entire scsi_host (including the privsize to
zero)
This patch removes the redundant memset.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/drivers/infiniband/ulp/srp/ib
checks the status of the
connections this ping pong can be for ever.
We need to find a way to eliminate this behavior.
Ishai
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, p
connection.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
---
I think this is the best solution. It allows users to use all four physical
connections from the initiator to target.
It also allows users to have several logical connections on one physical
connection (If they want conn
versions.
Ishai
> Isn't the format of 90-ib.rules in
> https://openfabrics.org/svn/gen2/trunk/ofed/openib/scripts/90-ib.rulesincorrect.
>
> We have
>
> KERNEL="umad*", NAME="infiniband/%k", which should be
> KERNEL=="umad*", NAM
connection requests, to avoid
getting
disconnects when multiple connections are active. There does not seem to be any
harm
in doing this even when multipath is not used.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
---
Index: last_stable/drivers/infiniband/ulp/srp/ib
performs post_send and waits for the timeout).
The following patch solves this problem by identifying the failure
and returning an immediate error code.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
---
Index: last_stable/drivers/infiniband/ulp/srp/ib
for SLES10. The reason is that SRP HA
uses the device-mapper multipath that needs high version of udev (>050).
RHEL4 uses udev 039.
Ishai
>> As for the HA it works on SuSE but not on RH. Ishai will
>> issue a report.
>
> This will be
.
Ishai
___
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
Here
is an Oops in ib_srp
From: Dachepalli, Sudhir
[mailto:[EMAIL PROTECTED] Sent: Tuesday, September 05, 2006
11:09 PMTo: Vu PhamCc: Richard, BillSubject:
OFED 1.1 rc3 srp driver panic
Hello
Vu,
I am trying to
integrate MPP and OFED 1.1 rc3 srp.
Status on following
2 issues.
See Below
-Original Message-
From: Roland Dreier [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 15, 2006 1:48 AM
To: Ishai Rabinovitz
Cc: openib-general@openib.org; Tziporet Koren
Subject: Re: A new version for srp daemon
> I put the code in
>
https://openib.org/svn/trunk/c
Adding
a subject
From: Ishai Rabinovitz Sent: Tuesday,
August 15, 2006 12:32 AMTo: 'Roland Dreier'Cc:
'openib-general@openib.org'; Tziporet KorenSubject:
Hi
Roland,
In order to support
High-Availability in OFED 1.1, we need more functionality to the srp
daemon.
/srp_daemon
and I'm in an initial testing stage (there are some known
bugs).
Since I think that
people may still want to use your original ibsrpdm, I think we should keep your
version and start a new tool from my code. What do you
think?
Ishai
The new tool main
features:
only the literal "erase" work for erase_target?
>
Because erase_target is a destructive command that can not be reversed I think
it should use a more safe approach.
--
Ishai Rabinovitz
___
openib-general mailing list
openib-general@openib.org
ct to the target. Using these files and the target GUID the
ibsrpdm can know on which scsi_host to perform the reconnect_target.
Please comment.
--
Ishai Rabinovitz
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/list
ue it will lock host_lock and will release it after
the loop.
I'm sending a patch for the second solution. If you prefer the first, I have
another patch for it (It is a bit longer).
Which solution do you like better?
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/
oo deeply yet, but something that would help me
> understand the overall plan here would be an explanation of how one
> would use the restore_target function. Why would I want to disconnect
> from a target but keep the kernel's SCSI device hanging around?
Add query for srp_state in sysfs.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
===
--- last_stable.orig/drivers/infiniband/ulp/srp/ib_srp.c2006-05-31
Add support to restore_target from sysfs.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
===
--- last_stable.orig/drivers/infiniband/ulp/srp/ib_srp.c2006-06-
Add support to remove_target from sysfs.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
===
--- last_stable.orig/drivers/infiniband/ulp/srp/ib_srp.c2006-06-
.
2) The value of target->cm_id can be NULL. This happens after _srp_remove_target
destroyed the old cm_id and before _srp_restore_target created the new cm_id.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/drivers/infiniband/ulp/srp
7;m not sure they are the correct thing to do. I'm waiting for
suggestions.
In any case I believe we should apply these patches and add solution to
this problem later.
Please comment.
--
Ishai Rabinovitz
___
openib-general mailing list
srp_reset_device and srp_reconnect_target
and call a new function srp_reset_req.
3) We can use list_move_tail in srp_remove_req.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/drivers/infiniband/ulp/srp/ib
The array agent is allocated with no entries.
When agent is being accessed in create_agent there is a memory corruption.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/src/userspace/srptools/src/sr
Hi,
I understand that there is a way to be informed by mail when there is a commit
to the svn repository.
How can I register?
Can I register to get notification only on svn commit to specific directories?
Thanks
--
Ishai Rabinovitz
___
openib-general
si_host_put(target->scsi_host);
> - /* And another put to really free the target port... */
> - scsi_host_put(target->scsi_host);
> }
>
> static int srp_connect_target(struct srp_target_port *target)
>
>
Roland,
As I told you before, your patch looks
penib-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
--
Ishai Rabinovitz
___
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 Fri, May 19, 2006 at 02:54:35AM +0300, Ishai Rabinovitz wrote:
Hi
Fixed the patch a little bit.
> Hi,
>
> I got "Unhandled CM event 6" (IB_CM_DREQ_ERROR) and "Unhandled CM event 7"
> (IB_CM_DREQ_RECEIVED).
>
> So here is a patch that handles these CM
. What do you think?
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
===
--- last_stable.orig/drivers/infiniband/ulp/srp/ib_srp.c2006-05-19
00:05:30.0 +03
3 changes in the same place:
1) The if statement is redundant.
2) There is no need to save the flags - it is inside a mutex_lock.
3) We hold the mutex for the list and we are not deleting from the list so
there is no need for list_for_each_entry_safe.
Signed-off-by: Ishai Rabinovitz <[EM
On Wed, May 17, 2006 at 06:40:04PM +0300, Ishai Rabinovitz wrote:
> Hi,
>
> While doing a code review I found a potential bug.
> I did not manage to execute a test to check this code.
> Please take a look:
Sorry, I made a mistake in the patch.
Please look at this one.
In srp_reco
Hi,
While doing a code review I found a potential bug.
I did not manage to execute a test to check this code.
Please take a look:
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
--
Index: last_stable/drivers/infiniband/ulp/srp/ib
e_work() and srp_remove_work() actually running.
>
> So the patch below seems correct to me.
>
> What do you think?
I could not reproduce the problem again, so this patch works for me.
--
Ishai Rabinovitz
___
openib-general mailing list
ope
;
> + return;
> + }
> wait_for_completion(&target->done);
> }
>
I don't think this caused the deadlock I had.
Still it looks like an important patch.
--
Ishai Rabinovitz
___
openib-general mailin
On Sun, May 14, 2006 at 02:02:01PM +0300, Ishai Rabinovitz wrote:
> Hi,
>
> After loading ib_srp module, adding a target and then unloading the ib_srp
> target the scsi_host directory in /sys/class/scsi_host/ still exists.
> It looks like the srp code does not release the s
Hi,
After loading ib_srp module, adding a target and then unloading the ib_srp
target the scsi_host directory in /sys/class/scsi_host/ still exists.
It looks like the srp code does not release the scsi_host it had allocated.
After examining the code I found out that when executing srp_remove_wor
to be involved?
>
> What if the daemon is killed/restarted?
>
> --
> MST
What if there are two daemons by accident?
--
Ishai Rabinovitz
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/op
es).
Any
comments?
Ishai
Rabinovitz
___
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
pay attention that we still face issues. The following is the diff
> between RC3 and the pre:
>
> 1. Bug fixes according to problems reported.
>
> 2. SRP - with new features: FMR, tunable parameters, SRP daemon - We have
> an issue with the back port of SRP to RH4 U2 and U3
On Mon, May 01, 2006 at 11:27:24AM -0700, Roland Dreier wrote:
> Ishai> Avoid a potential dead-lock. In srp_disconnect_target
> Ishai> there is a call to ib_send_cm_dreq and a wait for
> Ishai> completion If when getting DREP there is no comp no one
> Isha
On Mon, May 01, 2006 at 10:53:36AM -0700, Roland Dreier wrote:
> Ishai> Hi, I'm going to send 12 patches. 6 patches for the kernel,
> Ishai> and 6 for the userspace ibsrpdm. The kernel patches avoid
> Ishai> adding the same target twice, allow the removal of a
&
On Mon, May 01, 2006 at 04:50:32PM +0300, Muli Ben-Yehuda wrote:
> On Mon, May 01, 2006 at 02:28:48PM +0300, Ishai Rabinovitz wrote:
> >
> > Support a display of list of target from user level.
> >
> > Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
> >
On Mon, May 01, 2006 at 04:43:23PM +0300, Muli Ben-Yehuda wrote:
> On Mon, May 01, 2006 at 02:27:39PM +0300, Ishai Rabinovitz wrote:
> >
> > Do not add the same target twice.
> >
> > Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
> > Index: last_sta
On Mon, May 01, 2006 at 04:33:42PM +0300, Muli Ben-Yehuda wrote:
> On Mon, May 01, 2006 at 02:25:46PM +0300, Ishai Rabinovitz wrote:
> >
> > Move the destruction of the host and the removal from a list to a function.
> >
> > Signed-off-by: Ishai Rabinovitz <[EM
Hi,
I think there is a potential deadlock when disconnecting from the CM.
Roland, can you look at this patch and check if it is needed.
Thanks
Ishai
--
Avoid a potential dead-lock.
In srp_disconnect_target there is a call to
The query can be improved if working against OpenSM that supports
the option to ask about a certain bit in the capability mask.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/src/userspace/srptools/src/sr
Add -l option to ibsrpdm.
This option activates a daemon that queries for the targets in a loop and
tells ib_srp about new target that appears and old target that disappears.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/src/userspace/srptools/src/sr
Add a function send_and_get that handles the communication and retries.
Reduce redundancy.
Increment TID on retry.
Bound the number of retries.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/src/userspace/srptools/src/sr
alloca man page on my system says:
The alloca() function is machine and compiler dependent.
On many systems its implementation is buggy. Its use is discouraged.
Lets not use it.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/src/userspace/srptoo
Use constants for bits in masks. Improves readability.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/src/userspace/srptools/src/srp-dm.c
===
--- last_stable.orig/src/userspace/srptools/src/sr
Remove trailing spaces and arranging tabs.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/src/userspace/srptools/src/srp-dm.c
===
--- last_stable.orig/src/userspace/srptools/src/srp-dm.c2006
Support a display of list of target from user level.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
===
--- last_stable.orig/drivers/infiniband/ulp/srp/ib_srp.c
Support a remove of a target from user level.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
===
--- last_stable.orig/drivers/infiniband/ulp/srp/ib_srp.c2006
Do not add the same target twice.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
===
--- last_stable.orig/drivers/infiniband/ulp/srp/ib_srp.c2006-04-25
It is nicer to perform the init_work just before the call to schedule_work.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
===
--- last_stable.orig/drivers/infiniba
Move the destruction of the host and the removal from a list to a function.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
===
--- last_stable.orig/drivers/infiniba
Remove a redundant if
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
===
--- last_stable.orig/drivers/infiniband/ulp/srp/ib_srp.c2006-04-17
10:06:19.000
en applied without Vu's patches.
--
Ishai Rabinovitz
___
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
Hi
srp_process_rsp crashes on NULL pointer dereference.
The following fixes the crash.
Is this a correct fix?
---
Avoiding dereference of a null pointer.
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
Index: last_stable/drivers/infiniband/ulp/srp/ib
Yes it
should.
Ishai
From: Woodruff, Robert J
[mailto:[EMAIL PROTECTED] Sent: Thursday, April 06, 2006
1:31 AMTo: Ishai Rabinovitz;
[EMAIL PROTECTED]Subject: RE: [openfabrics-ewg] Changes in
SM for the new SRP daemon
Shouldn't this discussion be on openib-general
?
From: [
69 matches
Mail list logo
