Re: [RFC][PATCH 2/6] fnic: add fnic_scsi.c and fnic_io.h.

Joe Eykholt
2008-08-25T21:16:45Z

James Smart wrote:
>
>
> 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
>

I think you're both on the right track. When we reset the local port, it should make all
remote ports non-ready ... we no longer have a PLOGI to them. Until we redo FLOGI and
discovery, no SCSI ops will succeed. fc_lport_reset() calls fc_lport_set_fid, which calls
lp_rport_reset_list() ... but that doesn't seem to do much to rports other than the
directory server.

fc_rport_reset() puts the rport in state INIT, but I don't think that's enough. Maybe
that's where the remote port should get blocked. Sound right?

Joe