Hi Bart,
On 07.01.2013 12:34, Bart Van Assche wrote:
Sorry but this patch looks wrong to me, and that because of the
following reasons:
- A root cause analysis is missing. It has been mentioned in the patch
description that device_del() did hang but an analysis of why that
hang occurred
Van Assche.
See also https://github.com/advance38/linux/tree/ib-srp-remove-target-v3.7.
If necessary, I could rebase it on the stable tree.
Signed-off-by: Dongsu Park dongsu.p...@profitbricks.com
Cc: Sebastian Riemer sebastian.rie...@profitbricks.com
Cc: Bart Van Assche bvanass...@acm.org
Cc: David
cma_cm_response_timeout=30 cma_max_cm_retries=60
Signed-off-by: Dongsu Park dongsu.p...@profitbricks.com
Reviewed-by: Sebastian Riemer sebastian.rie...@profitbricks.com
---
drivers/infiniband/core/cma.c | 21 ++---
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 15 ---
drivers
From: Dongsu Park dongsu.p...@profitbricks.com
Unter circumstances, srp_rport_add() can make conflicts with
srp_rport_delete(), dumping the call trace written below.
That does not always occur. But its possible reason is adding
sysfs entries for the SRP target too fast, even before the
deletion
From: Dongsu Park dongsu.p...@profitbricks.com
After removing rport_delete(), rport-lld_data has to be set to NULL.
In addition to that, both srp_rport_delete() and
rport_dev_loss_timedout() must check if rport-lld_data is NULL,
before accessing to rport-lld_data or any rport's target area
From: Dongsu Park dongsu.p...@profitbricks.com
Signed-off-By: Sebastian Riemer sebastian.rie...@profitbricks.com
---
drivers/infiniband/ulp/srp/ib_srp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
b/drivers/infiniband/ulp/srp/ib_srp.c
index a0d0ca2
Hi Bart,
On 28.08.2012 10:04, Bart Van Assche wrote:
On 08/27/12 18:37, Dongsu Park wrote:
while testing ib_srp based on your srp-ha,
we sometimes hit kernel crashes with the call trace below.
How to reproduce:
0. Kernel 3.2.15 with SCST v4193 on the target,
Kernel 3.2.8
Hi Bart,
while testing ib_srp based on your srp-ha,
we sometimes hit kernel crashes with the call trace below.
How to reproduce:
0. Kernel 3.2.15 with SCST v4193 on the target,
Kernel 3.2.8 with ib_srp-ha on the initiator.
1. Configure 500+ vdisks on target, and get initiator connected.
2.
Hi Bart,
I'll try to explain, as Sebastian is on vacation.
On 23.08.2012 16:43, Bart Van Assche wrote:
On 08/23/12 15:59, Sebastian Riemer wrote:
we've triggered the WARN_ON() in srp_wait_last_send_wqe() by connecting
to a disabled SCST SRP target.
I would remove that one.
[ ... ]
