On 12/07/12 22:47, Vu Pham wrote:
I applied your latest patch [PATCH for-next] IB/srp: Make SCSI error
handling finish
and test
Let me capture what I'm seeing:
Host has two paths (scsi_host 7 & 8) to target thru two physical ports 1
& 2
[root@rsws42 ~]# multipath -l
size=50G features='0' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=0 status=active
| `- 7:0:0:11 sdb 8:16 active undef running
`-+- policy='round-robin 0' prio=0 status=enabled
`- 8:0:0:11 sdc 8:32 active undef running
Cable pull by disable port 1, I/Os fail-over fine, the problem is the
cleaning of scsi_host 7 of fail path.
IB RC failure, scsi error recovery kick in.
srp _reconnect_target() failed, srp_remove_target() run to remove
scsi_host 7; however, I think it get stuck at device_del(dev) inside
__scsi_remove_device(dev)
Error recovery continuously happen again and again on scsi host 7 for
9-10 minutes.
scsi_host 7 cannot be cleaned up, its sysfs entry is still there
(/sys/class/scsi_host/host7), its state is SHOST_CANCEL.
I brought port 1 back online, scsi_host 7 cannot reconnect to target
because its state in SRP_TARGET_REMOVED.
scci_host 7 sysfs entry does not contain target login info (ioc_guid,
id_ext, dgid...).
I think srp_daemon can reconnect to target by creating new path with new
scsi hosst; however, I cannot check because I currently don't have a
working srp_daemon.
I need to manually reconnect to target with echo command
Bottom line, I/Os can fail-over/failback; however, old scsi hosts cannot
be removed (sysfs entry is still there) with state SHOST_CANCEL, error
recovery keep happening on old scsi hosts for 10-20 minutes.
(reduced CC list)
Hello Vu,
Please double check the kernel tree you have used in your test. The
behavior you describe is the behavior that was fixed by the patch you
mentioned. If I repeat your test with Roland's for-next tree (commit
fb57e1d) with the "Make SCSI error handling finish" patch on top and on
a system where srp_daemon is not running, this is what I see:
* About 60s after "ibportstate 1 1 disable" on the target, the message
"scsi host7: SRP abort called" appears in the initiator kernel log.
* A few seconds later the following messages appear in the kernel log
of the initiator:
scsi host7: SRP reset_device called
scsi host7: ib_srp: SRP reset_host called
scsi host7: ib_srp: Got failed path rec status -110
scsi host7: ib_srp: Path record query failed
scsi host7: ib_srp: reconnect failed (-110), removing target port.
sd 7:0:0:0: Device offlined - not ready after error recovery
sd 7:0:0:0: alua: Detached
* A quick check in /sys on the initiator shows that the corresponding
SCSI host has been removed correctly:
# find /sys | grep host7
# ls /sys/class/scsi_host/
host0 host1 host10 host2 host3 host4 host5
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
