Re: [PATCH V3 2/7] Drivers: scsi: storvsc: Set cmd_per_lun to reflect value supported by the Host
On 07/12/2014 06:48 PM, K. Y. Srinivasan wrote:
Set cmd_per_lun to reflect value supported by the Host.
In this version of the patch I have addressed comments from
Christoph Hellwig h...@infradead.org
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Cc: sta...@vger.kernel.org
---
drivers/scsi/storvsc_drv.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 8938b13..cebcef7 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1690,7 +1690,7 @@ static struct scsi_host_template scsi_driver = {
.slave_alloc = storvsc_device_alloc,
.slave_destroy =storvsc_device_destroy,
.slave_configure = storvsc_device_configure,
- .cmd_per_lun = 1,
+ .cmd_per_lun = 255,
.can_queue =STORVSC_MAX_IO_REQUESTS*STORVSC_MAX_TARGETS,
.this_id = -1,
/* no use setting to 0 since ll_blk_rw reset it to 1 */
Reviewed-by: Hannes Reinecke h...@suse.de
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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 V3 1/7] Drivers: scsi: storvsc: Change the limits to reflect the values on the host
On 07/12/2014 06:48 PM, K. Y. Srinivasan wrote:
Hyper-V hosts can support multiple targets and multiple channels and larger
number of
LUNs per target. Update the code to reflect this. With this patch we can
correctly
enumerate all the paths in a multi-path storage environment.
In this version of the patch I have addressed comments from
Christoph Hellwig h...@infradead.org
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Cc: sta...@vger.kernel.org
---
drivers/scsi/storvsc_drv.c | 47 +---
1 files changed, 31 insertions(+), 16 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 9969fa1..8938b13 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -330,17 +330,17 @@ static int storvsc_timeout = 180;
static void storvsc_on_channel_callback(void *context);
-/*
- * In Hyper-V, each port/path/target maps to 1 scsi host adapter. In
- * reality, the path/target is not used (ie always set to 0) so our
- * scsi host adapter essentially has 1 bus with 1 target that contains
- * up to 256 luns.
- */
-#define STORVSC_MAX_LUNS_PER_TARGET64
-#define STORVSC_MAX_TARGETS1
-#define STORVSC_MAX_CHANNELS 1
+#define STORVSC_MAX_LUNS_PER_TARGET255
+#define STORVSC_MAX_TARGETS2
+#define STORVSC_MAX_CHANNELS 8
+#define STORVSC_FC_MAX_LUNS_PER_TARGET 255
+#define STORVSC_FC_MAX_TARGETS 128
+#define STORVSC_FC_MAX_CHANNELS8
+#define STORVSC_IDE_MAX_LUNS_PER_TARGET64
+#define STORVSC_IDE_MAX_TARGETS1
+#define STORVSC_IDE_MAX_CHANNELS 1
struct storvsc_cmd_request {
struct list_head entry;
Limiting max_lun to 255 will make the driver to _not_ respond to
LUNs higher than that; ie Well-known LUN won't work here.
Also the SCSI stack will be using REPORT LUNS anyway since you're
advertising SPC-2 compliance. So your driver runs into issues if
Hyper-V would ever return more than 256 LUNs with the REPORT LUN
command or if any of the LUNs has an addressing scheme other than
'0x00'.
I would suggest to raise this to the technical limit (ie the largest
LUN which the _protocol_ supports) and let REPORT LUNS deal with the
actual LUNs.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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 V3 4/7] Drivers: scsi: storvsc: Fix a bug in handling VMBUS protocol version
On 07/12/2014 06:48 PM, K. Y. Srinivasan wrote:
Based on the negotiated VMBUS protocol version, we adjust the size of the
storage
protocol messages. The two sizes we currently handle are pre-win8 and post-win8.
In WS2012 R2, we are negotiating higher VMBUS protocol version than the win8
version. Make adjustments to correctly handle this.
In this version of the patch I have addressed comments from
Christoph Hellwig h...@infradead.org
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Cc: sta...@vger.kernel.org
---
drivers/scsi/storvsc_drv.c | 17 ++---
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 8f8847e..7e8a642 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1752,19 +1752,22 @@ static int storvsc_probe(struct hv_device *device,
* set state to properly communicate with the host.
*/
- if (vmbus_proto_version == VERSION_WIN8) {
- sense_buffer_size = POST_WIN7_STORVSC_SENSE_BUFFER_SIZE;
- vmscsi_size_delta = 0;
- vmstor_current_major = VMSTOR_WIN8_MAJOR;
- vmstor_current_minor = VMSTOR_WIN8_MINOR;
- } else {
+ switch (vmbus_proto_version) {
+ case VERSION_WS2008:
+ case VERSION_WIN7:
sense_buffer_size = PRE_WIN8_STORVSC_SENSE_BUFFER_SIZE;
vmscsi_size_delta = sizeof(struct vmscsi_win8_extension);
vmstor_current_major = VMSTOR_WIN7_MAJOR;
vmstor_current_minor = VMSTOR_WIN7_MINOR;
+ break;
+ default:
+ sense_buffer_size = POST_WIN7_STORVSC_SENSE_BUFFER_SIZE;
+ vmscsi_size_delta = 0;
+ vmstor_current_major = VMSTOR_WIN8_MAJOR;
+ vmstor_current_minor = VMSTOR_WIN8_MINOR;
+ break;
}
-
if (dev_id-driver_data == SFC_GUID)
scsi_driver.can_queue = (STORVSC_MAX_IO_REQUESTS *
STORVSC_FC_MAX_TARGETS);
Reviewed-by: Hannes Reinecke h...@suse.de
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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/7] Drivers: scsi: storvsc: Implement a timedout handler
On 07/12/2014 06:48 PM, K. Y. Srinivasan wrote:
On Azure, we have seen instances of unbounded I/O latencies. To deal with
this issue, implement handler that can reset the timeout. Note that the
host gaurantees that it will respond to each command that has been issued.
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Cc: sta...@vger.kernel.org
---
drivers/scsi/storvsc_drv.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 7e8a642..3516761 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -33,6 +33,7 @@
#include linux/device.h
#include linux/hyperv.h
#include linux/mempool.h
+#include linux/blkdev.h
#include scsi/scsi.h
#include scsi/scsi_cmnd.h
#include scsi/scsi_host.h
@@ -1518,6 +1519,14 @@ static int storvsc_host_reset_handler(struct scsi_cmnd
*scmnd)
return SUCCESS;
}
+static enum blk_eh_timer_return storvsc_timeout_handler(struct scsi_cmnd
*scmnd)
+{
+ /*
+* The host will respond; ask for more time.
+*/
+ return BLK_EH_RESET_TIMER;
+}
+
static bool storvsc_scsi_cmd_ok(struct scsi_cmnd *scmnd)
{
bool allowed = true;
@@ -1697,6 +1706,7 @@ static struct scsi_host_template scsi_driver = {
.bios_param = storvsc_get_chs,
.queuecommand = storvsc_queuecommand,
.eh_host_reset_handler =storvsc_host_reset_handler,
+ .eh_timed_out = storvsc_timeout_handler,
.slave_alloc = storvsc_device_alloc,
.slave_destroy =storvsc_device_destroy,
.slave_configure = storvsc_device_configure,
Reviewed-by: Hannes Reinecke h...@suse.de
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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 V3 3/7] Drivers: scsi: storvsc: Filter commands based on the storage protocol version
On 07/12/2014 06:48 PM, K. Y. Srinivasan wrote:
Going forward it is possible that some of the commands that are not currently
implemented will be implemented on future Windows hosts. Even if they are not
implemented, we are told the host will corrrectly handle unsupported
commands (by returning appropriate return code and sense information).
Make command filtering depend on the host version.
In this version of the patch I have addressed comments from
Christoph Hellwig h...@infradead.org
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Cc: sta...@vger.kernel.org
---
drivers/scsi/storvsc_drv.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index cebcef7..8f8847e 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1553,9 +1553,19 @@ static int storvsc_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *scmnd)
struct vmscsi_request *vm_srb;
struct stor_mem_pools *memp = scmnd-device-hostdata;
- if (!storvsc_scsi_cmd_ok(scmnd)) {
- scmnd-scsi_done(scmnd);
- return 0;
+ if (vmstor_current_major = VMSTOR_WIN8_MAJOR) {
+ /*
+* On legacy hosts filter unimplemented commands.
+* Future hosts are expected to correctly handle
+* unsupported commands. Furthermore, it is
+* possible that some of the currently
+* unsupported commands maybe supported in
+* future versions of the host.
+*/
+ if (!storvsc_scsi_cmd_ok(scmnd)) {
+ scmnd-scsi_done(scmnd);
+ return 0;
+ }
}
request_size = sizeof(struct storvsc_cmd_request);
Reviewed-by: Hannes Reinecke h...@suse.de
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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 7/7] drivers: scsi: storvsc: Correctly handle TEST_UNIT_READY failure
On 07/12/2014 06:48 PM, K. Y. Srinivasan wrote: On some Windows hosts on FC SANs, TEST_UNIT_READY can return SRB_STATUS_ERROR. Correctly handle this. Note that there is sufficient sense information to support scsi error handling even in this case. In this version of the patch I have addressed comments from Christoph Hellwig h...@infradead.org Signed-off-by: K. Y. Srinivasan k...@microsoft.com Cc: sta...@vger.kernel.org --- drivers/scsi/storvsc_drv.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index 9342ba4..29d0329 100644 --- a/drivers/scsi/storvsc_drv.c +++ b/drivers/scsi/storvsc_drv.c @@ -1018,6 +1018,13 @@ static void storvsc_handle_error(struct vmscsi_request *vm_srb, case ATA_12: set_host_byte(scmnd, DID_PASSTHROUGH); break; + /* +* On Some Windows hosts TEST_UNIT_READY command can return +* SRB_STATUS_ERROR, let the upper level code deal with it +* based on the sense information. +*/ + case TEST_UNIT_READY: + break; default: set_host_byte(scmnd, DID_TARGET_FAILURE); } Reviewed-by: Hannes Reinecke h...@suse.de Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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 6/7] drivers: scsi: storvsc: Set srb_flags in all cases
On 07/12/2014 06:48 PM, K. Y. Srinivasan wrote:
Correctly set SRB flags for all valid I/O directions. Some IHV drivers on the
Windows host require this. The host validates the command and SRB flags
prior to passing the command down to native driver stack.
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Cc: sta...@vger.kernel.org
---
drivers/scsi/storvsc_drv.c | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 3516761..9342ba4 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1599,26 +1599,24 @@ static int storvsc_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *scmnd)
vm_srb = cmd_request-vstor_packet.vm_srb;
vm_srb-win8_extension.time_out_value = 60;
+ vm_srb-win8_extension.srb_flags |=
+ (SRB_FLAGS_QUEUE_ACTION_ENABLE |
+ SRB_FLAGS_DISABLE_SYNCH_TRANSFER);
/* Build the SRB */
switch (scmnd-sc_data_direction) {
case DMA_TO_DEVICE:
vm_srb-data_in = WRITE_TYPE;
vm_srb-win8_extension.srb_flags |= SRB_FLAGS_DATA_OUT;
- vm_srb-win8_extension.srb_flags |=
- (SRB_FLAGS_QUEUE_ACTION_ENABLE |
- SRB_FLAGS_DISABLE_SYNCH_TRANSFER);
break;
case DMA_FROM_DEVICE:
vm_srb-data_in = READ_TYPE;
vm_srb-win8_extension.srb_flags |= SRB_FLAGS_DATA_IN;
- vm_srb-win8_extension.srb_flags |=
- (SRB_FLAGS_QUEUE_ACTION_ENABLE |
- SRB_FLAGS_DISABLE_SYNCH_TRANSFER);
break;
default:
vm_srb-data_in = UNKNOWN_TYPE;
- vm_srb-win8_extension.srb_flags = 0;
+ vm_srb-win8_extension.srb_flags |= (SRB_FLAGS_DATA_IN |
+SRB_FLAGS_DATA_OUT);
break;
}
Reviewed-by: Hannes Reinecke h...@suse.de
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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 v2] mpt2sas: delay scsi_add_host call to work with scsi-mq
In _scsih_probe, delay the call to scsi_add_host until the host has been
fully set up.
Otherwise, the default .can_queue value of 1 causes scsi-mq to set the block
layer request queue size to its minimum size, resulting in awful performance.
In _scsih_probe error handling, call mpt3sas_base_detach rather than
scsi_remove_host to properly clean up in reverse order.
In _scsih_remove, call scsi_remove_host earlier to clean up in reverse order.
Signed-off-by: Robert Elliott elli...@hp.com
Signed-off-by: Christoph Hellwig h...@lst.de
Signed-off-by: Nagalakshmi Nandigama nagalakshmi.nandig...@avagotech.com
Signed-off-by: Sreekanth Reddy sreekanth.re...@avagotech.com
---
drivers/scsi/mpt2sas/mpt2sas_base.c |2 +-
drivers/scsi/mpt2sas/mpt2sas_scsih.c | 25 -
2 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c
b/drivers/scsi/mpt2sas/mpt2sas_base.c
index b4b391d..20e2ff8 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -281,7 +281,7 @@ mpt2sas_base_stop_watchdog(struct MPT2SAS_ADAPTER *ioc)
ioc-fault_reset_work_q = NULL;
spin_unlock_irqrestore(ioc-ioc_reset_in_progress_lock, flags);
if (wq) {
- if (!cancel_delayed_work(ioc-fault_reset_work))
+ if (!cancel_delayed_work_sync(ioc-fault_reset_work))
flush_workqueue(wq);
destroy_workqueue(wq);
}
diff --git a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
index ed8b6c1..53c4764 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
@@ -2906,11 +2906,10 @@ _scsih_fw_event_cleanup_queue(struct MPT2SAS_ADAPTER
*ioc)
return;
list_for_each_entry_safe(fw_event, next, ioc-fw_event_list, list) {
- if (cancel_delayed_work(fw_event-delayed_work)) {
+ if (cancel_delayed_work_sync(fw_event-delayed_work)) {
_scsih_fw_event_free(ioc, fw_event);
continue;
}
- fw_event-cancel_pending_work = 1;
}
}
@@ -7514,7 +7513,7 @@ _firmware_event_work(struct work_struct *work)
struct MPT2SAS_ADAPTER *ioc = fw_event-ioc;
/* the queue is being flushed so ignore this event */
- if (ioc-remove_host || fw_event-cancel_pending_work ||
+ if (ioc-remove_host ||
ioc-pci_error_recovery) {
_scsih_fw_event_free(ioc, fw_event);
return;
@@ -7970,9 +7969,9 @@ _scsih_remove(struct pci_dev *pdev)
}
sas_remove_host(shost);
+ scsi_remove_host(shost);
mpt2sas_base_detach(ioc);
list_del(ioc-list);
- scsi_remove_host(shost);
scsi_host_put(shost);
}
@@ -8313,13 +8312,6 @@ _scsih_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
}
}
- if ((scsi_add_host(shost, pdev-dev))) {
- printk(MPT2SAS_ERR_FMT failure at %s:%d/%s()!\n,
- ioc-name, __FILE__, __LINE__, __func__);
- list_del(ioc-list);
- goto out_add_shost_fail;
- }
-
/* register EEDP capabilities with SCSI layer */
if (prot_mask)
scsi_host_set_prot(shost, prot_mask);
@@ -8361,16 +8353,23 @@ _scsih_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
}
} else
ioc-hide_drives = 0;
+
+ if ((scsi_add_host(shost, pdev-dev))) {
+ printk(MPT2SAS_ERR_FMT failure at %s:%d/%s()!\n,
+ ioc-name, __FILE__, __LINE__, __func__);
+ goto out_add_shost_fail;
+ }
+
scsi_scan_host(shost);
return 0;
+ out_add_shost_fail:
+ mpt2sas_base_detach(ioc);
out_attach_fail:
destroy_workqueue(ioc-firmware_event_thread);
out_thread_fail:
list_del(ioc-list);
- scsi_remove_host(shost);
- out_add_shost_fail:
scsi_host_put(shost);
return -ENODEV;
}
--
1.7.1
--
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 v2] mpt3sas: delay scsi_add_host call to work with scsi-mq
In _scsih_probe, delay the call to scsi_add_host until the host has been
fully set up.
Otherwise, the default .can_queue value of 1 causes scsi-mq to set the block
layer request queue size to its minimum size, resulting in awful performance.
In _scsih_probe error handling, call mpt3sas_base_detach rather than
scsi_remove_host to properly clean up in reverse order.
In _scsih_remove, call scsi_remove_host earlier to clean up in reverse order.
Signed-off-by: Robert Elliott elli...@hp.com
Signed-off-by: Christoph Hellwig h...@lst.de
Signed-off-by: Nagalakshmi Nandigama nagalakshmi.nandig...@avagotech.com
Signed-off-by: Sreekanth Reddy sreekanth.re...@avagotech.com
---
drivers/scsi/mpt3sas/mpt3sas_base.c |2 +-
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 26 --
2 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index cb5f879..b2817c7 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -266,7 +266,7 @@ mpt3sas_base_stop_watchdog(struct MPT3SAS_ADAPTER *ioc)
ioc-fault_reset_work_q = NULL;
spin_unlock_irqrestore(ioc-ioc_reset_in_progress_lock, flags);
if (wq) {
- if (!cancel_delayed_work(ioc-fault_reset_work))
+ if (!cancel_delayed_work_sync(ioc-fault_reset_work))
flush_workqueue(wq);
destroy_workqueue(wq);
}
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 21b50c1..7c830af 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -2586,11 +2586,10 @@ _scsih_fw_event_cleanup_queue(struct MPT3SAS_ADAPTER
*ioc)
return;
list_for_each_entry_safe(fw_event, next, ioc-fw_event_list, list) {
- if (cancel_delayed_work(fw_event-delayed_work)) {
+ if (cancel_delayed_work_sync(fw_event-delayed_work)) {
_scsih_fw_event_free(ioc, fw_event);
continue;
}
- fw_event-cancel_pending_work = 1;
}
}
@@ -7077,7 +7076,7 @@ static void
_mpt3sas_fw_work(struct MPT3SAS_ADAPTER *ioc, struct fw_event_work *fw_event)
{
/* the queue is being flushed so ignore this event */
- if (ioc-remove_host || fw_event-cancel_pending_work ||
+ if (ioc-remove_host ||
ioc-pci_error_recovery) {
_scsih_fw_event_free(ioc, fw_event);
return;
@@ -7482,9 +7481,9 @@ static void _scsih_remove(struct pci_dev *pdev)
}
sas_remove_host(shost);
+ scsi_remove_host(shost);
mpt3sas_base_detach(ioc);
list_del(ioc-list);
- scsi_remove_host(shost);
scsi_host_put(shost);
}
@@ -7852,13 +7851,6 @@ _scsih_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
}
}
- if ((scsi_add_host(shost, pdev-dev))) {
- pr_err(MPT3SAS_FMT failure at %s:%d/%s()!\n,
- ioc-name, __FILE__, __LINE__, __func__);
- list_del(ioc-list);
- goto out_add_shost_fail;
- }
-
/* register EEDP capabilities with SCSI layer */
if (prot_mask 0)
scsi_host_set_prot(shost, prot_mask);
@@ -7886,15 +7878,21 @@ _scsih_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
ioc-name, __FILE__, __LINE__, __func__);
goto out_attach_fail;
}
+ if ((scsi_add_host(shost, pdev-dev))) {
+ pr_err(MPT3SAS_FMT failure at %s:%d/%s()!\n,
+ ioc-name, __FILE__, __LINE__, __func__);
+ list_del(ioc-list);
+ goto out_add_shost_fail;
+ }
+
scsi_scan_host(shost);
return 0;
-
+out_add_shost_fail:
+ mpt3sas_base_detach(ioc);
out_attach_fail:
destroy_workqueue(ioc-firmware_event_thread);
out_thread_fail:
list_del(ioc-list);
- scsi_remove_host(shost);
- out_add_shost_fail:
scsi_host_put(shost);
return -ENODEV;
}
--
1.7.1
--
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] eata: remove driver_lock
port_detect is only called from the module_init routine and thus implicitly
serialized, so remove the driver lock which was held over potentially
sleeping function calls.
Signed-off-by: Christoph Hellwig h...@lst.de
Reported-by: Arthur Marsh arthur.ma...@internode.on.net
Tested-by: Arthur Marsh arthur.ma...@internode.on.net
---
drivers/scsi/eata.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/scsi/eata.c b/drivers/scsi/eata.c
index 03372cf..980898e 100644
--- a/drivers/scsi/eata.c
+++ b/drivers/scsi/eata.c
@@ -837,7 +837,6 @@ struct hostdata {
static struct Scsi_Host *sh[MAX_BOARDS];
static const char *driver_name = EATA;
static char sha[MAX_BOARDS];
-static DEFINE_SPINLOCK(driver_lock);
/* Initialize num_boards so that ihdlr can work while detect is in progress */
static unsigned int num_boards = MAX_BOARDS;
@@ -1097,8 +1096,6 @@ static int port_detect(unsigned long port_base, unsigned
int j,
goto fail;
}
- spin_lock_irq(driver_lock);
-
if (do_dma(port_base, 0, READ_CONFIG_PIO)) {
#if defined(DEBUG_DETECT)
printk(%s: detect, do_dma failed at 0x%03lx.\n, name,
@@ -1265,10 +1262,7 @@ static int port_detect(unsigned long port_base, unsigned
int j,
}
#endif
- spin_unlock_irq(driver_lock);
sh[j] = shost = scsi_register(tpnt, sizeof(struct hostdata));
- spin_lock_irq(driver_lock);
-
if (shost == NULL) {
printk(%s: unable to register host, detaching.\n, name);
goto freedma;
@@ -1345,8 +1339,6 @@ static int port_detect(unsigned long port_base, unsigned
int j,
else
sprintf(dma_name, DMA %u, dma_channel);
- spin_unlock_irq(driver_lock);
-
for (i = 0; i shost-can_queue; i++)
ha-cp[i].cp_dma_addr = pci_map_single(ha-pdev,
ha-cp[i],
@@ -1439,7 +1431,6 @@ static int port_detect(unsigned long port_base, unsigned
int j,
freeirq:
free_irq(irq, sha[j]);
freelock:
- spin_unlock_irq(driver_lock);
release_region(port_base, REGION_SIZE);
fail:
return 0;
--
1.9.1
--
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 V3 1/7] Drivers: scsi: storvsc: Change the limits to reflect the values on the host
On Mon, Jul 14, 2014 at 08:15:17AM +0200, Hannes Reinecke wrote: Limiting max_lun to 255 will make the driver to _not_ respond to LUNs higher than that; ie Well-known LUN won't work here. Also the SCSI stack will be using REPORT LUNS anyway since you're advertising SPC-2 compliance. So your driver runs into issues if Hyper-V would ever return more than 256 LUNs with the REPORT LUN command or if any of the LUNs has an addressing scheme other than '0x00'. I would suggest to raise this to the technical limit (ie the largest LUN which the _protocol_ supports) and let REPORT LUNS deal with the actual LUNs. I suspect hypverv doesn't support anything more. For now I'd be inclined to just put it in ASAP and if your suggestion works out fix it up later, although I'll wait a bit for more review feedback. -- 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: scsi: SCSI_FC_TGT_ATTRS
On Mon, Jul 14, 2014 at 10:29:04AM +0200, Paul Bolle wrote: 0) Commit 73685a458f2e (tgt: removal) landed in next-20140714. It states that the CONFIG_SCSI_TGT, CONFIG_SCSI_SRP_TGT_ATTRS and CONFIG_SCSI_FC_TGT_ATTRS kbuild variable[s] [...] are no longer needed. It removed the Kconfig entry for SCSI_SRP_TGT_ATTRS, but it left the entries for SCSI_TGT and SCSI_FC_TGT_ATTRS untouched. 1) Both SCSI_TGT and SCSI_FC_TGT_ATTRS appear to be unused after that commit. Is a patch to remove their Kconfig entries queued somewhere? We missed those two options, feel free to send a patch. -- 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
scsi: SCSI_FC_TGT_ATTRS
0) Commit 73685a458f2e (tgt: removal) landed in next-20140714. It states that the CONFIG_SCSI_TGT, CONFIG_SCSI_SRP_TGT_ATTRS and CONFIG_SCSI_FC_TGT_ATTRS kbuild variable[s] [...] are no longer needed. It removed the Kconfig entry for SCSI_SRP_TGT_ATTRS, but it left the entries for SCSI_TGT and SCSI_FC_TGT_ATTRS untouched. 1) Both SCSI_TGT and SCSI_FC_TGT_ATTRS appear to be unused after that commit. Is a patch to remove their Kconfig entries queued somewhere? Paul Bolle -- 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
mpt2sas and mpt3sas merge (again)
Back when the mpt3sas driver was first posted I suggested that it should be merged into mpt2sas, but my proposal didn't get much traction. Illumos has now produced a shared driver and shown that the difference are basically limited to a different S/G list format [1], and a quick experiment on the Linux drivers confirms this mostly - the additional differences are various smaller workarounds for specific hardware revisions. I think we'd all be served much better with a merged driver. [1] http://thread.gmane.org/gmane.os.illumos.devel/17341 -- 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 V3 1/7] Drivers: scsi: storvsc: Change the limits to reflect the values on the host
On 07/14/2014 10:30 AM, Christoph Hellwig wrote: On Mon, Jul 14, 2014 at 08:15:17AM +0200, Hannes Reinecke wrote: Limiting max_lun to 255 will make the driver to _not_ respond to LUNs higher than that; ie Well-known LUN won't work here. Also the SCSI stack will be using REPORT LUNS anyway since you're advertising SPC-2 compliance. So your driver runs into issues if Hyper-V would ever return more than 256 LUNs with the REPORT LUN command or if any of the LUNs has an addressing scheme other than '0x00'. I would suggest to raise this to the technical limit (ie the largest LUN which the _protocol_ supports) and let REPORT LUNS deal with the actual LUNs. I suspect hypverv doesn't support anything more. For now I'd be inclined to just put it in ASAP and if your suggestion works out fix it up later, although I'll wait a bit for more review feedback. Okay, that's fine by me. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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 V3 1/7] Drivers: scsi: storvsc: Change the limits to reflect the values on the host
On Mon, Jul 14, 2014 at 10:57:53AM +0200, Hannes Reinecke wrote: Okay, that's fine by me. Should I take this as a reviewed-by tag? -- 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 V3 1/7] Drivers: scsi: storvsc: Change the limits to reflect the values on the host
On 07/14/2014 11:00 AM, Christoph Hellwig wrote: On Mon, Jul 14, 2014 at 10:57:53AM +0200, Hannes Reinecke wrote: Okay, that's fine by me. Should I take this as a reviewed-by tag? Yes, please do. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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: scsi-mq V2
On 7/8/2014 5:48 PM, Christoph Hellwig wrote:
SNIP
I've pushed out a new scsi-mq.3 branch, which has been rebased on the
latest core-for-3.17 tree + the RFC: clean up command setup series
from June 29th. Robert Elliot found a problem with not fully zeroed
out UNMAP CDBs, which is fixed by the saner discard handling in that
series.
There is a new patch to factor the code from the above series for
blk-mq use, which I've attached below. Besides that the only changes
are minor merge fixups in the main blk-mq usage patch.
Hey Christoph Co,
I'd like to share some benchmarks I took on this patch set using iSER
initiator (+2 pre-submitted performance improvements) vs LIO iSER target.
I ran workloads I think are interesting use-cases (single LUN with 1,2,4
IO threads up to a fully occupied system doing IO to multiple LUNs).
Overall (except 2 strange anomalies) seems that scsi-mq patches
(use_blk_mq=N) roughly sustains traditional scsi performance.
On the other hand scsi-mq code path (use_blk_mq=Y) on its own clearly
shows better performance (tables below).
At first I too hit the aio issues discussed in this thread and converted
to scsi-mq.3-no-rebase for testing (thanks Doug Rob for raising it).
I must say that for some reason I get very low numbers for writes vs.
reads (writes perf stuck at ~20K IOPs per thread), this happens
on 3.16-rc2 even before scsi-mq patches. Did anyone step on this as well
or is it just a weird problem I'm having in my setup?
Anyway this is why my benchmarks shows only randread IO pattern (getting
familiar numbers). I need to figure out whats wrong
with IO writes - I'll start bisecting on this.
I also reviewed the patch set and at this point, I don't have any
comments. So you can add to the series:
Reviewed-by: Sagi Grimberg 'sa...@dev.mellanox.co.il' (or Tested-by -
whatever you choose).
I want to state that I tested a traditional iSER initiator - no scsi-mq
adoption at all.
I started looking into adopting scsi-mq to iSCSI/iSER recently and I
must that say the scsi-mq adoption is not so
trivial due to iSCSI session-wide CmdSN/StatSN ordering constraints
(can't just use more RDMA channels per connection...)
I'll be on vacation for the next couple of weeks, so I'll start a
separate thread to get the community input on this matter.
Results: table entries are KIOPS(CPU%)
3.16-rc2 (scsi-mq patches reverted)
Threads/LUN 1 24
#LUNs
1 231(6.5%) 355(18.5%) 337(31.1%)
2 446(13.6%) 673(37.2%) 654(49.8%)
4 594(25%)960(49.41%) 1165(99.3%)
81018(50.3%) 1563(99.6%) 1696(99.9%)
16 1660(86.5%) 1731(99.6%) 1710(100%)
3.16-rc2 (scsi-mq included, use_blk_mq=N)
Threads/LUN 1 24
#LUNs
1 231(6.5%) 351(18.5%) 337(31.4%)
2 446(13.6%) 660(37.3%) 647(50%)
4 591(25%)967(49.7%) 1136(98.1%)
81014(52.1%) 1296(100%) 1470(100%)
16 1741(100%) 1761(100%) 1853(100%)
3.16-rc2 (scsi-mq included, use_blk_mq=Y)
Threads/LUN 1 24
#LUNs
1 265(6.4%) 465(13.4%) 572(27.9%)
2 507(13.4%) 902(27.8%) 1034(45.9%)
4 697(25%) 1197(49.5%) 1477(98.6%)
81257(53.6%) 1856(98.7%) 1906(100%)
16 1991(100%) 2021(100%) 2020(100%)
Notes:
- IOPs measurements are the average of a 60 seconds runs.
- The CPU measurement is the total usage across all CPUs, In order
to understand per-CPU utilization value should be normalized to 16
cores.
- scsi_mq (use_blk_mq=N) has roughly the same performance as
traditional scsi IO path but I see an anomaly in test cases
{8 LUNs, 2/4 threads per LUN}. This may result in NUMA
misalignment for threads/interrupts – requires further
investigation.
- iSER initiator has no Multi-Queue awareness.
Testing environment:
- Initiator and target systems of 16 (8x2) cores (Hyperthreading
disabled).
- CPU model: Intel(R) Xeon(R) @ 2.60GHz
- Block Layer settings:
- scheduler=noop
- rq_affinity=1
- add_random=0
- nomerges=1
- Single FDR link between the target and initiator.
- Device model: Mellanox ConnectIB (the numbers are also familiar
with Mellanox ConnectX-3).
- MSIX interrupt vectors were spread across system cores.
- irqbalancer was disabled.
- scsi_host settings:
- cmd_per_lun=32 (default)
- can_queue=113 (default)
- In the multi-LUN test cases, each LUN exposed via different
scsi_host (iSCSI session).
Software:
- fio version: 2.0.13
- LIO iSER target (target-pending for-next)
- Null backing devices (NULLIO)
- Upstream based iSER initiator + internal pre-submitted
performance enhancements.
fio configuration:
rw=randread
bs=1k
iodepth=128
loops=1
ioengine=libaio
direct=1
invalidate=1
fsync_on_close=1
randrepeat=1
Re: mpt2sas and mpt3sas merge (again)
On 07/14/2014 10:35 AM, Christoph Hellwig wrote: Back when the mpt3sas driver was first posted I suggested that it should be merged into mpt2sas, but my proposal didn't get much traction. Illumos has now produced a shared driver and shown that the difference are basically limited to a different S/G list format [1], and a quick experiment on the Linux drivers confirms this mostly - the additional differences are various smaller workarounds for specific hardware revisions. I think we'd all be served much better with a merged driver. [1] http://thread.gmane.org/gmane.os.illumos.devel/17341 Please. Pretty please. I've started a merge myself, but then never found time to finalize it. Carrying three basically identical drivers just creates a maintenance overhead for everyone involved. The original idea of splitting the driver and just maintaining the latest has never really worked out; all fixes to the latest driver turned out to be applicable to the others, too. So it just increased the workload for the maintainer for no real gain. I would _strongly_ vote for it. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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 v2] scsi_debug: support scsi-mq, queues and locks
On 14-07-13 06:55 PM, Elliott, Robert (Server Storage) wrote:
-Original Message-
From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
ow...@vger.kernel.org] On Behalf Of Douglas Gilbert
Sent: Monday, 07 July, 2014 8:31 AM
To: SCSI development list
Subject: [PATCH v2] scsi_debug: support scsi-mq, queues and locks
Resend, looks like the list does not like html attachments.
This v2 patch is against Christoph's core-for-3.17 branch which
includes scsi-mq V2. Here is a link to a partially updated
version of the scsi_debug html page.
http://sg.danny.cz/scsi/sdebug26.html
Reviewed-by: Robert Elliott elli...@hp.com
A few minor concerns:
1. In scsi_debug_abort, does num_aborts needs to be atomic - can
the SCSI midlayer have concurrent .eh_abort_handler calls
in progress?
+static int scsi_debug_abort(struct scsi_cmnd *SCpnt)
+ ++num_aborts;
(I don't think this patch changes that from before...)
2. Same question for:
num_dev_resets
num_target_resets
num_bus_resets
num_host_resets
(I don't think this patch changes that from before...)
These are only informational (i.e. only consumed by
'cat /proc/scsi/scsi_debug/host_id'). This could be addressed
if more meat is added to the various .eh* entry points.
I'd look for help from Hannes (cc-ed) in this area.
3. schedule_resp includes this comment about the new TASK SET
FULL injection code:
+ /* if (tsf) simulate device reporting SCSI status of TASK SET FULL.
+* Might override existing CHECK CONDITION. */
If a TASK SET FULL is injected over a CHECK CONDITION/
UNIT ATTENTION created by check_readiness():
+ k = find_first_bit(devip-uas_bm, SDEBUG_NUM_UAS);
...
+ clear_bit(k, devip-uas_bm);
then it looks like that unit attention is lost forever.
Yes. The driver could make the distinction between SCSI
errors found early in device server processing (e.g. UAs
and Illegal Requests) from errors found later such as
Medium Error. But that adds complexity. The simplest
approach would be to skip TSF injection if any error is
being reported. In the rare case where the driver wants
to delay the response and has no space (i.e. an attempt
to exceed CAN_QUEUE/scsi_debug_max_queue) the error could
take precedence by skipping the delay and doing an
in-thread scsi_done() call.
4. In scsi_debug_show_info:
+ num_tgts=%d, shared (ram) size=%d MB, opts=0x%x,
and the modparam string describing that variable:
MODULE_PARM_DESC(dev_size_mb, size in MB of ram shared by devs(def=8));
the units are really MiB, not MB.
(I don't think this patch changes that from before...)
Yes.
5. For the UNMAP command, this modparam:
MODULE_PARM_DESC(lbprz, unmapped blocks return 0 on read (def=1));
always causes unmap_region to zero out the blocks:
if (scsi_debug_lbprz) {
memset(fake_storep +
lba * scsi_debug_sector_size, 0,
scsi_debug_sector_size *
scsi_debug_unmap_granularity);
}
That doesn't recognize that unmap requests via UNMAP commands are just
hints/suggestions, not mandatory. The same is true in ATA for the
DATA SET MANAGEMENT/TRIM command.
Zeroing out is fine for when resp_write_same is the caller of
unmap_region and either NDOB=1 or the Data-Out Buffer contains all
zeros - if WRITE SAME with UNMAP=1 doesn't cause an unmap, it
still writes all zeros to the blocks.
When resp_unmap is the caller, though, there is no guarantee that
the data will change.
Maybe another modparam should be included to cause the driver
to purposely ignore unmap requests? That might help more people
realize the danger in these commands. (e.g., I think mdraid
assumes UNMAP will result in zeros for RAID-5/6 volumes,
which means parity will be calculated wrong if the drive
doesn't really unmap).
(I don't think this patch changes that from before...)
I consider the PI+LBP parts of this driver to be maintained
by Martin Petersen (cc-ed) and I'm hoping he will look at
this area (and its lock safety) when the dust settles.
I noticed that scsi_debug is reporting SPC-3 compliance and
that probably should be upped to SPC-4.
In summary, I would like to leave this oversized v2 patch
as is. Then address some of the issues raised here as
a series of small, follow-up patches including some input
from those cc-ed in this reply.
BTW The driver documentation at:
http://sg.danny.cz/sg/sdebug26.html
has been updated reflecting this v2 patch. There was a temporary
version at: http://sg.danny.cz/scsi/sdebug26.html
which will be removed (or made a symlink to the former).
Doug Gilbert
--
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: mpt2sas and mpt3sas merge (again)
On Mon, 2014-07-14 at 11:22 +0200, Hannes Reinecke wrote: On 07/14/2014 10:35 AM, Christoph Hellwig wrote: Back when the mpt3sas driver was first posted I suggested that it should be merged into mpt2sas, but my proposal didn't get much traction. Illumos has now produced a shared driver and shown that the difference are basically limited to a different S/G list format [1], and a quick experiment on the Linux drivers confirms this mostly - the additional differences are various smaller workarounds for specific hardware revisions. I think we'd all be served much better with a merged driver. [1] http://thread.gmane.org/gmane.os.illumos.devel/17341 Please. Pretty please. I support the concept, since I think everyone told LSI at the time that splitting the drivers would become a maintenance nightmare. I've started a merge myself, but then never found time to finalize it. Carrying three basically identical drivers just creates a maintenance overhead for everyone involved. The original idea of splitting the driver and just maintaining the latest has never really worked out; all fixes to the latest driver turned out to be applicable to the others, too. So it just increased the workload for the maintainer for no real gain. I would _strongly_ vote for it. This isn't really a democracy; it's about who maintains the drivers and right now it's LSI (or whatever their new name is). One of the big reasons we don't have a lot of leverage with them is that they always seem to slide updates around upstream via the distros (often, it has to be admitted the DKM route), so if Red Hat, SUSE, Oracle and Canonical can agree not to accept LSI updates until the driver is done this way, we'd have a lot more leverage. James -- 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: mpt2sas and mpt3sas merge (again)
On 07/14/2014 04:17 PM, James Bottomley wrote: On Mon, 2014-07-14 at 11:22 +0200, Hannes Reinecke wrote: On 07/14/2014 10:35 AM, Christoph Hellwig wrote: Back when the mpt3sas driver was first posted I suggested that it should be merged into mpt2sas, but my proposal didn't get much traction. Illumos has now produced a shared driver and shown that the difference are basically limited to a different S/G list format [1], and a quick experiment on the Linux drivers confirms this mostly - the additional differences are various smaller workarounds for specific hardware revisions. I think we'd all be served much better with a merged driver. [1] http://thread.gmane.org/gmane.os.illumos.devel/17341 Please. Pretty please. I support the concept, since I think everyone told LSI at the time that splitting the drivers would become a maintenance nightmare. I've started a merge myself, but then never found time to finalize it. Carrying three basically identical drivers just creates a maintenance overhead for everyone involved. The original idea of splitting the driver and just maintaining the latest has never really worked out; all fixes to the latest driver turned out to be applicable to the others, too. So it just increased the workload for the maintainer for no real gain. I would _strongly_ vote for it. This isn't really a democracy; it's about who maintains the drivers and right now it's LSI (or whatever their new name is). One of the big reasons we don't have a lot of leverage with them is that they always seem to slide updates around upstream via the distros (often, it has to be admitted the DKM route), so if Red Hat, SUSE, Oracle and Canonical can agree not to accept LSI updates until the driver is done this way, we'd have a lot more leverage. Hmm. We (as SUSE) have been striving to have a 'upstream first' policy. IE for any new release the drivers have to be upstream before we consider including it in our release. This is most certainly true for the upcoming SLE-12 release, and also has been enforced for the current SLES11 SP3 release. This is official company policy, and has been communicated to all our partners. We do accept driver updates (ie patches which are not upstream ATM), but only on the understanding that the vendor will have to push the patches upstream eventually. If they don't the patches will be kicked out of the next release. (Which is what happened to the mptsas v4 release; it never made it upstream and so got dropped from SLE-12). However, this cuts both ways; we cannot go and tell our partners to change the driver if upstream hasn't done it first. So the push has to come from us (as the linux kernel developers); after all, we should make the decision what goes in and what doesn't. If a driver is in a bad state (and it's actually us which defines the 'bad state') we should be discussing on how we would like to improve things. If the maintainer proves unwilling to implement our suggestions we can always go ahead and implement a separate driver. Look what happened to hpsa; this was the pretty much the showcase on how it should be done: Tomo went ahead and re-implemented the cciss driver, and eventually HP adopted it as their main driver. I agree that was pretty much the optimal case, though:-) Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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: mpt2sas and mpt3sas merge (again)
On Mon, 2014-07-14 at 16:39 +0200, Hannes Reinecke wrote: On 07/14/2014 04:17 PM, James Bottomley wrote: On Mon, 2014-07-14 at 11:22 +0200, Hannes Reinecke wrote: On 07/14/2014 10:35 AM, Christoph Hellwig wrote: Back when the mpt3sas driver was first posted I suggested that it should be merged into mpt2sas, but my proposal didn't get much traction. Illumos has now produced a shared driver and shown that the difference are basically limited to a different S/G list format [1], and a quick experiment on the Linux drivers confirms this mostly - the additional differences are various smaller workarounds for specific hardware revisions. I think we'd all be served much better with a merged driver. [1] http://thread.gmane.org/gmane.os.illumos.devel/17341 Please. Pretty please. I support the concept, since I think everyone told LSI at the time that splitting the drivers would become a maintenance nightmare. I've started a merge myself, but then never found time to finalize it. Carrying three basically identical drivers just creates a maintenance overhead for everyone involved. The original idea of splitting the driver and just maintaining the latest has never really worked out; all fixes to the latest driver turned out to be applicable to the others, too. So it just increased the workload for the maintainer for no real gain. I would _strongly_ vote for it. This isn't really a democracy; it's about who maintains the drivers and right now it's LSI (or whatever their new name is). One of the big reasons we don't have a lot of leverage with them is that they always seem to slide updates around upstream via the distros (often, it has to be admitted the DKM route), so if Red Hat, SUSE, Oracle and Canonical can agree not to accept LSI updates until the driver is done this way, we'd have a lot more leverage. Hmm. We (as SUSE) have been striving to have a 'upstream first' policy. IE for any new release the drivers have to be upstream before we consider including it in our release. This is most certainly true for the upcoming SLE-12 release, and also has been enforced for the current SLES11 SP3 release. This is official company policy, and has been communicated to all our partners. We do accept driver updates (ie patches which are not upstream ATM), but only on the understanding that the vendor will have to push the patches upstream eventually. If they don't the patches will be kicked out of the next release. (Which is what happened to the mptsas v4 release; it never made it upstream and so got dropped from SLE-12). However, this cuts both ways; we cannot go and tell our partners to change the driver if upstream hasn't done it first. I'm not saying we need to go into why this happened. Just that I'd like community agreement amongst the distros before trying to force the issue. I accept that the distros respond to their TAMs as well as the community, but if there's going to be TAM push back, I'd at least like to hear about it so I can have a word with the relevant people. So the push has to come from us (as the linux kernel developers); after all, we should make the decision what goes in and what doesn't. If a driver is in a bad state (and it's actually us which defines the 'bad state') we should be discussing on how we would like to improve things. If the maintainer proves unwilling to implement our suggestions we can always go ahead and implement a separate driver. Then we need a maintainer of that driver ... remember this is a fat firmware driver with a proprietary interface. It's hard to maintain and update without docs ... unless you happen to have an NDA copy? Look what happened to hpsa; this was the pretty much the showcase on how it should be done: Tomo went ahead and re-implemented the cciss driver, and eventually HP adopted it as their main driver. I agree that was pretty much the optimal case, though:-) The best is to get LSI to agree, yes ... hence the need for unanimity. James -- 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: [RFC 0/2] target: userspace pass-through backend
On Tue, Jul 1, 2014 at 9:11 PM, Andy Grover agro...@redhat.com wrote: Shaohua Li wrote an initial implementation of this, late last year[1]. Starting from that, I started working on some alternate implementation choices, and ended up with something rather different. Please take a look and let me know what you think. Patch 1 is a design and overview doc, and patch 2 is the actual code, along with implementation rationale. Thanks -- Andy [1] http://thread.gmane.org/gmane.linux.scsi.target.devel/5044 Andy Grover (2): target: Add documentation on the target userspace pass-through driver target: Add a user-passthrough backstore Documentation/target/tcmu-design.txt | 210 +++ drivers/target/Kconfig |5 + drivers/target/Makefile|1 + drivers/target/target_core_transport.c |4 + drivers/target/target_core_user.c | 1078 drivers/target/target_core_user.h | 126 6 files changed, 1424 insertions(+) create mode 100644 Documentation/target/tcmu-design.txt create mode 100644 drivers/target/target_core_user.c create mode 100644 drivers/target/target_core_user.h Hi Andy, Just wanted to let you know that a userspace backstore would potentially be useful for QEMU. QEMU supports a number of disk image formats (VMDK, VHDX, qcow2, and more). Make these available as SCSI LUNs on the host or to remote SCSI initiators is cool. We currently have a tool called qemu-nbd that exports disk images using the Network Block Device protocol. Your userspace backstore provides other options like iSCSI target or loopback access on the host. I took a quick look at the patch and imagine it's not hard to hook up to QEMU. Looks promising! Stefan -- 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: mpt2sas and mpt3sas merge (again)
On 07/14/2014 04:57 PM, James Bottomley wrote: On Mon, 2014-07-14 at 16:39 +0200, Hannes Reinecke wrote: On 07/14/2014 04:17 PM, James Bottomley wrote: [ .. ] This isn't really a democracy; it's about who maintains the drivers and right now it's LSI (or whatever their new name is). One of the big reasons we don't have a lot of leverage with them is that they always seem to slide updates around upstream via the distros (often, it has to be admitted the DKM route), so if Red Hat, SUSE, Oracle and Canonical can agree not to accept LSI updates until the driver is done this way, we'd have a lot more leverage. Hmm. We (as SUSE) have been striving to have a 'upstream first' policy. IE for any new release the drivers have to be upstream before we consider including it in our release. This is most certainly true for the upcoming SLE-12 release, and also has been enforced for the current SLES11 SP3 release. This is official company policy, and has been communicated to all our partners. We do accept driver updates (ie patches which are not upstream ATM), but only on the understanding that the vendor will have to push the patches upstream eventually. If they don't the patches will be kicked out of the next release. (Which is what happened to the mptsas v4 release; it never made it upstream and so got dropped from SLE-12). However, this cuts both ways; we cannot go and tell our partners to change the driver if upstream hasn't done it first. I'm not saying we need to go into why this happened. Just that I'd like community agreement amongst the distros before trying to force the issue. I accept that the distros respond to their TAMs as well as the community, but if there's going to be TAM push back, I'd at least like to hear about it so I can have a word with the relevant people. So the push has to come from us (as the linux kernel developers); after all, we should make the decision what goes in and what doesn't. If a driver is in a bad state (and it's actually us which defines the 'bad state') we should be discussing on how we would like to improve things. If the maintainer proves unwilling to implement our suggestions we can always go ahead and implement a separate driver. Then we need a maintainer of that driver ... remember this is a fat firmware driver with a proprietary interface. It's hard to maintain and update without docs ... unless you happen to have an NDA copy? Hmm. _if_ the driver is similar to the original one (which was the idea) it should be reasonably trivial to port the latest changes from the original driver to the merged one. Look what happened to hpsa; this was the pretty much the showcase on how it should be done: Tomo went ahead and re-implemented the cciss driver, and eventually HP adopted it as their main driver. I agree that was pretty much the optimal case, though:-) The best is to get LSI to agree, yes ... hence the need for unanimity. Agreed. Let's see what LSI has to say here. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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: mpt2sas and mpt3sas merge (again)
On 07/14/2014 05:10 PM, Hannes Reinecke wrote: On 07/14/2014 04:57 PM, James Bottomley wrote: On Mon, 2014-07-14 at 16:39 +0200, Hannes Reinecke wrote: On 07/14/2014 04:17 PM, James Bottomley wrote: [ .. ] This isn't really a democracy; it's about who maintains the drivers and right now it's LSI (or whatever their new name is). One of the big reasons we don't have a lot of leverage with them is that they always seem to slide updates around upstream via the distros (often, it has to be admitted the DKM route), so if Red Hat, SUSE, Oracle and Canonical can agree not to accept LSI updates until the driver is done this way, we'd have a lot more leverage. We have a strong 'upstream first' policy in our releases for new drivers and for new patches, so in theory upstream could use the force, I still prefer a softer way that is discussing it with Avago(LSI) and getting their ack. Hmm. We (as SUSE) have been striving to have a 'upstream first' policy. IE for any new release the drivers have to be upstream before we consider including it in our release. This is most certainly true for the upcoming SLE-12 release, and also has been enforced for the current SLES11 SP3 release. This is official company policy, and has been communicated to all our partners. We do accept driver updates (ie patches which are not upstream ATM), but only on the understanding that the vendor will have to push the patches upstream eventually. If they don't the patches will be kicked out of the next release. (Which is what happened to the mptsas v4 release; it never made it upstream and so got dropped from SLE-12). However, this cuts both ways; we cannot go and tell our partners to change the driver if upstream hasn't done it first. I'm not saying we need to go into why this happened. Just that I'd like community agreement amongst the distros before trying to force the issue. I accept that the distros respond to their TAMs as well as the community, but if there's going to be TAM push back, I'd at least like to hear about it so I can have a word with the relevant people. So the push has to come from us (as the linux kernel developers); after all, we should make the decision what goes in and what doesn't. If a driver is in a bad state (and it's actually us which defines the 'bad state') we should be discussing on how we would like to improve things. If the maintainer proves unwilling to implement our suggestions we can always go ahead and implement a separate driver. Then we need a maintainer of that driver ... remember this is a fat firmware driver with a proprietary interface. It's hard to maintain and update without docs ... unless you happen to have an NDA copy? Hmm. _if_ the driver is similar to the original one (which was the idea) it should be reasonably trivial to port the latest changes from the original driver to the merged one. I think you expect more or less that after that new driver is created it will be maintained again by Avago(LSI), so let us hear what they think first. From my point of view the not optimal thing already has happened, both driver exist and both are included in our major releases. The change is probably better for the long-term maintainability of the driver, but from the distro perspective any switch to a new driver adds some new work, because we don't want to remove any particular old driver which has been included to a major release. That said, I agree that we (Red Hat) will manage the change, since it is the better approach for the long-term maintenance of the driver in the upstream. Cheers, Tomas Look what happened to hpsa; this was the pretty much the showcase on how it should be done: Tomo went ahead and re-implemented the cciss driver, and eventually HP adopted it as their main driver. I agree that was pretty much the optimal case, though:-) The best is to get LSI to agree, yes ... hence the need for unanimity. Agreed. Let's see what LSI has to say here. Cheers, Hannes -- 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: scsi-mq V2
Hi Robert, On Sun, Jul 13, 2014 at 05:15:15PM +, Elliott, Robert (Server Storage) wrote: I will see if that solves the problem with the scsi-mq-3 tree, or at least some of the bisect trees leading up to it. scsi-mq-3 is still going after 45 minutes. I'll leave it running overnight. That has been going strong for 18 hours, so I think that's the patch we need. Thanks for taking the time to narrow this down. I've applied the fix to my aio-fixes tree at git://git.kvack.org/~bcrl/aio-fixes.git and fowarded it on to Linus as well. -ben -- Thought is the essence of where you are now. -- 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: mpt2sas stuck installing
On Sat, 12 Jul 2014 03:13:07 +
Elliott, Robert (Server Storage) elli...@hp.com wrote:
-Original Message-
From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
ow...@vger.kernel.org] On Behalf Of Joe Lawrence
...
In your crash stack trace, the scsi error handler has issued a host
reset, but then crashed in mpt2sas_base_get_iocstate. Reading through
_scsih_shutdown, I don't believe that the mpt2sas .shutdown path takes
any precaution before heading down mpt2sas_base_detach to free adapter
resources. The ordinary .remove path looks similar, though it does
call sas_remove_host before freeing resources, *then* scsi_remove_host
and scsi_host_put.
I wonder if this ordering needs to be reversed (and added to
_scsih_shutdown) to properly de-register from the SCSI midlayer prior
to removing the controller instance.
Regards,
-- Joe
Nagalakshmi was working on an mpt3sas patch for the scsi-mq tree
to do just that. I don't recall if the patch has made it into the
scsi-mq tree yet. Apparently it's also needed for non-mq and mpt2sas.
It is making this change:
sas_remove_host(shost);
+ scsi_remove_host(shost);
mpt3sas_base_detach(ioc);
list_del(ioc-list);
- scsi_remove_host(shost);
scsi_host_put(shost);
We are making a similar change in hpsa. Doing so led to a general
protection fault, which unveiled that we also needed to change
cancel_delayed_work() calls to cancel_delayed_work_sync() to
ensure there are no worker functions still active after the
scsi_host structure is unregistered.
It looks like Sreekanth posted those patches today -- the new ordering
seems correct, but is there any reason why _scsih_shutdown skips
{sas,scsi}_remove_host calls?
Regards,
-- Joe
--
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: mpt2sas and mpt3sas merge (again)
James == James Bottomley james.bottom...@hansenpartnership.com writes: James I support the concept, since I think everyone told LSI at the James time that splitting the drivers would become a maintenance James nightmare. And it is. I'd like to see these drivers merged as well. James One of the big reasons we don't have a lot of leverage with them James is that they always seem to slide updates around upstream via the James distros (often, it has to be admitted the DKM route), so if Red James Hat, SUSE, Oracle and Canonical can agree not to accept LSI James updates until the driver is done this way, we'd have a lot more James leverage. Unless it's a trivial bug fix Oracle won't take anything that's not accepted upstream. We are working with Avago/LSI to streamline their driver process to be a better fit for both upstream development and distro kernels. -- Martin K. Petersen Oracle Linux Engineering -- 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
