Mike Christie wrote:
Well - what should be happening is - prior to the reset or as part of
it, the fc transport fc_remote_port_delete() call should be made on all
those remote ports that connectivity is about to be terminated on. This
will place all the associated targets/luns on those rports into a
blocked state, and start the devloss timer on them. This will suspend
the eh path as well. Thus, things suspend until either the driver/fcoe
What do you mean by that? For lpfc it will or for this driver? This
driver does not have that block call like lpfc_block_error_handler, so
if the rport event occurs after the scsi eh is running we do not suspend
the eh.
So below I am saying we should make the lpfc_block_error_handler
functionality and the equivalent in the qla2xxx and mpfc common so
libfc/fcoe and fnic can use it.
Well there's successive layers of the onion here. And your right, one of
them is the block_error_handler. Agreed, all of this should be common.
-- james s
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
