Re: [PATCH] Update Maintainers for IBM Power 842, vscsi, and vfc drivers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/09/2014 01:32 PM, Nathan Fontenot wrote: > Update the MAINTAINERS file to indicate the current maintainers > for the IBM Power 842 Compression driver, IBM Power Virtual SCSI > driver and the IBM Power Virtual FC Driver. > > Signed-off-by: Nathan Fontenot Nathan, sorry I didn't take care of this before I gave up r...@linux.ibm.com. Acked-by: Robert Jennings > --- MAINTAINERS | 16 +++- 1 file changed, 11 > insertions(+), 5 deletions(-) > > Index: linux/MAINTAINERS > === > > > - --- linux.orig/MAINTAINERS2014-04-08 14:14:57.0 -0500 > +++ linux/MAINTAINERS 2014-04-08 14:25:29.0 -0500 @@ > -4358,7 +4358,7 @@ F: drivers/crypto/nx/ > > IBM Power 842 compression accelerator -M: Robert Jennings > +M: Nathan Fontenot > S: Supported F: > drivers/crypto/nx/nx-842.c F: include/linux/nx842.h @@ -4374,12 > +4374,18 @@ S:Supported F:drivers/net/ethernet/ibm/ibmveth.* > > -IBM Power Virtual SCSI/FC Device Drivers -M: Robert Jennings > +IBM Power Virtual SCSI Device Drivers > +M: Nathan Fontenot L: > linux-scsi@vger.kernel.org S: Supported -F: drivers/scsi/ibmvscsi/ > -X: drivers/scsi/ibmvscsi/ibmvstgt.c +F: > drivers/scsi/ibmvscsi/ibmvscsi* +F: drivers/scsi/ibmvscsi/viosrp.h > + +IBM Power Virtual FC Device Drivers +M: Brian King > +L: linux-scsi@vger.kernel.org +S: > Supported +F: drivers/scsi/ibmvscsi/ibmvfc* > > IBM ServeRAID RAID DRIVER P: Jack Hammer > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTSA1/AAoJEHQMPZ7t8u1zbmwQAJXdfa1pObeOpukcuE924zGH jKxeDsFSLSrkxltO7vVMZ/y2LsKJtOaNXy1GzSqX7y3TbaDv2hWYi+GcI6/AlBl+ cgTtMBfYmSUpyuOxEdDzkj4KRx8cF02V0ajCcCqkwTqwvDw5JWBR3/sjDTAvYhes RzCv3Fl6F3Nf0ksTmmmUxlAmXUITH++4paYTZjrTW2N4YVUKVVzszr4K0dFqqqlW Ffi/brOXPF7ItfdL4/cEm5j2cZPh/zMLHJb24z67WMmzhCIUELzBjlEFRsBalaz/ X+/pKED01KqNiOpWOLR7FKWZlNkiHV2ZB9QxoUAsepI/s94TxOK94nNHiT6feunG 5WQjrwiWYC2ntG/arNITtz/t+Hs0OKsAvT5mCQ4W+e+UzHB/61zeN3p2/avrA0H6 A33yN2BeHkUyR3ra4uzhn+Sx2nOJvArMNGrnw+LAxrxg17ymE7qGvAqGmDExeTRl dLJv58B94QlchIgApuESQ4pLGvftvgT0bE/34DgWcTIBzQyTneTn5UTCOYR9h6hA wpDPmujlt5aEEb2Pm11pJSJ7lvY8MoPOqyc7aHWPkz7t6qfKEdJ8IquRFAyqi+/6 MeiinUCUW1Tp4gif+sy+Dc8UIsMIniUDeyA0//aWZCkA+CfF++P89WWdke/c2t+X otp+JW8ZqTgHZi1DUuiv =TcEI -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ibmvfc: Fix for offlining devices during error recovery
* Brian King (brk...@linux.vnet.ibm.com) wrote: > > This fixes an issue seen with devices getting marked offline > in a scenario where a VIOS was getting rebooted while a > client VFC adapter is in SCSI EH and prevents unnecessary > EH escalation in some scenarios. > > Signed-off-by: Brian King Acked-by: Robert Jennings > --- > > drivers/scsi/ibmvscsi/ibmvfc.c | 15 +-- > 1 file changed, 13 insertions(+), 2 deletions(-) > > diff -puN drivers/scsi/ibmvscsi/ibmvfc.c~ibmvfc_abort_during_reset > drivers/scsi/ibmvscsi/ibmvfc.c > --- linux/drivers/scsi/ibmvscsi/ibmvfc.c~ibmvfc_abort_during_reset > 2013-08-06 15:10:04.0 -0500 > +++ linux-bjking1/drivers/scsi/ibmvscsi/ibmvfc.c 2013-08-06 > 15:10:04.0 -0500 > @@ -2208,7 +2208,10 @@ static int ibmvfc_cancel_all(struct scsi > > if (rsp_rc != 0) { > sdev_printk(KERN_ERR, sdev, "Failed to send cancel event. > rc=%d\n", rsp_rc); > - return -EIO; > + /* If failure is received, the host adapter is most likely going > + through reset, return success so the caller will wait for the > command > + being cancelled to get returned */ > + return 0; > } > > sdev_printk(KERN_INFO, sdev, "Cancelling outstanding commands.\n"); > @@ -2221,7 +2224,15 @@ static int ibmvfc_cancel_all(struct scsi > > if (status != IBMVFC_MAD_SUCCESS) { > sdev_printk(KERN_WARNING, sdev, "Cancel failed with rc=%x\n", > status); > - return -EIO; > + switch (status) { > + case IBMVFC_MAD_DRIVER_FAILED: > + case IBMVFC_MAD_CRQ_ERROR: > + /* Host adapter most likely going through reset, return > success to > + the caller will wait for the command being cancelled > to get returned */ > + return 0; > + default: > + return -EIO; > + }; > } > > sdev_printk(KERN_INFO, sdev, "Successfully cancelled outstanding > commands\n"); > _ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] ibmvfc: Driver version 1.0.11
* Brian King (brk...@linux.vnet.ibm.com) wrote: > > Bump driver version to 1.0.11. > > > Signed-off-by: Brian King Acked-by: Robert Jennings > --- > > drivers/scsi/ibmvscsi/ibmvfc.h |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff -puN drivers/scsi/ibmvscsi/ibmvfc.h~ibmvfc_version_1_0_11 > drivers/scsi/ibmvscsi/ibmvfc.h > --- linux/drivers/scsi/ibmvscsi/ibmvfc.h~ibmvfc_version_1_0_11 > 2013-04-10 15:51:55.0 -0500 > +++ linux-bjking1/drivers/scsi/ibmvscsi/ibmvfc.h 2013-04-12 > 08:22:33.0 -0500 > @@ -29,8 +29,8 @@ > #include "viosrp.h" > > #define IBMVFC_NAME "ibmvfc" > -#define IBMVFC_DRIVER_VERSION"1.0.10" > -#define IBMVFC_DRIVER_DATE "(August 24, 2012)" > +#define IBMVFC_DRIVER_VERSION"1.0.11" > +#define IBMVFC_DRIVER_DATE "(April 12, 2013)" > > #define IBMVFC_DEFAULT_TIMEOUT 60 > #define IBMVFC_ADISC_CANCEL_TIMEOUT 45 > _ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] ibmvfc: Suppress ABTS if target gone
* Brian King (brk...@linux.vnet.ibm.com) wrote: > > Adds support for a new VIOS feature that allows ibmvfc to > optimize terminate_rport_io by telling the VIOS the target > is no longer accessible on the fabric and that it should > not send an ABTS out on the fabric to the device. > > Signed-off-by: Brian King Acked-by: Robert Jennings > --- > > drivers/scsi/ibmvscsi/ibmvfc.c | 13 +++-- > drivers/scsi/ibmvscsi/ibmvfc.h |3 ++- > 2 files changed, 9 insertions(+), 7 deletions(-) > > diff -puN drivers/scsi/ibmvscsi/ibmvfc.c~ibmvfc_supress_abts > drivers/scsi/ibmvscsi/ibmvfc.c > --- linux-2.6/drivers/scsi/ibmvscsi/ibmvfc.c~ibmvfc_supress_abts > 2013-01-25 14:29:11.0 -0600 > +++ linux-2.6-bjking1/drivers/scsi/ibmvscsi/ibmvfc.c 2013-01-25 > 14:29:24.0 -0600 > @@ -2190,10 +2190,12 @@ static int ibmvfc_cancel_all(struct scsi > tmf->common.length = sizeof(*tmf); > tmf->scsi_id = rport->port_id; > int_to_scsilun(sdev->lun, &tmf->lun); > + if (!(vhost->login_buf->resp.capabilities & > IBMVFC_CAN_SUPPRESS_ABTS)) > + type &= ~IBMVFC_TMF_SUPPRESS_ABTS; > if (vhost->state == IBMVFC_ACTIVE) > tmf->flags = (type | IBMVFC_TMF_LUA_VALID); > else > - tmf->flags = IBMVFC_TMF_LUA_VALID; > + tmf->flags = ((type & IBMVFC_TMF_SUPPRESS_ABTS) | > IBMVFC_TMF_LUA_VALID); > tmf->cancel_key = (unsigned long)sdev->hostdata; > tmf->my_cancel_key = (unsigned long)starget->hostdata; > > @@ -2402,7 +2404,7 @@ static int ibmvfc_eh_abort_handler(struc > cancel_rc = ibmvfc_cancel_all(sdev, IBMVFC_TMF_ABORT_TASK_SET); > ibmvfc_abort_task_set(sdev); > } else > - cancel_rc = ibmvfc_cancel_all(sdev, 0); > + cancel_rc = ibmvfc_cancel_all(sdev, IBMVFC_TMF_SUPPRESS_ABTS); > > if (!cancel_rc) > rc = ibmvfc_wait_for_ops(vhost, sdev, ibmvfc_match_lun); > @@ -2435,7 +2437,7 @@ static int ibmvfc_eh_device_reset_handle > cancel_rc = ibmvfc_cancel_all(sdev, IBMVFC_TMF_LUN_RESET); > reset_rc = ibmvfc_reset_device(sdev, IBMVFC_LUN_RESET, "LUN"); > } else > - cancel_rc = ibmvfc_cancel_all(sdev, 0); > + cancel_rc = ibmvfc_cancel_all(sdev, IBMVFC_TMF_SUPPRESS_ABTS); > > if (!cancel_rc && !reset_rc) > rc = ibmvfc_wait_for_ops(vhost, sdev, ibmvfc_match_lun); > @@ -2456,7 +2458,7 @@ static int ibmvfc_eh_device_reset_handle > static void ibmvfc_dev_cancel_all_noreset(struct scsi_device *sdev, void > *data) > { > unsigned long *rc = data; > - *rc |= ibmvfc_cancel_all(sdev, 0); > + *rc |= ibmvfc_cancel_all(sdev, IBMVFC_TMF_SUPPRESS_ABTS); > } > > /** > @@ -2547,8 +2549,7 @@ static void ibmvfc_terminate_rport_io(st > dev_rport = starget_to_rport(scsi_target(sdev)); > if (dev_rport != rport) > continue; > - ibmvfc_cancel_all(sdev, IBMVFC_TMF_ABORT_TASK_SET); > - ibmvfc_abort_task_set(sdev); > + ibmvfc_cancel_all(sdev, IBMVFC_TMF_SUPPRESS_ABTS); > } > > rc = ibmvfc_wait_for_ops(vhost, rport, ibmvfc_match_rport); > diff -puN drivers/scsi/ibmvscsi/ibmvfc.h~ibmvfc_supress_abts > drivers/scsi/ibmvscsi/ibmvfc.h > --- linux-2.6/drivers/scsi/ibmvscsi/ibmvfc.h~ibmvfc_supress_abts > 2013-01-25 14:29:11.0 -0600 > +++ linux-2.6-bjking1/drivers/scsi/ibmvscsi/ibmvfc.h 2013-01-25 > 14:29:11.0 -0600 > @@ -208,10 +208,10 @@ struct ibmvfc_npiv_login_resp { > u16 error; > u32 flags; > #define IBMVFC_NATIVE_FC 0x01 > -#define IBMVFC_CAN_FLUSH_ON_HALT 0x08 > u32 reserved; > u64 capabilities; > #define IBMVFC_CAN_FLUSH_ON_HALT 0x08 > +#define IBMVFC_CAN_SUPPRESS_ABTS 0x10 > u32 max_cmds; > u32 scsi_id_sz; > u64 max_dma_len; > @@ -351,6 +351,7 @@ struct ibmvfc_tmf { > #define IBMVFC_TMF_LUN_RESET 0x10 > #define IBMVFC_TMF_TGT_RESET 0x20 > #define IBMVFC_TMF_LUA_VALID 0x40 > +#define IBMVFC_TMF_SUPPRESS_ABTS 0x80 > u32 cancel_key; > u32 my_cancel_key; > u32 pad; > _ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] ibmvfc: Send cancel when link is down
* Brian King (brk...@linux.vnet.ibm.com) wrote: > > If attempting to abort requests due to a fail fail timeout > or error handling while the link is down, we cannot send > an abort out on the fabric. We can, however, send a cancel > to the VIOS. This fixes ibmvfc to send a cancel in this > case to prevent error handling from failing and/or > escalating. > > Signed-off-by: Brian King Acked-by: Robert Jennings > --- > > drivers/scsi/ibmvscsi/ibmvfc.c | 13 - > 1 file changed, 8 insertions(+), 5 deletions(-) > > diff -puN drivers/scsi/ibmvscsi/ibmvfc.c~ibmvfc_cancel_when_link_down > drivers/scsi/ibmvscsi/ibmvfc.c > --- linux-2.6/drivers/scsi/ibmvscsi/ibmvfc.c~ibmvfc_cancel_when_link_down > 2013-01-23 08:12:09.0 -0600 > +++ linux-2.6-bjking1/drivers/scsi/ibmvscsi/ibmvfc.c 2013-01-23 > 09:18:46.0 -0600 > @@ -2179,7 +2179,7 @@ static int ibmvfc_cancel_all(struct scsi > return 0; > } > > - if (vhost->state == IBMVFC_ACTIVE) { > + if (vhost->logged_in) { > evt = ibmvfc_get_event(vhost); > ibmvfc_init_event(evt, ibmvfc_sync_completion, > IBMVFC_MAD_FORMAT); > > @@ -2190,7 +2190,10 @@ static int ibmvfc_cancel_all(struct scsi > tmf->common.length = sizeof(*tmf); > tmf->scsi_id = rport->port_id; > int_to_scsilun(sdev->lun, &tmf->lun); > - tmf->flags = (type | IBMVFC_TMF_LUA_VALID); > + if (vhost->state == IBMVFC_ACTIVE) > + tmf->flags = (type | IBMVFC_TMF_LUA_VALID); > + else > + tmf->flags = IBMVFC_TMF_LUA_VALID; > tmf->cancel_key = (unsigned long)sdev->hostdata; > tmf->my_cancel_key = (unsigned long)starget->hostdata; > > @@ -2389,7 +2392,7 @@ static int ibmvfc_eh_abort_handler(struc > { > struct scsi_device *sdev = cmd->device; > struct ibmvfc_host *vhost = shost_priv(sdev->host); > - int cancel_rc, block_rc, abort_rc = 0; > + int cancel_rc, block_rc; > int rc = FAILED; > > ENTER; > @@ -2397,11 +2400,11 @@ static int ibmvfc_eh_abort_handler(struc > ibmvfc_wait_while_resetting(vhost); > if (block_rc != FAST_IO_FAIL) { > cancel_rc = ibmvfc_cancel_all(sdev, IBMVFC_TMF_ABORT_TASK_SET); > - abort_rc = ibmvfc_abort_task_set(sdev); > + ibmvfc_abort_task_set(sdev); > } else > cancel_rc = ibmvfc_cancel_all(sdev, 0); > > - if (!cancel_rc && !abort_rc) > + if (!cancel_rc) > rc = ibmvfc_wait_for_ops(vhost, sdev, ibmvfc_match_lun); > > if (block_rc == FAST_IO_FAIL && rc != FAILED) > _ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] ibmvfc: Support FAST_IO_FAIL in EH handlers
* Brian King (brk...@linux.vnet.ibm.com) wrote: > > Adds support for receiving FAST_IO_FAIL from fc_block_scsi_eh > when in error recovery. This fixes cases of devices being > taken offline when they are no longer accessible on the fabric, > preventing them from coming back online when the fabric recovers. > > Signed-off-by: Brian King Acked-by: Robert Jennings > --- > > drivers/scsi/ibmvscsi/ibmvfc.c | 69 > ++--- > 1 file changed, 52 insertions(+), 17 deletions(-) > > diff -puN drivers/scsi/ibmvscsi/ibmvfc.c~ibmvfc_block_scsi_eh_fast_fail > drivers/scsi/ibmvscsi/ibmvfc.c > --- linux-2.6/drivers/scsi/ibmvscsi/ibmvfc.c~ibmvfc_block_scsi_eh_fast_fail > 2013-01-22 07:51:01.0 -0600 > +++ linux-2.6-bjking1/drivers/scsi/ibmvscsi/ibmvfc.c 2013-02-06 > 14:56:06.0 -0600 > @@ -2383,24 +2383,30 @@ out: > * @cmd: scsi command to abort > * > * Returns: > - * SUCCESS / FAILED > + * SUCCESS / FAST_IO_FAIL / FAILED > **/ > static int ibmvfc_eh_abort_handler(struct scsi_cmnd *cmd) > { > struct scsi_device *sdev = cmd->device; > struct ibmvfc_host *vhost = shost_priv(sdev->host); > - int cancel_rc, abort_rc; > + int cancel_rc, block_rc, abort_rc = 0; > int rc = FAILED; > > ENTER; > - fc_block_scsi_eh(cmd); > + block_rc = fc_block_scsi_eh(cmd); > ibmvfc_wait_while_resetting(vhost); > - cancel_rc = ibmvfc_cancel_all(sdev, IBMVFC_TMF_ABORT_TASK_SET); > - abort_rc = ibmvfc_abort_task_set(sdev); > + if (block_rc != FAST_IO_FAIL) { > + cancel_rc = ibmvfc_cancel_all(sdev, IBMVFC_TMF_ABORT_TASK_SET); > + abort_rc = ibmvfc_abort_task_set(sdev); > + } else > + cancel_rc = ibmvfc_cancel_all(sdev, 0); > > if (!cancel_rc && !abort_rc) > rc = ibmvfc_wait_for_ops(vhost, sdev, ibmvfc_match_lun); > > + if (block_rc == FAST_IO_FAIL && rc != FAILED) > + rc = FAST_IO_FAIL; > + > LEAVE; > return rc; > } > @@ -2410,29 +2416,47 @@ static int ibmvfc_eh_abort_handler(struc > * @cmd: scsi command struct > * > * Returns: > - * SUCCESS / FAILED > + * SUCCESS / FAST_IO_FAIL / FAILED > **/ > static int ibmvfc_eh_device_reset_handler(struct scsi_cmnd *cmd) > { > struct scsi_device *sdev = cmd->device; > struct ibmvfc_host *vhost = shost_priv(sdev->host); > - int cancel_rc, reset_rc; > + int cancel_rc, block_rc, reset_rc = 0; > int rc = FAILED; > > ENTER; > - fc_block_scsi_eh(cmd); > + block_rc = fc_block_scsi_eh(cmd); > ibmvfc_wait_while_resetting(vhost); > - cancel_rc = ibmvfc_cancel_all(sdev, IBMVFC_TMF_LUN_RESET); > - reset_rc = ibmvfc_reset_device(sdev, IBMVFC_LUN_RESET, "LUN"); > + if (block_rc != FAST_IO_FAIL) { > + cancel_rc = ibmvfc_cancel_all(sdev, IBMVFC_TMF_LUN_RESET); > + reset_rc = ibmvfc_reset_device(sdev, IBMVFC_LUN_RESET, "LUN"); > + } else > + cancel_rc = ibmvfc_cancel_all(sdev, 0); > > if (!cancel_rc && !reset_rc) > rc = ibmvfc_wait_for_ops(vhost, sdev, ibmvfc_match_lun); > > + if (block_rc == FAST_IO_FAIL && rc != FAILED) > + rc = FAST_IO_FAIL; > + > LEAVE; > return rc; > } > > /** > + * ibmvfc_dev_cancel_all_noreset - Device iterated cancel all function > + * @sdev:scsi device struct > + * @data:return code > + * > + **/ > +static void ibmvfc_dev_cancel_all_noreset(struct scsi_device *sdev, void > *data) > +{ > + unsigned long *rc = data; > + *rc |= ibmvfc_cancel_all(sdev, 0); > +} > + > +/** > * ibmvfc_dev_cancel_all_reset - Device iterated cancel all function > * @sdev:scsi device struct > * @data:return code > @@ -2449,26 +2473,33 @@ static void ibmvfc_dev_cancel_all_reset( > * @cmd: scsi command struct > * > * Returns: > - * SUCCESS / FAILED > + * SUCCESS / FAST_IO_FAIL / FAILED > **/ > static int ibmvfc_eh_target_reset_handler(struct scsi_cmnd *cmd) > { > struct scsi_device *sdev = cmd->device; > struct ibmvfc_host *vhost = shost_priv(sdev->host); > struct scsi_target *starget = scsi_target(sdev); > - int reset_rc; > + int block_rc; > + int reset_rc = 0; > int rc = FAILED; > unsigned long cancel_rc = 0; > > ENTER; > - fc_block_scsi_eh(cmd); > + block_rc = fc_block_scsi_eh(cmd); > ibmvfc_wait_while_resetting(vhost); > - starget_for_each_device(starget, &a
Re: [PATCH 1/5] ibmvfc: Properly set cancel flags when cancelling abort
* Brian King (brk...@linux.vnet.ibm.com) wrote: > > The flags on a cancel operation are intended to indicate what, > if any, TMF will follow the cancel request. This fixes a case > where we were incorrectly setting the abort task set flag on > the cancel flag when we were cancelling an abort task set. > > Signed-off-by: Brian King Acked-by: Robert Jennings > --- > > drivers/scsi/ibmvscsi/ibmvfc.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff -puN drivers/scsi/ibmvscsi/ibmvfc.c~ibmvfc_abort_cancel_flags > drivers/scsi/ibmvscsi/ibmvfc.c > --- linux-2.6/drivers/scsi/ibmvscsi/ibmvfc.c~ibmvfc_abort_cancel_flags > 2013-01-22 07:44:23.0 -0600 > +++ linux-2.6-bjking1/drivers/scsi/ibmvscsi/ibmvfc.c 2013-01-22 > 07:44:56.0 -0600 > @@ -2327,7 +2327,7 @@ static int ibmvfc_abort_task_set(struct > timeout = wait_for_completion_timeout(&evt->comp, timeout); > > if (!timeout) { > - rc = ibmvfc_cancel_all(sdev, IBMVFC_TMF_ABORT_TASK_SET); > + rc = ibmvfc_cancel_all(sdev, 0); > if (!rc) { > rc = ibmvfc_wait_for_ops(vhost, sdev->hostdata, > ibmvfc_match_key); > if (rc == SUCCESS) > _ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ibmvscsi: Fix slave_configure deadlock
* Brian King (brk...@linux.vnet.ibm.com) wrote: > > No locks should be held when calling scsi_adjust_queue_depth > so drop the lock in slave_configure prior to calling it. > > Signed-off-by: Brian King Acked-by: Robert Jennings > --- > > drivers/scsi/ibmvscsi/ibmvscsi.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff -puN drivers/scsi/ibmvscsi/ibmvscsi.c~ibmvscsi_slave_configure_deadlock > drivers/scsi/ibmvscsi/ibmvscsi.c > --- linux/drivers/scsi/ibmvscsi/ibmvscsi.c~ibmvscsi_slave_configure_deadlock > 2013-03-06 16:36:26.0 -0600 > +++ linux-bjking1/drivers/scsi/ibmvscsi/ibmvscsi.c2013-03-06 > 16:36:26.0 -0600 > @@ -1899,8 +1899,8 @@ static int ibmvscsi_slave_configure(stru > sdev->allow_restart = 1; > blk_queue_rq_timeout(sdev->request_queue, 120 * HZ); > } > - scsi_adjust_queue_depth(sdev, 0, shost->cmd_per_lun); > spin_unlock_irqrestore(shost->host_lock, lock_flags); > + scsi_adjust_queue_depth(sdev, 0, shost->cmd_per_lun); > return 0; > } > > _ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scsi/ibmvscsi: /sys/class/scsi_host/hostX/config doesn't show any information
On Sun, Jul 29, 2012 at 8:33 PM, Benjamin Herrenschmidt wrote: > scsi/ibmvscsi: Fix host config length field overflow > > The length field in the host config packet is only 16-bit long, so > passing it 0x1 (64K which is our standard PAGE_SIZE) doesn't > work and result in an empty config from the server. > > Signed-off-by: Benjamin Herrenschmidt > CC: James, can this be added to your for-next branch so that we can also get this to the stable trees? Thanks. Acked-by: Robert Jennings > --- > > diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c > b/drivers/scsi/ibmvscsi/ibmvscsi.c > index 3a6c474..337e8b3 100644 > --- a/drivers/scsi/ibmvscsi/ibmvscsi.c > +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c > @@ -1541,6 +1541,9 @@ static int ibmvscsi_do_host_config(struct > ibmvscsi_host_data *hostdata, > > host_config = &evt_struct->iu.mad.host_config; > > + /* The transport length field is only 16-bit */ > + length = min(0x, length); > + > /* Set up a lun reset SRP command */ > memset(host_config, 0x00, sizeof(*host_config)); > host_config->common.type = VIOSRP_HOST_CONFIG_TYPE; > > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scsi/ibmvscsi: add module alias for ibmvscsic
On Sun, Jul 29, 2012 at 8:32 PM, Benjamin Herrenschmidt wrote: > On Wed, 2012-07-18 at 18:49 +0200, o...@aepfle.de wrote: >> From: Olaf Hering >> >> The driver is named ibmvscsic, at runtime it its name is advertised as >> ibmvscsi. For this reason mkinitrd wont pickup the driver properly. >> Reported by IBM during SLES11 beta testing: >> >> https://bugzilla.novell.com/show_bug.cgi?id=459933 >> LTC50724 > > So while this would work, I do wonder however whether we could instead > fix it by simplifying the whole thing as follow since iSeries is now > gone and so we don't need split backends anymore: > > scsi/ibmvscsi: Remove backend abstraction > > Now that the iSeries code is gone the backend abstraction > in this driver is no longer necessary, which allows us to > consolidate the driver in one file. > > The side effect is that the module name is now ibmvscsi.ko > which matches the driver hotplug name and fixes auto-load > issues. > > Signed-off-by: Benjamin Herrenschmidt -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scsi/ibmvscsi: /sys/class/scsi_host/hostX/config doesn't show any information
On Sun, Jul 29, 2012 at 8:33 PM, Benjamin Herrenschmidt wrote: > n Wed, 2012-07-18 at 18:49 +0200, o...@aepfle.de wrote: >> From: Linda Xie >> >> Expected result: >> It should show something like this: >> x1521p4:~ # cat /sys/class/scsi_host/host1/config >> PARTITIONNAME='x1521p4' >> NWSDNAME='X1521P4' >> HOSTNAME='X1521P4' >> DOMAINNAME='RCHLAND.IBM.COM' >> NAMESERVERS='9.10.244.100 9.10.244.200' >> >> Actual result: >> x1521p4:~ # cat /sys/class/scsi_host/host0/config >> x1521p4:~ # >> >> This patch changes the size of the buffer used for transfering config >> data to 4K. It was tested against 2.6.19-rc2 tree. >> >> Reported by IBM during SLES11 beta testing: > > So this patch just seems to blindly replace all occurrences of PAGE_SIZE > with HOST_PAGE_SIZE which is utterly wrong. Only one of those needs to > be changed, the one passed to ibmvscsi_do_host_config() which is what's > visible to the server, all the rest is just sysfs attributes and should > remain as-is. > > Additionally (not even mentioning that there is no explanation as to > what the real problem is anywhere in the changeset) I don't like the > fix. The root of the problem is that the MAD header has a 16-bit length > field, so writing 0x1 (64K PAGE_SIZE) into it doesn't quite work. > > So in addition to a better comment, I would suggest a fix more like > this: > > scsi/ibmvscsi: Fix host config length field overflow > > The length field in the host config packet is only 16-bit long, so > passing it 0x1 (64K which is our standard PAGE_SIZE) doesn't > work and result in an empty config from the server. > > Signed-off-by: Benjamin Herrenschmidt > CC: Acked-by: Robert Jennings Tested with an IBM i host and confirmed the fix. > --- > > diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c > b/drivers/scsi/ibmvscsi/ibmvscsi.c > index 3a6c474..337e8b3 100644 > --- a/drivers/scsi/ibmvscsi/ibmvscsi.c > +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c > @@ -1541,6 +1541,9 @@ static int ibmvscsi_do_host_config(struct > ibmvscsi_host_data *hostdata, > > host_config = &evt_struct->iu.mad.host_config; > > + /* The transport length field is only 16-bit */ > + length = min(0x, length); > + > /* Set up a lun reset SRP command */ > memset(host_config, 0x00, sizeof(*host_config)); > host_config->common.type = VIOSRP_HOST_CONFIG_TYPE; > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ibmvscsi: Add maintainer for IBM virtual SCSI/FC drivers
Add a MAINTAINERS entry for the IBM Power Virtual SCSI and FC device drivers. Signed-off-by: Robert Jennings --- MAINTAINERS |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index fb036a0..f441c46 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3425,6 +3425,13 @@ L: net...@vger.kernel.org S: Supported F: drivers/net/ethernet/ibm/ibmveth.* +IBM Power Virtual SCSI/FC Device Drivers +M: Robert Jennings +L: linux-scsi@vger.kernel.org +S: Supported +F: drivers/scsi/ibmvscsi/ +X: drivers/scsi/ibmvscsi/ibmvstgt.c + IBM ServeRAID RAID DRIVER P: Jack Hammer M: Dave Jeffery -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scsi/ibmvscsi: add module alias for ibmvscsic
On Tue, Jul 31, 2012 at 11:20 AM, Brian King wrote: > > On 07/30/2012 10:08 PM, Benjamin Herrenschmidt wrote: > > On Mon, 2012-07-30 at 21:06 +0200, Olaf Hering wrote: > >>> So while this would work, I do wonder however whether we could > >> instead > >>> fix it by simplifying the whole thing as follow since iSeries is now > >>> gone and so we don't need split backends anymore: > >>> > >>> scsi/ibmvscsi: Remove backend abstraction > >> > >> I cant that these things myself anymore. > > > > Brian, can somebody from your side own these ? > > I talked to Rob and he will be picking this up. Rob - can you submit > a patch to the maintainers file, adding yourself as the ibmvscsi > maintainer? I've submitted a patch for the MAINTAINERS file and I'll take a look at these patches to verify them as well. Thanks. --Rob Jennings -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] ibmvscsi: retry on H_DROPPED during send_crq
Currently the vscsi client driver responds to the case where H_SEND_CRQ returns H_DROPPED by returning DID_ERROR. If the server CRQ is full, either from mismanaging the request_limit or problems on the server, we should return SCSI_MLQUEUE_HOST_BUSY instead. The places where we are calling send_srp_login are not checking the return code. We could get H_DROPPED or H_CLOSED and in that case we should reset and retry. Signed-off-by: Robert Jennings <[EMAIL PROTECTED]> --- drivers/scsi/ibmvscsi/ibmvscsi.c | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-) Index: b/drivers/scsi/ibmvscsi/ibmvscsi.c === --- a/drivers/scsi/ibmvscsi/ibmvscsi.c +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c @@ -629,14 +629,15 @@ static int ibmvscsi_send_srp_event(struc list_del(&evt_struct->list); del_timer(&evt_struct->timer); - /* If send_crq returns H_CLOSED, return SCSI_MLQUEUE_HOST_BUSY. -* Firmware will send a CRQ with a transport event (0xFF) to -* tell this client what has happened to the transport. This -* will be handled in ibmvscsi_handle_crq() + /* If send_crq returns H_CLOSED or H_DROPPED, return +* SCSI_MLQUEUE_HOST_BUSY. Firmware will send a CRQ with +* a transport event (0xFF) to tell this client what has +* happened to the transport. This will be handled in +* ibmvscsi_handle_crq(). */ - if (rc == H_CLOSED) { + if (rc == H_CLOSED || rc == H_DROPPED) { dev_warn(hostdata->dev, "send warning. " -"Receive queue closed, will retry.\n"); +"Receive queue unavailable, will retry.\n"); goto send_busy; } dev_err(hostdata->dev, "send error %d\n", rc); @@ -1270,7 +1271,8 @@ void ibmvscsi_handle_crq(struct viosrp_c if ((rc = ibmvscsi_ops->send_crq(hostdata, 0xC002LL, 0)) == 0) { /* Now login */ - send_srp_login(hostdata); + if (send_srp_login(hostdata)) + ibmvscsi_reset_host(hostdata); } else { dev_err(hostdata->dev, "Unable to send init rsp. rc=%ld\n", rc); } @@ -1280,7 +1282,8 @@ void ibmvscsi_handle_crq(struct viosrp_c dev_info(hostdata->dev, "partner initialization complete\n"); /* Now login */ - send_srp_login(hostdata); + if (send_srp_login(hostdata)) + ibmvscsi_reset_host(hostdata); break; default: dev_err(hostdata->dev, "unknown crq message type: %d\n", crq->format); - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] [v2] ibmvscsi: requeue while CRQ closed
CRQ send errors that return with H_CLOSED should return with SCSI_MLQUEUE_HOST_BUSY until firmware alerts the client of a CRQ transport event. The transport event will either reinitialize and requeue the requests or fail and return IO with DID_ERROR. To avoid failing the eh_* functions while re-attaching to the server adapter this will retry for a period of time while ibmvscsi_send_srp_event returns SCSI_MLQUEUE_HOST_BUSY. In ibmvscsi_eh_abort_handler() the loop includes the search of the event list. The lock on the hostdata is dropped while waiting to try again after failing ibmvscsi_send_srp_event. The event could have been purged if a login was in progress when the function was called. In ibmvscsi_eh_device_reset_handler() the loop includes the call to get_event_struct() because a failing call to ibmvscsi_send_srp_event() will have freed the event struct. Signed-off-by: Robert Jennings <[EMAIL PROTECTED]> Signed-off-by: Brian King <[EMAIL PROTECTED]> --- drivers/scsi/ibmvscsi/ibmvscsi.c | 59 --- 1 file changed, 48 insertions(+), 11 deletions(-) Index: linux-2.6/drivers/scsi/ibmvscsi/ibmvscsi.c === --- linux-2.6.orig/drivers/scsi/ibmvscsi/ibmvscsi.c 2007-11-12 08:52:59.0 -0600 +++ linux-2.6/drivers/scsi/ibmvscsi/ibmvscsi.c 2007-11-12 08:54:17.0 -0600 @@ -629,6 +629,16 @@ list_del(&evt_struct->list); del_timer(&evt_struct->timer); + /* If send_crq returns H_CLOSED, return SCSI_MLQUEUE_HOST_BUSY. +* Firmware will send a CRQ with a transport event (0xFF) to +* tell this client what has happened to the transport. This +* will be handled in ibmvscsi_handle_crq() +*/ + if (rc == H_CLOSED) { + dev_warn(hostdata->dev, "send warning. " +"Receive queue closed, will retry.\n"); + goto send_busy; + } dev_err(hostdata->dev, "send error %d\n", rc); atomic_inc(&hostdata->request_limit); goto send_error; @@ -976,58 +986,74 @@ int rsp_rc; unsigned long flags; u16 lun = lun_from_dev(cmd->device); + unsigned long wait_switch = 0; /* First, find this command in our sent list so we can figure * out the correct tag */ spin_lock_irqsave(hostdata->host->host_lock, flags); - found_evt = NULL; - list_for_each_entry(tmp_evt, &hostdata->sent, list) { - if (tmp_evt->cmnd == cmd) { - found_evt = tmp_evt; - break; + wait_switch = jiffies + (init_timeout * HZ); + do { + found_evt = NULL; + list_for_each_entry(tmp_evt, &hostdata->sent, list) { + if (tmp_evt->cmnd == cmd) { + found_evt = tmp_evt; + break; + } } - } - if (!found_evt) { - spin_unlock_irqrestore(hostdata->host->host_lock, flags); - return SUCCESS; - } + if (!found_evt) { + spin_unlock_irqrestore(hostdata->host->host_lock, flags); + return SUCCESS; + } - evt = get_event_struct(&hostdata->pool); - if (evt == NULL) { - spin_unlock_irqrestore(hostdata->host->host_lock, flags); - sdev_printk(KERN_ERR, cmd->device, "failed to allocate abort event\n"); - return FAILED; - } + evt = get_event_struct(&hostdata->pool); + if (evt == NULL) { + spin_unlock_irqrestore(hostdata->host->host_lock, flags); + sdev_printk(KERN_ERR, cmd->device, + "failed to allocate abort event\n"); + return FAILED; + } - init_event_struct(evt, - sync_completion, - VIOSRP_SRP_FORMAT, - init_timeout); + init_event_struct(evt, + sync_completion, + VIOSRP_SRP_FORMAT, + init_timeout); - tsk_mgmt = &evt->iu.srp.tsk_mgmt; + tsk_mgmt = &evt->iu.srp.tsk_mgmt; - /* Set up an abort SRP command */ - memset(tsk_mgmt, 0x00, sizeof(*tsk_mgmt)); - tsk_mgmt->opcode = SRP_TSK_MGMT; - tsk_mgmt->lun = ((u64) lun) << 48; - tsk_mgmt->tsk_mgmt_func = SRP_TSK_ABORT_TASK; - tsk_mgm
[PATCH 1/1] ibmvscsi: requeue while CRQ closed
CRQ send errors that return with H_CLOSED should return with SCSI_MLQUEUE_HOST_BUSY until firmware alerts the client of a CRQ transport event. The transport event will either reinitialize and requeue the requests, or fail and return IO with DID_ERROR. To avoid failing the eh_* functions while re-attaching to the server adapter this will retry for a period of time while ibmvscsi_send_srp_event returns SCSI_MLQUEUE_HOST_BUSY. Signed-off-by: Robert Jennings <[EMAIL PROTECTED]> Signed-off-by: Brian King <[EMAIL PROTECTED]> --- drivers/scsi/ibmvscsi/ibmvscsi.c | 59 --- 1 file changed, 48 insertions(+), 11 deletions(-) Index: linux-2.6/drivers/scsi/ibmvscsi/ibmvscsi.c === --- linux-2.6.orig/drivers/scsi/ibmvscsi/ibmvscsi.c 2007-11-09 08:53:02.0 -0600 +++ linux-2.6/drivers/scsi/ibmvscsi/ibmvscsi.c 2007-11-09 08:53:36.0 -0600 @@ -629,6 +629,16 @@ list_del(&evt_struct->list); del_timer(&evt_struct->timer); + /* If send_crq returns H_CLOSED, return SCSI_MLQUEUE_HOST_BUSY. +* Firmware will send a CRQ with a transport event (0xFF) to +* tell this client what has happened to the transport. This +* will be handled in ibmvscsi_handle_crq() +*/ + if (rc == H_CLOSED) { + dev_warn(hostdata->dev, "send warning. " +"Receive queue closed, will retry.\n"); + goto send_busy; + } dev_err(hostdata->dev, "send error %d\n", rc); atomic_inc(&hostdata->request_limit); goto send_error; @@ -976,6 +986,7 @@ int rsp_rc; unsigned long flags; u16 lun = lun_from_dev(cmd->device); + unsigned long wait_switch = 0; /* First, find this command in our sent list so we can figure * out the correct tag @@ -1019,15 +1030,30 @@ tsk_mgmt->lun, tsk_mgmt->task_tag); evt->sync_srp = &srp_rsp; - init_completion(&evt->comp); - rsp_rc = ibmvscsi_send_srp_event(evt, hostdata, init_timeout * 2); - spin_unlock_irqrestore(hostdata->host->host_lock, flags); + + wait_switch = jiffies + (init_timeout * HZ); + do { + init_completion(&evt->comp); + rsp_rc = ibmvscsi_send_srp_event(evt, hostdata, init_timeout * 2); + + if (rsp_rc != SCSI_MLQUEUE_HOST_BUSY) + break; + + spin_unlock_irqrestore(hostdata->host->host_lock, flags); + msleep(10); + spin_lock_irqsave(hostdata->host->host_lock, flags); + } while (time_before(jiffies, wait_switch)); + if (rsp_rc != 0) { + free_event_struct(&found_evt->hostdata->pool, found_evt); + spin_unlock_irqrestore(hostdata->host->host_lock, flags); sdev_printk(KERN_ERR, cmd->device, "failed to send abort() event. rc=%d\n", rsp_rc); return FAILED; } + spin_unlock_irqrestore(hostdata->host->host_lock, flags); + wait_for_completion(&evt->comp); /* make sure we got a good response */ @@ -1099,6 +1125,7 @@ int rsp_rc; unsigned long flags; u16 lun = lun_from_dev(cmd->device); + unsigned long wait_switch = 0; spin_lock_irqsave(hostdata->host->host_lock, flags); evt = get_event_struct(&hostdata->pool); @@ -1125,9 +1152,20 @@ tsk_mgmt->lun); evt->sync_srp = &srp_rsp; - init_completion(&evt->comp); - rsp_rc = ibmvscsi_send_srp_event(evt, hostdata, init_timeout * 2); - spin_unlock_irqrestore(hostdata->host->host_lock, flags); + + wait_switch = jiffies + (init_timeout * HZ); + do { + init_completion(&evt->comp); + rsp_rc = ibmvscsi_send_srp_event(evt, hostdata, init_timeout * 2); + spin_unlock_irqrestore(hostdata->host->host_lock, flags); + + if (rsp_rc != SCSI_MLQUEUE_HOST_BUSY) + break; + + msleep(10); + spin_lock_irqsave(hostdata->host->host_lock, flags); + } while (time_before(jiffies, wait_switch)); + if (rsp_rc != 0) { sdev_printk(KERN_ERR, cmd->device, "failed to send reset event. rc=%d\n", rsp_rc); - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] [v2] ibmvscsi: Prevent IO during partner login
The prior version of this patch introduced a problem for the error handler routines. Calling ibmvscsi_eh_reset_device during a initialization/login would result in the reset failing without need. To avoid failing the eh_* functions while re-attaching to the server adapter this will retry for a period of time while ibmvscsi_send_srp_event returns SCSI_MLQUEUE_HOST_BUSY. By setting the request_limit in send_srp_login to 1 we allowed login requests to be sent to the server adapter. If this was not an initial login, but was a login after a disconnect with the server, other I/O requests could attempt to be processed before the login occured. To address this we can set the request_limit to 0 while doing the login and add an exception where login requests, along with task management events, are always passed to the server. There is a case where the request_limit had already reached 0 would result in all events being sent rather than returning SCSI_MLQUEUE_HOST_BUSY; this has also been fixed by this patch. Signed-off-by: Robert Jennings <[EMAIL PROTECTED]> Signed-off-by: Brian King <[EMAIL PROTECTED]> --- drivers/scsi/ibmvscsi/ibmvscsi.c | 59 --- 1 file changed, 48 insertions(+), 11 deletions(-) Index: b/drivers/scsi/ibmvscsi/ibmvscsi.c === --- a/drivers/scsi/ibmvscsi/ibmvscsi.c +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c @@ -556,7 +556,7 @@ static int ibmvscsi_send_srp_event(struc unsigned long timeout) { u64 *crq_as_u64 = (u64 *) &evt_struct->crq; - int request_status; + int request_status = 0; int rc; /* If we have exhausted our request limit, just fail this request, @@ -574,6 +574,13 @@ static int ibmvscsi_send_srp_event(struc if (request_status < -1) goto send_error; /* Otherwise, we may have run out of requests. */ + /* If request limit was 0 when we started the adapter is in the +* process of performing a login with the server adapter, or +* we may have run out of requests. +*/ + else if (request_status == -1 && +evt_struct->iu.srp.login_req.opcode != SRP_LOGIN_REQ) + goto send_busy; /* Abort and reset calls should make it through. * Nothing except abort and reset should use the last two * slots unless we had two or less to begin with. @@ -633,7 +640,8 @@ static int ibmvscsi_send_srp_event(struc unmap_cmd_data(&evt_struct->iu.srp.cmd, evt_struct, hostdata->dev); free_event_struct(&hostdata->pool, evt_struct); - atomic_inc(&hostdata->request_limit); + if (request_status != -1) + atomic_inc(&hostdata->request_limit); return SCSI_MLQUEUE_HOST_BUSY; send_error: @@ -927,10 +935,11 @@ static int send_srp_login(struct ibmvscs login->req_buf_fmt = SRP_BUF_FORMAT_DIRECT | SRP_BUF_FORMAT_INDIRECT; spin_lock_irqsave(hostdata->host->host_lock, flags); - /* Start out with a request limit of 1, since this is negotiated in -* the login request we are just sending + /* Start out with a request limit of 0, since this is negotiated in +* the login request we are just sending and login requests always +* get sent by the driver regardless of request_limit. */ - atomic_set(&hostdata->request_limit, 1); + atomic_set(&hostdata->request_limit, 0); rc = ibmvscsi_send_srp_event(evt_struct, hostdata, init_timeout * 2); spin_unlock_irqrestore(hostdata->host->host_lock, flags); @@ -967,6 +976,7 @@ static int ibmvscsi_eh_abort_handler(str int rsp_rc; unsigned long flags; u16 lun = lun_from_dev(cmd->device); + unsigned long wait_switch = 0; /* First, find this command in our sent list so we can figure * out the correct tag @@ -1010,15 +1020,30 @@ static int ibmvscsi_eh_abort_handler(str tsk_mgmt->lun, tsk_mgmt->task_tag); evt->sync_srp = &srp_rsp; - init_completion(&evt->comp); - rsp_rc = ibmvscsi_send_srp_event(evt, hostdata, init_timeout * 2); - spin_unlock_irqrestore(hostdata->host->host_lock, flags); + + wait_switch = jiffies + (init_timeout * HZ); + do { + init_completion(&evt->comp); + rsp_rc = ibmvscsi_send_srp_event(evt, hostdata, init_timeout * 2); + + if (rsp_rc != SCSI_MLQUEUE_HOST_BUSY) + break; + + spin_unlock_irqrestore(hostdata->host->host_lock, flags); + msleep(10); + spin_lock_irqsave(hostdata->host->host
[PATCH 1/1] ibmvscsi: Prevent IO during partner login
By setting the request_limit in send_srp_login to 1 we allowed login requests to be sent to the server adapter. If this was not an initial login, but was a login after a disconnect with the server, other I/O requests could attempt to be processed before the login occured. These I/O requests would fail, sometimes resulting in filesystems getting marked read-only. To address this we can set the request_limit to 0 while doing the login and add an exception where login requests, along with task management events, are always passed to the server. There is a case where the request_limit had already reached 0 would result in all events being sent rather than returning SCSI_MLQUEUE_HOST_BUSY; this has also been fixed by this patch. Signed-off-by: Robert Jennings <[EMAIL PROTECTED]> Signed-off-by: Brian King <[EMAIL PROTECTED]> --- drivers/scsi/ibmvscsi/ibmvscsi.c | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) Index: b/drivers/scsi/ibmvscsi/ibmvscsi.c === --- a/drivers/scsi/ibmvscsi/ibmvscsi.c +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c @@ -556,7 +556,7 @@ static int ibmvscsi_send_srp_event(struc unsigned long timeout) { u64 *crq_as_u64 = (u64 *) &evt_struct->crq; - int request_status; + int request_status = 0; int rc; /* If we have exhausted our request limit, just fail this request, @@ -574,6 +574,13 @@ static int ibmvscsi_send_srp_event(struc if (request_status < -1) goto send_error; /* Otherwise, we may have run out of requests. */ + /* If request limit was 0 when we started the adapter is in the +* process of performing a login with the server adapter, or +* we may have run out of requests. +*/ + else if (request_status == -1 && +evt_struct->iu.srp.login_req.opcode != SRP_LOGIN_REQ) + goto send_busy; /* Abort and reset calls should make it through. * Nothing except abort and reset should use the last two * slots unless we had two or less to begin with. @@ -633,7 +640,8 @@ static int ibmvscsi_send_srp_event(struc unmap_cmd_data(&evt_struct->iu.srp.cmd, evt_struct, hostdata->dev); free_event_struct(&hostdata->pool, evt_struct); - atomic_inc(&hostdata->request_limit); + if (request_status != -1) + atomic_inc(&hostdata->request_limit); return SCSI_MLQUEUE_HOST_BUSY; send_error: @@ -927,10 +935,11 @@ static int send_srp_login(struct ibmvscs login->req_buf_fmt = SRP_BUF_FORMAT_DIRECT | SRP_BUF_FORMAT_INDIRECT; spin_lock_irqsave(hostdata->host->host_lock, flags); - /* Start out with a request limit of 1, since this is negotiated in -* the login request we are just sending + /* Start out with a request limit of 0, since this is negotiated in +* the login request we are just sending and login requests always +* get sent by the driver regardless of request_limit. */ - atomic_set(&hostdata->request_limit, 1); + atomic_set(&hostdata->request_limit, 0); rc = ibmvscsi_send_srp_event(evt_struct, hostdata, init_timeout * 2); spin_unlock_irqrestore(hostdata->host->host_lock, flags); - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Stgt-devel] Question for pass-through target design
* Vladislav Bolkhovitin ([EMAIL PROTECTED]) wrote: > Robert Jennings wrote: > >>>>What I meant that is that the kernel tgt code (scsi_tgt*) receives > >>>>SCSI commands from one lld and send them to another lld instead of > >>>>sending them to user space. > >>> > >>>Although the approach of passing SCSI commands from a target LLD to an > >>>initiator one without any significant interventions from the target > >>>software looks to be nice and simple, you should realize how limited, > >>>unsafe and illegal it is, since it badly violates SCSI specs. > >> > >>I think that 'implemented cleanly' means that one scsi_host is assigned > >>to only one initiator. > > > >Vladislav listed a number of issues that are inherent in an implementation > >that does not have a 1:1 relationship of initiators to targets. The vscsi > >architecture defines the 1:1 relationship; it's imposible to have more > >than one initiator per target. > > Just few small notes: > > 1. As I already wrote, complete 1:1 relationship isn't practically > possible, because there is always a local access on the target (i.e. one > more initiator) and you can't disable it on practice. I was proposing a 1:1 relationship of initiator to target within the target framework for in-kernel pass-through. We would still have the case that local access on the target is possible; an administrator with privileges neccessary to create a target would have the responsibility to not then access the device locally. This is no different than if I create my root file system on /dev/sda1, I should not also 'dd' data to /dev/sda1 while the system is running. It's a bad idea, but nothing stops me; however this is something that only a root level user can do. This would be the same, these targets in pass-through have permissions by default that do not allow local access by non-root users. > 2. 1:1 relationship is a serious limitation for usage cases like an SPI > tape library serving backup for several servers on an FC net. Restricting the relationship to 1:1 would be for pass-through devices only, this would not necessarily dictate other target types which could be used for such cases. --Rob - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Stgt-devel] Question for pass-through target design
Missed a fair bit of this thread when it was first sent, bad mail filter I think (or pebkac). * FUJITA Tomonori ([EMAIL PROTECTED]) wrote: > From: Vladislav Bolkhovitin <[EMAIL PROTECTED]> > Subject: Re: [Stgt-devel] Question for pass-through target design > Date: Mon, 07 May 2007 18:24:44 +0400 > > > FUJITA Tomonori wrote: > > It looks like the pass-through target support is currently broken, at > > least as I've checked for ibmvstgt, but I think it's a general problem. > > I wanted to check my assumptions and get ideas. > > >>> > > >>>Yeah, unfortunately, it works only with the iSCSI target driver (which > > >>>runs in user space). > > >>> > > >>> > > >>> > > The code isn't allocating any memory to pass along to the sg code to > > store > > the result of a read or data for a write. Currently, dxferp for > > sg_io_hdr > > or dout_xferp/din_xferp for sg_io_v4 are assigned to the value of uaddr, > > which is set to 0 in kern_queue_cmd. With the pointer set to NULL, > > the pass-through target isn't going to function. Even if we had memory > > allocated, there isn't a means of getting data to be written via sg down > > this code path. > > > > What ideas are there as to how the data will get to user-space so that > > we can use sg? > > >>> > > >>>For kernel-space drivers, we don't need to go to user-space. We can do > > >>>the pass-through in kernel space. I talked with James about this last > > >>>year and he said that if the code is implemented cleanly, he would > > >>>merges it into mainline. > > >> > > >>We already have a pass-through in the kernel space for > > >>kernel space drivers. It is the scsi_tgt* code. > > > > > > > > > Could you elaborate more? > > > > > > What I meant that is that the kernel tgt code (scsi_tgt*) receives > > > SCSI commands from one lld and send them to another lld instead of > > > sending them to user space. > > > > Although the approach of passing SCSI commands from a target LLD to an > > initiator one without any significant interventions from the target > > software looks to be nice and simple, you should realize how limited, > > unsafe and illegal it is, since it badly violates SCSI specs. > > I think that 'implemented cleanly' means that one scsi_host is assigned > to only one initiator. Vladislav listed a number of issues that are inherent in an implementation that does not have a 1:1 relationship of initiators to targets. The vscsi architecture defines the 1:1 relationship; it's imposible to have more than one initiator per target. Are there any barriers that we will need to address if this were the case? Regards, Rob Jennings - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2][v3] ibmvscsi: add slave_configure to allow device restart
Fixed the kernel-doc comment for ibmvscsi_slave_configure. Thanks to Randy Dunlap for pointing this out. Adding a slave_configure function for the driver. Now the disks can be restarted by the scsi mid-layer when the are disconnected and reconnected. Signed-off-by: "Robert Jennings" <[EMAIL PROTECTED]> Signed-off-by: "Santiago Leon" <[EMAIL PROTECTED]> --- drivers/scsi/ibmvscsi/ibmvscsi.c | 22 ++ 1 file changed, 22 insertions(+) Index: b/drivers/scsi/ibmvscsi/ibmvscsi.c === --- a/drivers/scsi/ibmvscsi/ibmvscsi.c +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c @@ -1354,6 +1354,27 @@ return rc; } +/** + * ibmvscsi_slave_configure: Set the "allow_restart" flag for each disk. + * @sdev: struct scsi_device device to configure + * + * Enable allow_restart for a device if it is a disk. Adjust the + * queue_depth here also as is required by the documentation for + * struct scsi_host_template. + */ +static int ibmvscsi_slave_configure(struct scsi_device *sdev) +{ + struct Scsi_Host *shost = sdev->host; + unsigned long lock_flags = 0; + + spin_lock_irqsave(shost->host_lock, lock_flags); + if (sdev->type == TYPE_DISK) + sdev->allow_restart = 1; + scsi_adjust_queue_depth(sdev, 0, shost->cmd_per_lun); + spin_unlock_irqrestore(shost->host_lock, lock_flags); + return 0; +} + /* * sysfs attributes */ @@ -1499,6 +1520,7 @@ .queuecommand = ibmvscsi_queuecommand, .eh_abort_handler = ibmvscsi_eh_abort_handler, .eh_device_reset_handler = ibmvscsi_eh_device_reset_handler, + .slave_configure = ibmvscsi_slave_configure, .cmd_per_lun = 16, .can_queue = IBMVSCSI_MAX_REQUESTS_DEFAULT, .this_id = -1, - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ibmvscsi: add slave_configure to allow device restart
Fixed the kernel-doc comment for ibmvscsi_slave_configure. Thanks to Randy Dunlap for catching that. Adding a slave_configure function for the driver. Now the disks can be restarted by the scsi mid-layer when the are disconnected and reconnected. Signed-off-by: "Robert Jennings" <[EMAIL PROTECTED]> Signed-off-by: "Santiago Leon" <[EMAIL PROTECTED]> --- drivers/scsi/ibmvscsi/ibmvscsi.c | 23 +++ 1 file changed, 23 insertions(+) Index: b/drivers/scsi/ibmvscsi/ibmvscsi.c === --- a/drivers/scsi/ibmvscsi/ibmvscsi.c +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c @@ -1354,6 +1354,28 @@ return rc; } +/** + * ibmvscsi_slave_configure: Set the "allow_restart" flag for each disk. + * + * @sdev: struct scsi_device device to configure + * + * Enable allow_restart for a device if it is a disk. Adjust the + * queue_depth here also as is required by the documentation for + * struct scsi_host_template. + */ +static int ibmvscsi_slave_configure(struct scsi_device *sdev) +{ + struct Scsi_Host *shost = sdev->host; + unsigned long lock_flags = 0; + + spin_lock_irqsave(shost->host_lock, lock_flags); + if (sdev->type == TYPE_DISK) + sdev->allow_restart = 1; + scsi_adjust_queue_depth(sdev, 0, shost->cmd_per_lun); + spin_unlock_irqrestore(shost->host_lock, lock_flags); + return 0; +} + /* * sysfs attributes */ @@ -1499,6 +1521,7 @@ .queuecommand = ibmvscsi_queuecommand, .eh_abort_handler = ibmvscsi_eh_abort_handler, .eh_device_reset_handler = ibmvscsi_eh_device_reset_handler, + .slave_configure = ibmvscsi_slave_configure, .cmd_per_lun = 16, .can_queue = IBMVSCSI_MAX_REQUESTS_DEFAULT, .this_id = -1, - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ibmvscsi: add slave_configure to allow device restart
Adding a slave_configure function for the driver. Now the disks can be restarted by the scsi mid-layer when the are disconnected and reconnected. Signed-off-by: "Robert Jennings" <[EMAIL PROTECTED]> Signed-off-by: "Santiago Leon" <[EMAIL PROTECTED]> --- drivers/scsi/ibmvscsi/ibmvscsi.c | 18 ++ 1 file changed, 18 insertions(+) Index: b/drivers/scsi/ibmvscsi/ibmvscsi.c === --- a/drivers/scsi/ibmvscsi/ibmvscsi.c +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c @@ -1354,6 +1354,23 @@ return rc; } +/** + * ibmvscsi_slave_configure: For each slave device that is a disk, + * ensure that the "allow_restart" flag is enabled. + */ +static int ibmvscsi_slave_configure(struct scsi_device *sdev) +{ + struct Scsi_Host *shost = sdev->host; + unsigned long lock_flags = 0; + + spin_lock_irqsave(shost->host_lock, lock_flags); + if (sdev->type == TYPE_DISK) + sdev->allow_restart = 1; + scsi_adjust_queue_depth(sdev, 0, shost->cmd_per_lun); + spin_unlock_irqrestore(shost->host_lock, lock_flags); + return 0; +} + /* * sysfs attributes */ @@ -1499,6 +1516,7 @@ .queuecommand = ibmvscsi_queuecommand, .eh_abort_handler = ibmvscsi_eh_abort_handler, .eh_device_reset_handler = ibmvscsi_eh_device_reset_handler, + .slave_configure = ibmvscsi_slave_configure, .cmd_per_lun = 16, .can_queue = IBMVSCSI_MAX_REQUESTS_DEFAULT, .this_id = -1, - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ibmvscsi: allow for dynamic adjustment of server request_limit
The request limit calculations used previously on the client failed to mirror the state of the server. Additionally, when a value < 3 was provided there could be problems setting can_queue and handling abort and reset commands. Signed-off-by: "Robert Jennings" <[EMAIL PROTECTED]> Signed-off-by: "Santiago Leon <[EMAIL PROTECTED]> --- drivers/scsi/ibmvscsi/ibmvscsi.c | 58 +-- drivers/scsi/ibmvscsi/ibmvscsi.h |2 + 2 files changed, 40 insertions(+), 20 deletions(-) Index: b/drivers/scsi/ibmvscsi/ibmvscsi.c === --- a/drivers/scsi/ibmvscsi/ibmvscsi.c +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c @@ -85,7 +85,7 @@ static int max_id = 64; static int max_channel = 3; static int init_timeout = 5; -static int max_requests = 50; +static int max_requests = IBMVSCSI_MAX_REQUESTS_DEFAULT; #define IBMVSCSI_VERSION "1.5.8" @@ -538,7 +538,8 @@ int request_status; int rc; - /* If we have exhausted our request limit, just fail this request. + /* If we have exhausted our request limit, just fail this request, +* unless it is for a reset or abort. * Note that there are rare cases involving driver generated requests * (such as task management requests) that the mid layer may think we * can handle more requests (can_queue) when we actually can't @@ -551,9 +552,30 @@ */ if (request_status < -1) goto send_error; - /* Otherwise, if we have run out of requests */ - else if (request_status < 0) - goto send_busy; + /* Otherwise, we may have run out of requests. */ + /* Abort and reset calls should make it through. +* Nothing except abort and reset should use the last two +* slots unless we had two or less to begin with. +*/ + else if (request_status < 2 && +evt_struct->iu.srp.cmd.opcode != SRP_TSK_MGMT) { + /* In the case that we have less than two requests +* available, check the server limit as a combination +* of the request limit and the number of requests +* in-flight (the size of the send list). If the +* server limit is greater than 2, return busy so +* that the last two are reserved for reset and abort. +*/ + int server_limit = request_status; + struct srp_event_struct *tmp_evt; + + list_for_each_entry(tmp_evt, &hostdata->sent, list) { + server_limit++; + } + + if (server_limit > 2) + goto send_busy; + } } /* Copy the IU into the transfer area */ @@ -572,6 +594,7 @@ printk(KERN_ERR "ibmvscsi: send error %d\n", rc); + atomic_inc(&hostdata->request_limit); goto send_error; } @@ -581,7 +604,8 @@ unmap_cmd_data(&evt_struct->iu.srp.cmd, evt_struct, hostdata->dev); free_event_struct(&hostdata->pool, evt_struct); - return SCSI_MLQUEUE_HOST_BUSY; + atomic_inc(&hostdata->request_limit); + return SCSI_MLQUEUE_HOST_BUSY; send_error: unmap_cmd_data(&evt_struct->iu.srp.cmd, evt_struct, hostdata->dev); @@ -831,23 +855,16 @@ printk(KERN_INFO "ibmvscsi: SRP_LOGIN succeeded\n"); - if (evt_struct->xfer_iu->srp.login_rsp.req_lim_delta > - (max_requests - 2)) - evt_struct->xfer_iu->srp.login_rsp.req_lim_delta = - max_requests - 2; + if (evt_struct->xfer_iu->srp.login_rsp.req_lim_delta < 0) + printk(KERN_ERR "ibmvscsi: Invalid request_limit.\n"); - /* Now we know what the real request-limit is */ + /* Now we know what the real request-limit is. +* This value is set rather than added to request_limit because +* request_limit could have been set to -1 by this client. +*/ atomic_set(&hostdata->request_limit, evt_struct->xfer_iu->srp.login_rsp.req_lim_delta); - hostdata->host->can_queue = - evt_struct->xfer_iu->srp.login_rsp.req_lim_delta - 2; - - if (hostdata->host->can_queue < 1) { - printk(KERN_ERR "ibmvscsi: Invalid request_limit_delta\n"); - return; - } - /* If we had any pending I/Os, kick them */ scsi_unblock_requests(
[PATCH 0/2][resend] ibmvscsi: dynamic request_limit and device restart
James, Resending these patches for inclusion in your tree. There are two fixes for the ibmvscsi client driver in this set. - Dynamic request_limit The request_limit for the driver was not properly reflecting the value on the server side and could cause can_queue to be set to improper values (-1). The patch corrects this so that request_limit mirrors the value on the server and sets can_queue appropriately. - Device restart When a drive was removed from the server and then re-added the client would not be able to use that device. The device would return a unit attention and then not ready. By adding a slave_configure function we can set the "allow_restart" flag for all disk devices. Now devices will resume functioning when they are re-added to the server. --- - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] [v2] ibmvscsi: add slave_configure to allow device restart
The first version of this patch had the incorrect type for the lock_flags variable. Adding a slave_configure function for the driver. Now the disks can be restarted by the scsi mid-layer when the are disconnected and reconnected. Signed-off-by: "Robert Jennings" <[EMAIL PROTECTED]> --- drivers/scsi/ibmvscsi/ibmvscsi.c | 18 ++ 1 file changed, 18 insertions(+) Index: b/drivers/scsi/ibmvscsi/ibmvscsi.c === --- a/drivers/scsi/ibmvscsi/ibmvscsi.c +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c @@ -1354,6 +1354,23 @@ return rc; } +/** + * ibmvscsi_slave_configure: For each slave device that is a disk, + * ensure that the "allow_restart" flag is enabled. + */ +static int ibmvscsi_slave_configure(struct scsi_device *sdev) +{ + struct Scsi_Host *shost = sdev->host; + unsigned long lock_flags = 0; + + spin_lock_irqsave(shost->host_lock, lock_flags); + if (sdev->type == TYPE_DISK) + sdev->allow_restart = 1; + scsi_adjust_queue_depth(sdev, 0, shost->cmd_per_lun); + spin_unlock_irqrestore(shost->host_lock, lock_flags); + return 0; +} + /* * sysfs attributes */ @@ -1499,6 +1516,7 @@ .queuecommand = ibmvscsi_queuecommand, .eh_abort_handler = ibmvscsi_eh_abort_handler, .eh_device_reset_handler = ibmvscsi_eh_device_reset_handler, + .slave_configure = ibmvscsi_slave_configure, .cmd_per_lun = 16, .can_queue = IBMVSCSI_MAX_REQUESTS_DEFAULT, .this_id = -1, - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ibmvscsi: allow for dynamic adjustment of server request_limit
The request limit calculations used previously on the client failed to mirror the state of the server. Additionally, when a value < 3 was provided there could be problems setting can_queue and handling abort and reset commands. Signed-off-by: "Robert Jennings" <[EMAIL PROTECTED]> --- drivers/scsi/ibmvscsi/ibmvscsi.c | 58 +-- drivers/scsi/ibmvscsi/ibmvscsi.h |2 + 2 files changed, 40 insertions(+), 20 deletions(-) Index: ibmvscsi-23509/drivers/scsi/ibmvscsi/ibmvscsi.c === --- ibmvscsi-23509.orig/drivers/scsi/ibmvscsi/ibmvscsi.c +++ ibmvscsi-23509/drivers/scsi/ibmvscsi/ibmvscsi.c @@ -85,7 +85,7 @@ static int max_id = 64; static int max_channel = 3; static int init_timeout = 5; -static int max_requests = 50; +static int max_requests = IBMVSCSI_MAX_REQUESTS_DEFAULT; #define IBMVSCSI_VERSION "1.5.8" @@ -538,7 +538,8 @@ int request_status; int rc; - /* If we have exhausted our request limit, just fail this request. + /* If we have exhausted our request limit, just fail this request, +* unless it is for a reset or abort. * Note that there are rare cases involving driver generated requests * (such as task management requests) that the mid layer may think we * can handle more requests (can_queue) when we actually can't @@ -551,9 +552,30 @@ */ if (request_status < -1) goto send_error; - /* Otherwise, if we have run out of requests */ - else if (request_status < 0) - goto send_busy; + /* Otherwise, we may have run out of requests. */ + /* Abort and reset calls should make it through. +* Nothing except abort and reset should use the last two +* slots unless we had two or less to begin with. +*/ + else if (request_status < 2 && +evt_struct->iu.srp.cmd.opcode != SRP_TSK_MGMT) { + /* In the case that we have less than two requests +* available, check the server limit as a combination +* of the request limit and the number of requests +* in-flight (the size of the send list). If the +* server limit is greater than 2, return busy so +* that the last two are reserved for reset and abort. +*/ + int server_limit = request_status; + struct srp_event_struct *tmp_evt; + + list_for_each_entry(tmp_evt, &hostdata->sent, list) { + server_limit++; + } + + if (server_limit > 2) + goto send_busy; + } } /* Copy the IU into the transfer area */ @@ -572,6 +594,7 @@ printk(KERN_ERR "ibmvscsi: send error %d\n", rc); + atomic_inc(&hostdata->request_limit); goto send_error; } @@ -581,7 +604,8 @@ unmap_cmd_data(&evt_struct->iu.srp.cmd, evt_struct, hostdata->dev); free_event_struct(&hostdata->pool, evt_struct); - return SCSI_MLQUEUE_HOST_BUSY; + atomic_inc(&hostdata->request_limit); + return SCSI_MLQUEUE_HOST_BUSY; send_error: unmap_cmd_data(&evt_struct->iu.srp.cmd, evt_struct, hostdata->dev); @@ -831,23 +855,16 @@ printk(KERN_INFO "ibmvscsi: SRP_LOGIN succeeded\n"); - if (evt_struct->xfer_iu->srp.login_rsp.req_lim_delta > - (max_requests - 2)) - evt_struct->xfer_iu->srp.login_rsp.req_lim_delta = - max_requests - 2; + if (evt_struct->xfer_iu->srp.login_rsp.req_lim_delta < 0) + printk(KERN_ERR "ibmvscsi: Invalid request_limit.\n"); - /* Now we know what the real request-limit is */ + /* Now we know what the real request-limit is. +* This value is set rather than added to request_limit because +* request_limit could have been set to -1 by this client. +*/ atomic_set(&hostdata->request_limit, evt_struct->xfer_iu->srp.login_rsp.req_lim_delta); - hostdata->host->can_queue = - evt_struct->xfer_iu->srp.login_rsp.req_lim_delta - 2; - - if (hostdata->host->can_queue < 1) { - printk(KERN_ERR "ibmvscsi: Invalid request_limit_delta\n"); - return; - } - /* If we had any pending I/Os, kick them */ scsi_unblock_requests(hostdata->host); @@ -1483,7 +150
[PATCH 2/2] ibmvscsi: add slave_configure to allow device restart
Adding a slave_configure function for the driver. Now the disks can be restarted by the scsi mid-layer when the are disconnected and reconnected. Signed-off-by: "Robert Jennings" <[EMAIL PROTECTED]> --- drivers/scsi/ibmvscsi/ibmvscsi.c | 18 ++ 1 file changed, 18 insertions(+) Index: ibmvscsi-23509/drivers/scsi/ibmvscsi/ibmvscsi.c === --- ibmvscsi-23509.orig/drivers/scsi/ibmvscsi/ibmvscsi.c +++ ibmvscsi-23509/drivers/scsi/ibmvscsi/ibmvscsi.c @@ -1354,6 +1354,23 @@ return rc; } +/** + * ibmvscsi_slave_configure: For each slave device that is a disk, + * ensure that the "allow_restart" flag is enabled. + */ +static int ibmvscsi_slave_configure(struct scsi_device *sdev) +{ + struct Scsi_Host *shost = sdev->host; + int lock_flags = 0; + + spin_lock_irqsave(shost->host_lock, lock_flags); + if (sdev->type == TYPE_DISK) + sdev->allow_restart = 1; + scsi_adjust_queue_depth(sdev, 0, shost->cmd_per_lun); + spin_unlock_irqrestore(shost->host_lock, lock_flags); + return 0; +} + /* * sysfs attributes */ @@ -1499,6 +1516,7 @@ .queuecommand = ibmvscsi_queuecommand, .eh_abort_handler = ibmvscsi_eh_abort_handler, .eh_device_reset_handler = ibmvscsi_eh_device_reset_handler, + .slave_configure = ibmvscsi_slave_configure, .cmd_per_lun = 16, .can_queue = IBMVSCSI_MAX_REQUESTS_DEFAULT, .this_id = -1, - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] ibmvscsi: dynamic request_limit and device restart
There are two fixes for the ibmvscsi client driver in this set. - Dynamic request_limit The request_limit for the driver was not properly reflecting the value on the server side and could cause can_queue to be set to improper values (-1). The patch corrects this so that request_limit mirrors the value on the server and sets can_queue appropriately. - Device restart When a drive was removed from the server and then re-added the client would not be able to use that device. The device would return a unit attention and then not ready. By adding a slave_configure function we can set the "allow_restart" flag for all disk devices. Now devices will resume functioning when they are re-added to the server. --- - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html