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 nf...@linux.vnet.ibm.com Nathan, sorry I didn't take care of this before I gave up r...@linux.ibm.com. Acked-by: Robert Jennings r...@pochix.net --- 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 r...@linux.vnet.ibm.com +M: Nathan Fontenot nf...@linux.vnet.ibm.com 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 r...@linux.vnet.ibm.com +IBM Power Virtual SCSI Device Drivers +M: Nathan Fontenot nf...@linux.vnet.ibm.com 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 brk...@linux.vnet.ibm.com +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/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 brk...@linux.vnet.ibm.com
Acked-by: Robert Jennings r...@linux.vnet.ibm.com
---
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 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 brk...@linux.vnet.ibm.com
Acked-by: Robert Jennings r...@linux.vnet.ibm.com
---
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, cancel_rc,
ibmvfc_dev_cancel_all_reset);
- reset_rc = ibmvfc_reset_device(sdev, IBMVFC_TARGET_RESET, target);
+ if (block_rc != FAST_IO_FAIL) {
+ starget_for_each_device(starget, cancel_rc,
ibmvfc_dev_cancel_all_reset);
+ reset_rc = ibmvfc_reset_device(sdev, IBMVFC_TARGET_RESET,
target);
+ } else
+ starget_for_each_device(starget, cancel_rc,
ibmvfc_dev_cancel_all_noreset);
if (!cancel_rc !reset_rc)
rc = ibmvfc_wait_for_ops(vhost, starget, ibmvfc_match_target);
+ if (block_rc
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 brk...@linux.vnet.ibm.com
Acked-by: Robert Jennings r...@linux.vnet.ibm.com
---
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 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 brk...@linux.vnet.ibm.com
Acked-by: Robert Jennings r...@linux.vnet.ibm.com
---
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 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 brk...@linux.vnet.ibm.com Acked-by: Robert Jennings r...@linux.vnet.ibm.com --- 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_VERSION1.0.10 -#define IBMVFC_DRIVER_DATE (August 24, 2012) +#define IBMVFC_DRIVER_VERSION1.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 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 brk...@linux.vnet.ibm.com Acked-by: Robert Jennings r...@linux.vnet.ibm.com --- 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: add module alias for ibmvscsic
On Sun, Jul 29, 2012 at 8:32 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Wed, 2012-07-18 at 18:49 +0200, o...@aepfle.de wrote: From: Olaf Hering o...@aepfle.de 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 benh@kernel.crashing. I've give this a quick test and I prefer this cleanup, it solves the initial problem nicely. James, please consider pulling this patch. Thanks. Acked-by: Robert Jennings r...@linux.vnet.ibm.com -- 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 b...@kernel.crashing.org 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 b...@kernel.crashing.org CC: sta...@vger.kernel.org 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 r...@linux.vnet.ibm.com --- 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: /sys/class/scsi_host/hostX/config doesn't show any information
On Sun, Jul 29, 2012 at 8:33 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: n Wed, 2012-07-18 at 18:49 +0200, o...@aepfle.de wrote: From: Linda Xie lx...@us.ibm.com 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 b...@kernel.crashing.org CC: sta...@vger.kernel.org Acked-by: Robert Jennings r...@linux.vnet.ibm.com 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
Re: [PATCH] scsi/ibmvscsi: add module alias for ibmvscsic
On Tue, Jul 31, 2012 at 11:20 AM, Brian King brk...@linux.vnet.ibm.com 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] 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 r...@linux.vnet.ibm.com --- 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 r...@linux.vnet.ibm.com +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 ipsli...@adaptec.com -- 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
[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_mgmt-task_tag = (u64) found_evt;
-
- sdev_printk(KERN_INFO, cmd-device, aborting command. lun 0x%lx, tag
0x%lx\n,
- tsk_mgmt-lun, tsk_mgmt-task_tag);
-
- evt-sync_srp = srp_rsp;
- init_completion(evt-comp
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_lock, flags);
+ } while (time_before(jiffies, wait_switch));
+
if (rsp_rc != 0) {
+ free_event_struct(found_evt-hostdata-pool, found_evt
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: [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 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 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(hostdata-host);
@@ -1483,7 +1500,7 @@
.eh_abort_handler = ibmvscsi_eh_abort_handler,
.eh_device_reset_handler = ibmvscsi_eh_device_reset_handler,
.cmd_per_lun = 16,
- .can_queue = 1, /* Updated after SRP_LOGIN */
+ .can_queue
[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 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
