Vasu Dev wrote:
Currently fc_fcp_abts_resp() only does exch_done and cleanup
if BA_ACC received to abort req, so added code to do cleanup
on BA_RJT also, however not sure if scsi result should be
diffrent for BA_ACC v/s BA_RJT.
Either way we need to retry the command because we dropped status and
data. I thought I sent a patch for that but it looks like it did not hit
the list, so here it is attached. With that patch we will retry the command.
Signed-off-by: Vasu Dev <[EMAIL PROTECTED]>
---
drivers/scsi/libfc/fc_fcp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/libfc/fc_fcp.c b/drivers/scsi/libfc/fc_fcp.c
index f2915ed..bfe077f 100644
--- a/drivers/scsi/libfc/fc_fcp.c
+++ b/drivers/scsi/libfc/fc_fcp.c
@@ -609,7 +609,7 @@ static void fc_fcp_abts_resp(struct fc_fcp_pkt *fsp, struct
fc_frame_header *fh)
* we will let the command timeout and scsi-ml escalate if
* the abort was rejected
*/
- if (fh->fh_r_ctl == FC_RCTL_BA_ACC) {
+ if (fh->fh_r_ctl == FC_RCTL_BA_ACC || fh->fh_r_ctl == FC_RCTL_BA_RJT) {
I remembered why I did this after I mentioned it on the list. If it is
rejected do we know the status of the exchange we are aborting? If not
then it seemed safest to let the scsi eh escalate the eh. For example if
it is rejected because the target port is not able to exexute the abort
then we do not want to complete the command here and possibly retry it
before killing it on the target.
I guess to be able to complete it here we need to look into the reason
code, but I am not sure if the optimization is needed.
fsp->state |= FC_SRB_ABORTED;
fsp->state &= ~FC_SRB_ABORT_PENDING;
fsp->status_code = FC_CMD_ABORTED;
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
>From 594d07c42db1625d70daa9b0ac7e8a20d29b1513 Mon Sep 17 00:00:00 2001
From: Mike Christie <[EMAIL PROTECTED]>
Date: Thu, 21 Aug 2008 23:03:25 -0500
Subject: [PATCH 9/9] libfc: Do not return DID_ABORT unless we have to
I added this bug when I fixed the abort code. If fc_fcp.c
is forcing a retry then we do not want to complete the
command with DID_ABORT because that will fail the command.
If we are aborting the command from the scsi eh it
does not really matter what we return because the scsi_done code is short
circuited.
This patch was made over my outstanding patches. I put them
up here:
http://kernel.org/pub/linux/kernel/people/mnc/fcoe/21-08-08
Signed-off-by: Mike Christie <[EMAIL PROTECTED]>
---
drivers/scsi/libfc/fc_fcp.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/libfc/fc_fcp.c b/drivers/scsi/libfc/fc_fcp.c
index f2915ed..e974ce1 100644
--- a/drivers/scsi/libfc/fc_fcp.c
+++ b/drivers/scsi/libfc/fc_fcp.c
@@ -612,7 +612,6 @@ static void fc_fcp_abts_resp(struct fc_fcp_pkt *fsp, struct
fc_frame_header *fh)
if (fh->fh_r_ctl == FC_RCTL_BA_ACC) {
fsp->state |= FC_SRB_ABORTED;
fsp->state &= ~FC_SRB_ABORT_PENDING;
- fsp->status_code = FC_CMD_ABORTED;
if (fsp->wait_for_comp)
complete(&fsp->tm_done);
@@ -859,9 +858,10 @@ static void fc_fcp_complete(struct fc_fcp_pkt *fsp)
if (fsp->state & FC_SRB_ABORT_PENDING)
return;
- if (fsp->state & FC_SRB_ABORTED)
- fsp->status_code = FC_CMD_ABORTED;
- else {
+ if (fsp->state & FC_SRB_ABORTED) {
+ if (!fsp->status_code)
+ fsp->status_code = FC_CMD_ABORTED;
+ } else {
/*
* Test for transport underrun, independent of response
* underrun status.
--
1.5.5.1
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
