Hi Mike,
> [Muneendra] I have to make sure the flag is set after the check for
> blocked state. If blocked, it's returning BLK_EH_RESET_TIMER, so it
> will restart the eh timer. The io will "sit out" like this, pending,
> until either the adapter fails it back due to logout or io completion,
> or fastio fail or rport devloss timesout and invokes the abort handler
> to force abort .
>Hey,
>I'm not sure if we are talking about the same thing. If port state is
>marginal above, then we set the NORETRIES bit then return BLK_EH_DONE which
>will start up the scsi eh_abort_handler and if that fails the rest of the
>scsi >eh_*_handlers.
>While we are calling the eh handlers, if the driver does a
>fc_remote_port_delete then fc_remote_port_add we still have the NORETRIES
>bit set, so when we return from the eh_*_handlers we will fail the IO
>upwards.
>I was trying to ask if you wanted the IO failed upwards in that case.
>Because the port state went to online, did you want the normal (cleared
>NOTRIES bit) cmd retry behavior? It sounds like below you want the cleared
>NORETRIED bit behavior, right?
[Muneendra]Yes we need the normal cmd behavior(clear noretries bit) when the
portstate went to normal.
I think to achieve this we can clear the noretries bit in fc_block_scsi_eh/
fc_block_rport .
As this is the last place where the individual abort_handler checks for
blocked state. Is this fine?
Regards,
Muneendra.
>
>> + (rport->port_state != FC_PORTSTATE_MARGINAL)) {
>> spin_unlock_irqrestore(shost->host_lock, flags);
>> return;
>
>> It looks like if fc_remote_port_delete is called, then we will allow
>> that function to set the port_state to blocked. If the problem is
>> resolved then fc_remote_port_add will set the state to online. So it
>> would look like the port state is >now ok in the kernel, but would
>> userspace still have it in the marginal port group?
>
>> Did you want this behavior or did you want it to stay in marginal
>> until your daemon marks it as online?
> [Muneendra] We need this behavior.User daemon should not depend on the
> rport_state to move a path from marginal path
> group.It should only depends on RSCN and LINKUP events/manual
> intervention. events that we look out (rscn for target-side cable
> bounces and link up/down for initiator cable bounces) will result in
> port state changes - so although we don't drive one from the other,
> they are correlated.
>
> Regards,
> Muneendra.
>
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
