Re: Error handling on FC devices

[James Smart <James.Smart@emulex.com>]

Always possible - but....   Our f/w works at the FCP level and below, 
which means it doesn't know/do SCSI commands - e.g what the cdb within 
the FCP CMD frame is; know anything about SCSI device classes and state; 
etc. And it shouldn't be required to do so. Anytime this has been there 
in the past, it's been problematic.

if we want to do this - we should add it to the midlayer/transport.

-- james  s


On 11/28/2012 2:09 AM, Hannes Reinecke wrote:
> On 11/27/2012 09:29 PM, Elliott, Robert (Server Storage) wrote:
>> There is a new command in SPC-4 called REMOVE I_T NEXUS that is 
>> intended to help
> > that situation.  REMOVE I_T NEXUS lets the application client use a 
> good I_T nexus
> > to abort commands that were being processed on a bad I_T nexus, so 
> it can safely
> > re-issue those commands on the good I_T nexus without worrying that 
> the original
> > commands might resume.
>>
>> In contrast:
>> - the ABORT TASK, ABORT TASK SET, and CLEAR TASK SET must use the 
>> same I_T nexus
> >   as the commands being aborted, so are not viable if that I_T nexus 
> is bad
>> - LOGICAL UNIT RESET aborts commands from every I_T nexus, so in 
>> addition to
> >   aborting commands from the bad I_T nexus it also affects commands 
> on the
> >   good I_T nexus
>>
> Hmm. Nice in principle, but the problem here is that we cannot 
> guarantee the nexus is still intact.
> So one would need to implement this in the HBA firmware; the firmware 
> would need to be able to process the TMF, and do the appropriate 
> things for the FC stack like dropping the rport etc.
>
> Good idea, though.
>
> James, Andrew, Chad?
> Any chance of having a firmware supporting REMOVE IT-NEXUS ?
>
> Cheers,
>
> Hannes