James, Please drop this patch series, as it has a bug in the passthru patch. I'll resend the fixed patch series soon. Thanks, Brian Brian King wrote: > When processing the response to either a LUN reset, > target reset, or an abort task set, the ibmvfc driver needs to > treat as success receiving a response with a non-zero > status in the response IU along with a general transport > error with the FCP response code being zero. The VIOS > currently guarantees this cannot happen, but a future version > of VIOS may allow this to be returned, so ensure we handle > this response combination correctly for TMFs, as we already > do for SCSI commands. > > Signed-off-by: Brian King <brking@xxxxxxxxxxxxxxxxxx> > --- > > drivers/scsi/ibmvscsi/ibmvfc.c | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff -puN drivers/scsi/ibmvscsi/ibmvfc.c~ibmvfc_tmf_rsp_fixup drivers/scsi/ibmvscsi/ibmvfc.c > --- linux-2.6/drivers/scsi/ibmvscsi/ibmvfc.c~ibmvfc_tmf_rsp_fixup 2009-10-02 10:39:48.000000000 -0500 > +++ linux-2.6-bjking1/drivers/scsi/ibmvscsi/ibmvfc.c 2009-10-05 10:03:00.000000000 -0500 > @@ -1731,7 +1731,10 @@ static int ibmvfc_reset_device(struct sc > sdev_printk(KERN_INFO, sdev, "Resetting %s\n", desc); > wait_for_completion(&evt->comp); > > - if (rsp_iu.cmd.status) { > + if (rsp_iu.cmd.status) > + rsp_code = ibmvfc_get_err_result(&rsp_iu.cmd); > + > + if (rsp_code) { > if (fc_rsp->flags & FCP_RSP_LEN_VALID) > rsp_code = fc_rsp->data.info.rsp_code; > > @@ -1820,7 +1823,10 @@ static int ibmvfc_abort_task_set(struct > sdev_printk(KERN_INFO, sdev, "Aborting outstanding commands\n"); > wait_for_completion(&evt->comp); > > - if (rsp_iu.cmd.status) { > + if (rsp_iu.cmd.status) > + rsp_code = ibmvfc_get_err_result(&rsp_iu.cmd); > + > + if (rsp_code) { > if (fc_rsp->flags & FCP_RSP_LEN_VALID) > rsp_code = fc_rsp->data.info.rsp_code; > > _ -- Brian King Linux on Power Virtualization IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html