Hi all,
just when we thought we'd finally nailed the error handling on FC ...
A customer of ours recently hit this really nasty issue:
He had a 'drain' on the SAN, in the sense that the link was still
intact, but no commands were coming back from the link.
This caused the FC HBA / driver to no
On 11/19/2012 7:41 AM, Hannes Reinecke wrote:
Hi all,
just when we thought we'd finally nailed the error handling on FC ...
A customer of ours recently hit this really nasty issue:
He had a 'drain' on the SAN, in the sense that the link was still
intact, but no commands were coming back from t
On Mon, 2012-11-26 at 17:32 -0500, James Smart wrote:
> Given path switching is somewhat separate from the i/o, would it better
> to send a notification of a path-fail condition as part of the eh,
> rather than hinging it on the individual i/o. Yes, the i/o is still in
> limbo and can't be swit
t; To: james.sm...@emulex.com
> Cc: Hannes Reinecke; SCSI Mailing List; Andrew Vasquez; Chad Dupuis;
> James Bottomley
> Subject: Re: Error handling on FC devices
>
> On Mon, 2012-11-26 at 17:32 -0500, James Smart wrote:
> > Given path switching is somewhat separate from the i/o, would
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,
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 pa
On 11/29/2012 05:02 PM, James Smart wrote:
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
On 11/30/2012 05:44 AM, Hannes Reinecke wrote:
> On 11/29/2012 05:02 PM, James Smart wrote:
>> 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
>>
On 11/30/2012 05:54 PM, Mike Christie wrote:
On 11/30/2012 05:44 AM, Hannes Reinecke wrote:
On 11/29/2012 05:02 PM, James Smart wrote:
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 i
On 12/3/2012 1:15 AM, Hannes Reinecke wrote:
> Well, looking at QLogic and Emulex both emulate a bus reset with a loop
> over each target and invoke a target reset there. I somewhat fail to see
> the rationale behind it, other than emulating the bus reset behaviour on
> SPI.
It is actually
> Well, looking at QLogic and Emulex both emulate a bus reset with a
> loop over each target and invoke a target reset there.
> I somewhat fail to see the rationale behind it, other than emulating
> the bus reset behaviour on SPI.
> Given that the original target reset already failed (otherwise we
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/03/2012 04:52 PM, Elliott, Robert (Server Storage) wrote:
>
>> Well, looking at QLogic and Emulex both emulate a bus reset with a
>> loop over each target and invoke a target reset there.
>> I somewhat fail to see the rationale behind it, other
12 matches
Mail list logo
