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
