'Bus reset' is not really applicable to FibreChannel, as
the concept of a bus doesn't apply. Hence all FC LLDD
simulate a 'bus reset' by sending a target reset to each
attached remote port, causing error handling to spill
over to unaffected devices.
This patch implements a 'I_T nexus reset' handle
On 12/07/2012 08:51 AM, Hannes Reinecke wrote:
> 'Bus reset' is not really applicable to FibreChannel, as
> the concept of a bus doesn't apply. Hence all FC LLDD
> simulate a 'bus reset' by sending a target reset to each
> attached remote port, causing error handling to spill
> over to unaffected d
On Fri, 7 Dec 2012, Mike Christie wrote:
On 12/07/2012 08:51 AM, Hannes Reinecke wrote:
'Bus reset' is not really applicable to FibreChannel, as
the concept of a bus doesn't apply. Hence all FC LLDD
simulate a 'bus reset' by sending a target reset to each
attached remote port, causing error h
On 12/7/2012 1:58 PM, Chad Dupuis wrote:
> Also, are there certain port types we wouldn't want to send this reset to
> such as tape?
AFAIK, for tape it shouldn't cause any more harm than the target reset
which
happens immediately before it. This patch is infinitely better than the
previo
On 12/07/2012 03:05 PM, Jeremy Linton wrote:
> On 12/7/2012 1:58 PM, Chad Dupuis wrote:
>> Also, are there certain port types we wouldn't want to send this reset to
>> such as tape?
>
> AFAIK, for tape it shouldn't cause any more harm than the target reset
> which
> happens immediately bef
On 12/7/2012 3:20 PM, Mike Christie wrote:
> On 12/07/2012 03:05 PM, Jeremy Linton wrote:
>> That said, its far from perfect. The code (as I understand it) isn't
>> differentiating between isolating the failure, or bringing out the big
>> hammer in an attempt to correct problems on a specific I_T
Am 12/07/2012 07:58 PM, schrieb Mike Christie:
On 12/07/2012 08:51 AM, Hannes Reinecke wrote:
'Bus reset' is not really applicable to FibreChannel, as
the concept of a bus doesn't apply. Hence all FC LLDD
simulate a 'bus reset' by sending a target reset to each
attached remote port, causing erro
On 12/09/2012 09:40 AM, Hannes Reinecke wrote:
> Am 12/07/2012 07:58 PM, schrieb Mike Christie:
>> On 12/07/2012 08:51 AM, Hannes Reinecke wrote:
>>> 'Bus reset' is not really applicable to FibreChannel, as
>>> the concept of a bus doesn't apply. Hence all FC LLDD
>>> simulate a 'bus reset' by send
On 12/09/2012 05:19 PM, Mike Christie wrote:
>
>> >
>>> >>
>>> >>
>>> @@ -3266,8 +3271,8 @@ fc_timeout_fail_rport_io(struct work_struct
>>> *work)
>>> if (rport->port_state != FC_PORTSTATE_BLOCKED)
>>> return;
>>>
>>> -rport->flags |= FC_RPORT_FA
On Dec 7, 2012, at 8:51 AM, Hannes Reinecke wrote:
>
> diff --git a/drivers/scsi/bfa/bfad_im.c b/drivers/scsi/bfa/bfad_im.c
> index 8f92732..d6555aa 100644
> --- a/drivers/scsi/bfa/bfad_im.c
> +++ b/drivers/scsi/bfa/bfad_im.c
> @@ -793,7 +793,7 @@ struct scsi_host_template bfad_im_scsi_host_temp
Am 12/07/2012 08:58 PM, schrieb Chad Dupuis:
On Fri, 7 Dec 2012, Mike Christie wrote:
On 12/07/2012 08:51 AM, Hannes Reinecke wrote:
'Bus reset' is not really applicable to FibreChannel, as
the concept of a bus doesn't apply. Hence all FC LLDD
simulate a 'bus reset' by sending a target reset
11 matches
Mail list logo
