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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Joe Eykholt wrote:
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?


Did you see the thread
http://www.open-fcoe.org/pipermail/devel/2008-July/000394.html
I think we basically said we need to overhaul the fc class fc_remote_port and the libfc's use - some of the discussion went off list into some call. James and Chris were going to work on it. I think both got busy with other issues or are still working on it.
--
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux