Retrying cmd when SNS Key is "Unit Attention" and the device is not removable

Retrying cmd when SNS Key is "Unit Attention" and the device is not removable

[Robert Love]

I'm not seeing commands retried when the target returns "Check
Condition / Unit Attention" for SNS data.

I narrowed it down to commit id:
b60af5b0adf0da24c673598c8d3fb4d4189a15ce which makes changes to the
scsi_io_completion() function. In particular it is now calling
scsi_queue_insert(cmd, SCSI_MLQUEUE_EH_RETRY) instead of
scsi_requeue_command() when the sense_key is UNIT_ATTENTION and the
device is not removable. I don't fully understand the differences in
these functions, and I'm continuing to investigate, but something is
causing the command to not be retried.

I came across this when I was testing Open-FCoE's reset functionality.
We logout of targets and then re-login to them. The binding persists and
the target is shown as "Online" after the re-login. After that, if I run
'fdisk -l' the SCSI-ml sends a "Read(10)" command and the target replies
with "Status: Check Condition (0x02)" and fdisk hangs. Before the above
mentioned patch the SCSI-ml would retry and the response would be good
(w/ payload). I'm not sure why the target/lun replies with "Check
Condition."

Was it intentional that this patch changed the retry function for
(sense_key == UNIT_ATTENTION && !cmd->device->removable)? I imagine so
because the commit message talks about the various retry scenarios. Does
anyone have any leads as to why this doesn't retry?

Thanks,

//Rob

RE: Retrying cmd when SNS Key is "Unit Attention" and the device is not removable

[Love, Robert W]

Robert Love wrote:
> I'm not seeing commands retried when the target returns "Check
> Condition / Unit Attention" for SNS data.
> 
It looks like a fix went in about a week ago for this. I
retested with the tip and as far as I can tell it works fine.