Re: [PATCH 12/15] scsi: initial blk-mq support
On 02/06/2014 04:11 PM, Nicholas A. Bellinger wrote:
+struct request_queue *scsi_mq_alloc_queue(struct scsi_device *sdev)
+{
+ struct Scsi_Host *shost = sdev-host;
+ struct blk_mq_hw_ctx *hctx;
+ struct request_queue *q;
+ struct request *rq;
+ struct scsi_cmnd *cmd;
+ struct blk_mq_reg reg;
+ int i, j, sgl_size;
+
+ memset(reg, 0, sizeof(reg));
+ reg.ops = scsi_mq_ops;
+ reg.queue_depth = shost-cmd_per_lun;
+ if (!reg.queue_depth)
+ reg.queue_depth = 1;
+
+ /* XXX: what to do about chained S/G lists? */
+ if (shost-hostt-sg_tablesize SCSI_MAX_SG_SEGMENTS)
+ shost-sg_tablesize = SCSI_MAX_SG_SEGMENTS;
+ sgl_size = shost-sg_tablesize * sizeof(struct scatterlist);
+
+ reg.cmd_size = sizeof(struct scsi_cmnd) +
+ sgl_size +
+ shost-hostt-cmd_size;
+ if (scsi_host_get_prot(shost))
+ reg.cmd_size += sizeof(struct scsi_data_buffer) + sgl_size;
OK, so your in-lining the allocation of data + protection SGLs from
blk-mq..
The original prototype code was doing these allocations separately below
for each pre-allocated cmd, and offering LLD's to optionally
pre-allocate their own descripts using sh-hostt-cmd_size if
necessary..
This was necessary to eliminate all fast-path allocations for
virtio-scsi, and I'd like to see something similar here as an optional
feature as well.
Yeah, it would be nice if like in Nick's patches, the driver could just
set the scsi_host_template-cmd_size then when the scsi_cmnd got to the
driver's queuecommand, the driver could just get its internal cmd struct
from the scsi_cmnd struct (for example in Nick's patch it was off the
SCp.ptr).
I started converting my iscsi mq patch from Nick's code to Christoph's
and am currently trying to figure out how to setup the
scsi_host_template-cmd_pool.
Current iscsi patch is attached if anyone cares.
However, one question I had with both approaches is how to deal with per
cmd pci/dma memory and preallocations.
diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
index bc77a6f..1d0857c 100644
--- a/drivers/scsi/be2iscsi/be_main.c
+++ b/drivers/scsi/be2iscsi/be_main.c
@@ -320,10 +320,10 @@ static int beiscsi_eh_device_reset(struct scsi_cmnd *sc)
memset(inv_tbl, 0x0, sizeof(*inv_tbl) * BE2_CMDS_PER_CXN);
num_invalidate = 0;
for (i = 0; i conn-session-cmds_max; i++) {
- abrt_task = conn-session-cmds[i];
- abrt_io_task = abrt_task-dd_data;
- if (!abrt_task-sc || abrt_task-state == ISCSI_TASK_FREE)
+ abrt_task = conn-session-task_map[i];
+ if (!abrt_task || abrt_task-state != ISCSI_TASK_RUNNING)
continue;
+ abrt_io_task = abrt_task-dd_data;
if (sc-device-lun != abrt_task-sc-device-lun)
continue;
diff --git a/drivers/scsi/bnx2i/bnx2i_iscsi.c b/drivers/scsi/bnx2i/bnx2i_iscsi.c
index c00642f..34289b4 100644
--- a/drivers/scsi/bnx2i/bnx2i_iscsi.c
+++ b/drivers/scsi/bnx2i/bnx2i_iscsi.c
@@ -447,7 +447,7 @@ static int bnx2i_alloc_bdt(struct bnx2i_hba *hba, struct
iscsi_session *session,
io-bd_tbl = dma_alloc_coherent(hba-pcidev-dev,
ISCSI_MAX_BDS_PER_CMD * sizeof(*bd),
- io-bd_tbl_dma, GFP_KERNEL);
+ io-bd_tbl_dma, GFP_ATOMIC);
if (!io-bd_tbl) {
iscsi_session_printk(KERN_ERR, session, Could not
allocate bdt.\n);
@@ -458,61 +458,6 @@ static int bnx2i_alloc_bdt(struct bnx2i_hba *hba, struct
iscsi_session *session,
}
/**
- * bnx2i_destroy_cmd_pool - destroys iscsi command pool and release BD table
- * @hba: adapter instance pointer
- * @session: iscsi session pointer
- * @cmd: iscsi command structure
- */
-static void bnx2i_destroy_cmd_pool(struct bnx2i_hba *hba,
- struct iscsi_session *session)
-{
- int i;
-
- for (i = 0; i session-cmds_max; i++) {
- struct iscsi_task *task = session-cmds[i];
- struct bnx2i_cmd *cmd = task-dd_data;
-
- if (cmd-io_tbl.bd_tbl)
- dma_free_coherent(hba-pcidev-dev,
- ISCSI_MAX_BDS_PER_CMD *
- sizeof(struct iscsi_bd),
- cmd-io_tbl.bd_tbl,
- cmd-io_tbl.bd_tbl_dma);
- }
-
-}
-
-
-/**
- * bnx2i_setup_cmd_pool - sets up iscsi command pool for the session
- * @hba: adapter instance pointer
- * @session: iscsi session pointer
- */
-static int bnx2i_setup_cmd_pool(struct bnx2i_hba *hba,
- struct iscsi_session *session)
-{
- int i;
-
- for (i = 0; i session-cmds_max; i++) {
-
Re: [PATCH 04/17] scsi: avoid useless free_list lock roundtrips
Il 05/02/2014 13:39, Christoph Hellwig ha scritto:
Avoid hitting the host-wide free_list lock unless we need to put a command
back onto the freelist.
Signed-off-by: Christoph Hellwig h...@lst.de
---
drivers/scsi/scsi.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index ebcea6c..4139486 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -320,15 +320,16 @@ void __scsi_put_command(struct Scsi_Host *shost, struct
scsi_cmnd *cmd,
{
unsigned long flags;
- /* changing locks here, don't need to restore the irq state */
- spin_lock_irqsave(shost-free_list_lock, flags);
if (unlikely(list_empty(shost-free_list))) {
- list_add(cmd-list, shost-free_list);
- cmd = NULL;
+ spin_lock_irqsave(shost-free_list_lock, flags);
+ if (list_empty(shost-free_list)) {
+ list_add(cmd-list, shost-free_list);
+ cmd = NULL;
+ }
+ spin_unlock_irqrestore(shost-free_list_lock, flags);
}
- spin_unlock_irqrestore(shost-free_list_lock, flags);
- if (likely(cmd != NULL))
+ if (cmd)
scsi_pool_free_command(shost-cmd_pool, cmd);
put_device(dev);
Reviewed-by: Paolo Bonzini pbonz...@redhat.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 06/17] scsi: add support for per-host cmd pools
Il 05/02/2014 13:39, Christoph Hellwig ha scritto:
+ pool = scsi_find_host_cmd_pool(shost);
Should you have a WARN_ON somewhere if shost-hostt-cmd_size
shost-unchecked_isa_dma?
Apart from this,
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Paolo
+ if (!pool) {
+ pool = scsi_alloc_host_cmd_pool(shost);
+ if (!pool)
+ goto out;
+ }
+
--
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 07/17] virtio_scsi: use cmd_size
Il 05/02/2014 13:39, Christoph Hellwig ha scritto:
Taken almost entirely from Nicholas Bellinger's scsi-mq conversion.
Signed-off-by: Christoph Hellwig h...@lst.de
---
drivers/scsi/virtio_scsi.c | 25 +++--
1 file changed, 7 insertions(+), 18 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 16bfd50..d9a6074 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -204,7 +204,6 @@ static void virtscsi_complete_cmd(struct virtio_scsi
*vscsi, void *buf)
set_driver_byte(sc, DRIVER_SENSE);
}
- mempool_free(cmd, virtscsi_cmd_pool);
sc-scsi_done(sc);
atomic_dec(tgt-reqs);
@@ -279,8 +278,6 @@ static void virtscsi_complete_free(struct virtio_scsi
*vscsi, void *buf)
if (cmd-comp)
complete_all(cmd-comp);
- else
- mempool_free(cmd, virtscsi_cmd_pool);
}
static void virtscsi_ctrl_done(struct virtqueue *vq)
@@ -496,10 +493,9 @@ static int virtscsi_queuecommand(struct virtio_scsi *vscsi,
struct virtio_scsi_vq *req_vq,
struct scsi_cmnd *sc)
{
- struct virtio_scsi_cmd *cmd;
- int ret;
-
struct Scsi_Host *shost = virtio_scsi_host(vscsi-vdev);
+ struct virtio_scsi_cmd *cmd = (struct virtio_scsi_cmd *)(sc + 1);
+
BUG_ON(scsi_sg_count(sc) shost-sg_tablesize);
/* TODO: check feature bit and fail if unsupported? */
@@ -508,11 +504,6 @@ static int virtscsi_queuecommand(struct virtio_scsi *vscsi,
dev_dbg(sc-device-sdev_gendev,
cmd %p CDB: %#02x\n, sc, sc-cmnd[0]);
- ret = SCSI_MLQUEUE_HOST_BUSY;
- cmd = mempool_alloc(virtscsi_cmd_pool, GFP_ATOMIC);
- if (!cmd)
- goto out;
-
memset(cmd, 0, sizeof(*cmd));
cmd-sc = sc;
cmd-req.cmd = (struct virtio_scsi_cmd_req){
@@ -531,13 +522,9 @@ static int virtscsi_queuecommand(struct virtio_scsi *vscsi,
if (virtscsi_kick_cmd(req_vq, cmd,
sizeof cmd-req.cmd, sizeof cmd-resp.cmd,
- GFP_ATOMIC) == 0)
- ret = 0;
- else
- mempool_free(cmd, virtscsi_cmd_pool);
-
-out:
- return ret;
+ GFP_ATOMIC) != 0)
+ return SCSI_MLQUEUE_HOST_BUSY;
+ return 0;
}
static int virtscsi_queuecommand_single(struct Scsi_Host *sh,
@@ -683,6 +670,7 @@ static struct scsi_host_template
virtscsi_host_template_single = {
.name = Virtio SCSI HBA,
.proc_name = virtio_scsi,
.this_id = -1,
+ .cmd_size = sizeof(struct virtio_scsi_cmd),
.queuecommand = virtscsi_queuecommand_single,
.eh_abort_handler = virtscsi_abort,
.eh_device_reset_handler = virtscsi_device_reset,
@@ -699,6 +687,7 @@ static struct scsi_host_template
virtscsi_host_template_multi = {
.name = Virtio SCSI HBA,
.proc_name = virtio_scsi,
.this_id = -1,
+ .cmd_size = sizeof(struct virtio_scsi_cmd),
.queuecommand = virtscsi_queuecommand_multi,
.eh_abort_handler = virtscsi_abort,
.eh_device_reset_handler = virtscsi_device_reset,
-- 1.7.10.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
Acked-by: Paolo Bonzini pbonz...@redhat.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 06/17] scsi: add support for per-host cmd pools
On 02/05/2014 06:39 AM, Christoph Hellwig wrote:
-static struct scsi_host_cmd_pool *scsi_get_host_cmd_pool(gfp_t gfp_mask)
+static struct scsi_host_cmd_pool *
+scsi_find_host_cmd_pool(struct Scsi_Host *shost)
{
+ if (shost-hostt-cmd_size)
+ return shost-hostt-cmd_pool;
+ if (shost-unchecked_isa_dma)
+ return scsi_cmd_dma_pool;
+ return scsi_cmd_pool;
+}
+
It seems there is a issue with using the cmd_size to indicate the driver
has its own cmd pool and also using that for scsi mq enabled drivers to
indicate that we want the LLD's struct allocated by blk/scsi mq.
If a driver sets cmd_size for only the scsi/blk mq purpose, this patch
wants the driver to also setup a cmd pool which I do not think is used
when doing scsi/blk mq.
--
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 13/17] scsi: push host_lock down into scsi_{host,target}_queue_ready
On 02/06/14 22:58, Nicholas A. Bellinger wrote: Starting with a baseline using scsi_debug that NOPs REQ_TYPE_FS commands to measure improvements would be a better baseline vs. scsi_request_fn() existing code that what your doing above. That way at least it's easier to measure specific scsi-core overhead down to the LLD's queuecommand without everything else in the way. Running initiator and target workload on the same system makes initiator and target code share CPUs and hence makes it hard to analyze which performance change is caused by initiator optimizations and which performance change is caused by interactions between initiator and target workloads. Bart. -- 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 13/17] scsi: push host_lock down into scsi_{host,target}_queue_ready
On 02/06/14 19:41, James Bottomley wrote: On Thu, 2014-02-06 at 18:10 +0100, Bart Van Assche wrote: On 02/06/14 17:56, James Bottomley wrote: Could you benchmark this lot and show what the actual improvement is just for this series, if any? I see a performance improvement of 12% with the SRP protocol for the SCSI core optimizations alone (I am still busy measuring the impact of the blk-mq conversion but I can already see that it is really significant). Please note that the performance impact depends a lot on the workload (number of LUNs per SCSI host e.g.) so maybe the workload I chose is not doing justice to Christoph's work. And it's also important to mention that with the workload I ran I was saturating the target system CPU (a quad core Intel i5). In other words, results might be better with a more powerful target system. On what? Just the patches I indicated or the whole series? My specific concern is that swapping a critical section for atomics may not buy us anything even on x86 and may slow down non-x86. That's the bit I'd like benchmarks to explore. The numbers I mentioned in my previous e-mail referred to the SCSI data path micro-optimizations patch series and the A different approach for using blk-mq in the SCSI layer series as a whole. I have run a new test in which I compared the performance between a kernel with these two patch series applied versus a kernel in which the four patches that convert host_busy, target_busy and device_busy into atomics have been reverted. For a workload with a single SCSI host, a single LUN, a block size of 512 bytes, the SRP protocol and a single CPU thread submitting I/O requests I see a performance improvement of 0.5% when using atomics. For a workload with a single SCSI host, eight LUNs and eight CPU threads submitting I/O I see a performance improvement of 3.8% when using atomics. Please note that these measurements have been run on a single socket system, that cache line misses are more expensive on NUMA systems and hence that the performance impact of these patches on a NUMA system will be more substantial. Bart. -- 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 13/22] megaraid: Use pci_enable_msix_range()
-Original Message-
From: Alexander Gordeev [mailto:agord...@redhat.com]
Sent: Tuesday, February 04, 2014 4:47 PM
To: linux-ker...@vger.kernel.org
Cc: Alexander Gordeev; DL-MegaRAID Linux; linux-scsi@vger.kernel.org;
linux-...@vger.kernel.org
Subject: [PATCH 13/22] megaraid: Use pci_enable_msix_range()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers using these two
interfaces need to be updated to use the new pci_enable_msi_range() and
pci_enable_msix_range() interfaces.
Signed-off-by: Alexander Gordeev agord...@redhat.com
Cc: Neela Syam Kolli megaraidli...@lsi.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/megaraid/megaraid_sas_base.c | 25 +++--
1 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 3b7ad10..90944f1 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -3731,18 +3731,12 @@ static int megasas_init_fw(struct
megasas_instance *instance)
(unsigned int)num_online_cpus());
for (i = 0; i instance-msix_vectors; i++)
instance-msixentry[i].entry = i;
- i = pci_enable_msix(instance-pdev, instance-msixentry,
- instance-msix_vectors);
- if (i = 0) {
- if (i) {
- if (!pci_enable_msix(instance-pdev,
- instance-msixentry, i))
- instance-msix_vectors = i;
- else
- instance-msix_vectors = 0;
- }
- } else
+ i = pci_enable_msix_range(instance-pdev, instance-
msixentry,
+1, instance-msix_vectors);
+ if (i 0)
instance-msix_vectors = 0;
+ else
+ instance-msix_vectors = i;
dev_info(instance-pdev-dev, [scsi%d]: FW supports
%d MSIX vector,Online CPUs: %d,
@@ -4667,9 +4661,11 @@ megasas_resume(struct pci_dev *pdev)
goto fail_ready_state;
/* Now re-enable MSI-X */
- if (instance-msix_vectors)
- pci_enable_msix(instance-pdev, instance-msixentry,
- instance-msix_vectors);
+ if (instance-msix_vectors
+ pci_enable_msix_range(instance-pdev, instance-msixentry,
+instance-msix_vectors,
+instance-msix_vectors) 0)
+ goto fail_reenable_msix;
switch (instance-pdev-device) {
case PCI_DEVICE_ID_LSI_FUSION:
@@ -4756,6 +4752,7 @@ fail_init_mfi:
fail_set_dma_mask:
fail_ready_state:
+fail_reenable_msix:
pci_disable_device(pdev);
Acked-by: Sumit Saxena sumit.sax...@lsi.com
Sumit
--
1.7.7.6
--
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 12/15] scsi: initial blk-mq support
On Fri, Feb 07, 2014 at 02:45:18AM -0600, Mike Christie wrote: Yeah, it would be nice if like in Nick's patches, the driver could just set the scsi_host_template-cmd_size then when the scsi_cmnd got to the driver's queuecommand, the driver could just get its internal cmd struct from the scsi_cmnd struct (for example in Nick's patch it was off the SCp.ptr). You can do this with my series. The cmd_size support is actually added in the first series and still works here. Instead of needing SCp.ptr you just grab the memory right behind the command. Right now virtio_scsi opencodes this, but I should probably add a helper for the next iteration. -- 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 06/17] scsi: add support for per-host cmd pools
On Fri, Feb 07, 2014 at 10:13:25AM +0100, Paolo Bonzini wrote: Il 05/02/2014 13:39, Christoph Hellwig ha scritto: +pool = scsi_find_host_cmd_pool(shost); Should you have a WARN_ON somewhere if shost-hostt-cmd_size shost-unchecked_isa_dma? Seems like we could support passing SLAB_CACHE_DMA and __GFP_DMA easily even for the per-template pool, I'll look into that. -- 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 06/17] scsi: add support for per-host cmd pools
On Fri, Feb 07, 2014 at 03:35:00AM -0600, Mike Christie wrote: It seems there is a issue with using the cmd_size to indicate the driver has its own cmd pool and also using that for scsi mq enabled drivers to indicate that we want the LLD's struct allocated by blk/scsi mq. If a driver sets cmd_size for only the scsi/blk mq purpose, this patch wants the driver to also setup a cmd pool which I do not think is used when doing scsi/blk mq. I don't quite understand what you mean. cmd_size means that each scsi_cmnd passed to the driver will have additional per-driver data. For the old path it's implemented by creating a slab cache and storing it in the host template to easily find it, for blk-mq it is used to increase the allocation in the block core as scsi doesn't do it's own allocations in this case. Very different implementation underneath, but same effect for the driver. -- 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 12/15] scsi: initial blk-mq support
Is there extra scsi_mq_done() part that does IPI here even necessary anymore..? I was under the assumption that blk_mq_end_io() is already taking care of this..? blk_mq_end_io does it, but given that the SCSI-specific I/O completion path is non-trivial I'd rather run it on the indicated CPU as well, similar to how the old blk-softirq code works. I'll send out a patch series that should make this area a lot cleaner and avoid having to implement the IPIs in each driver that wants or needs it soon. OK, so your in-lining the allocation of data + protection SGLs from blk-mq.. The original prototype code was doing these allocations separately below for each pre-allocated cmd, and offering LLD's to optionally pre-allocate their own descripts using sh-hostt-cmd_size if necessary.. This was necessary to eliminate all fast-path allocations for virtio-scsi, and I'd like to see something similar here as an optional feature as well. It's present. The cmd_size host_template parameter is added in the previous series, and we still take it into account. -- 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
[bug #1] arcmsr: read past end of array in arcmsr_report_sense_info()
Hello Erich Chen,
The patch 1c57e86d75cf: [SCSI] arcmsr: initial driver, version
1.20.00.13 from Jul 12, 2006, leads to the following static checker
warning:
drivers/scsi/arcmsr/arcmsr_hba.c:816 arcmsr_report_sense_info()
error: memcpy() 'ccb-arcmsr_cdb.SenseData' too small (15 vs 18)
drivers/scsi/arcmsr/arcmsr_hba.c
805 static void arcmsr_report_sense_info(struct CommandControlBlock *ccb)
806 {
807
808 struct scsi_cmnd *pcmd = ccb-pcmd;
809 struct SENSE_DATA *sensebuffer = (struct SENSE_DATA
*)pcmd-sense_buffer;
810 pcmd-result = DID_OK 16;
811 if (sensebuffer) {
812 int sense_data_length =
813 sizeof(struct SENSE_DATA)
SCSI_SENSE_BUFFERSIZE
814 ? sizeof(struct SENSE_DATA) :
SCSI_SENSE_BUFFERSIZE;
815 memset(sensebuffer, 0, SCSI_SENSE_BUFFERSIZE);
816 memcpy(sensebuffer, ccb-arcmsr_cdb.SenseData,
sense_data_length);
^
This buffer is 15 bytes but we copy 18 bytes so we are reading past the
end of the array.
817 sensebuffer-ErrorCode = SCSI_SENSE_CURRENT_ERRORS;
818 sensebuffer-Valid = 1;
819 }
820 }
regards,
dan carpenter
--
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
[bug #2] arcmsr: forever loop in arcmsr_polling_hbc_ccbdone()
Hello Nick Cheng,
The patch cdd3cb156f19: [SCSI] SCSI: Support Type C RAID controller
from Jul 13, 2010, leads to the following static checker warning:
drivers/scsi/arcmsr/arcmsr_hba.c:2474 arcmsr_polling_hbc_ccbdone()
warn: this loop depends on readl() succeeding
drivers/scsi/arcmsr/arcmsr_hba.c
2432 poll_count++;
2433 while (1) {
2434 if ((readl(reg-host_int_status)
ARCMSR_HBCMU_OUTBOUND_POSTQUEUE_ISR) == 0) {
^
readl() returns 0x on failure (hotplug).
2435 if (poll_ccb_done) {
2436 rtn = SUCCESS;
2437 break;
2438 } else {
2439 msleep(25);
2440 if (poll_count 100) {
We break out of the loop if we time out but this condition can only be
reached if the readl() succeeds. Probably the intent was to time out
regardless of the readl() return value.
2441 rtn = FAILED;
2442 break;
2443 }
2444 goto polling_hbc_ccb_retry;
2445 }
2446 }
2447 flag_ccb = readl(reg-outbound_queueport_low);
2448 ccb_cdb_phy = (flag_ccb 0xFFF0);
2449 arcmsr_cdb = (struct ARCMSR_CDB *)(acb-vir2phy_offset
+ ccb_cdb_phy);/*frame must be 32 bytes aligned*/
2450 pCCB = container_of(arcmsr_cdb, struct
CommandControlBlock, arcmsr_cdb);
2451 poll_ccb_done = (pCCB == poll_ccb) ? 1 : 0;
2452 /* check ifcommand done with no error*/
2453 if ((pCCB-acb != acb) || (pCCB-startdone !=
ARCMSR_CCB_START)) {
2454 if (pCCB-startdone == ARCMSR_CCB_ABORTED) {
2455 printk(KERN_NOTICE arcmsr%d: scsi id =
%d lun = %d ccb = '0x%p'
2456 poll command abort
successfully \n
2457 , acb-host-host_no
2458 , pCCB-pcmd-device-id
2459 , pCCB-pcmd-device-lun
2460 , pCCB);
2461 pCCB-pcmd-result = DID_ABORT
16;
2462 arcmsr_ccb_complete(pCCB);
2463 continue;
2464 }
2465 printk(KERN_NOTICE arcmsr%d: polling get an
illegal ccb
2466 command done ccb = '0x%p'
2467 ccboutstandingcount = %d \n
2468 , acb-host-host_no
2469 , pCCB
2470 ,
atomic_read(acb-ccboutstandingcount));
2471 continue;
2472 }
2473 error = (flag_ccb ARCMSR_CCBREPLY_FLAG_ERROR_MODE1) ?
true : false;
2474 arcmsr_report_ccb_state(acb, pCCB, error);
2475 }
2476 return rtn;
regards,
dan carpenter
--
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
[bug #3] arcmsr: Sparse finds has many warnings and errors
This file has many many Sparse warnings. Most of them are just a matter of using correct __iomem tags but some are real bugs where we dereference __iomem pointers. Can you take a look? regards, dan carpenter drivers/scsi/arcmsr/arcmsr_hba.c:81:19: warning: symbol 'wait_q' was not declared. Should it be static? drivers/scsi/arcmsr/arcmsr_hba.c:2582:54: warning: cast removes address space of expression drivers/scsi/arcmsr/arcmsr_hba.c:2586:83: warning: incorrect type in argument 2 (different address spaces) drivers/scsi/arcmsr/arcmsr_hba.c:2586:83:expected void volatile [noderef] asn:2*addr drivers/scsi/arcmsr/arcmsr_hba.c:2586:83:got unsigned int * drivers/scsi/arcmsr/arcmsr_hba.c:2587:72: warning: incorrect type in argument 2 (different address spaces) drivers/scsi/arcmsr/arcmsr_hba.c:2587:72:expected void volatile [noderef] asn:2*addr drivers/scsi/arcmsr/arcmsr_hba.c:2587:72:got unsigned int * drivers/scsi/arcmsr/arcmsr_hba.c:2588:66: warning: incorrect type in argument 2 (different address spaces) drivers/scsi/arcmsr/arcmsr_hba.c:2588:66:expected void volatile [noderef] asn:2*addr drivers/scsi/arcmsr/arcmsr_hba.c:2588:66:got unsigned int *noident drivers/scsi/arcmsr/arcmsr_hba.c:2589:72: warning: incorrect type in argument 2 (different address spaces) drivers/scsi/arcmsr/arcmsr_hba.c:2589:72:expected void volatile [noderef] asn:2*addr drivers/scsi/arcmsr/arcmsr_hba.c:2589:72:got unsigned int *noident drivers/scsi/arcmsr/arcmsr_hba.c:840:46: warning: cast removes address space of expression drivers/scsi/arcmsr/arcmsr_hba.c:842:36: warning: incorrect type in argument 1 (different address spaces) drivers/scsi/arcmsr/arcmsr_hba.c:842:36:expected void const volatile [noderef] asn:2*addr drivers/scsi/arcmsr/arcmsr_hba.c:842:36:got unsigned int *noident drivers/scsi/arcmsr/arcmsr_hba.c:843:67: warning: incorrect type in argument 2 (different address spaces) drivers/scsi/arcmsr/arcmsr_hba.c:843:67:expected void volatile [noderef] asn:2*addr drivers/scsi/arcmsr/arcmsr_hba.c:843:67:got unsigned int *noident drivers/scsi/arcmsr/arcmsr_hba.c:2655:48: warning: incorrect type in initializer (different address spaces) drivers/scsi/arcmsr/arcmsr_hba.c:2655:48:expected struct MessageUnit_B [noderef] asn:2*reg drivers/scsi/arcmsr/arcmsr_hba.c:2655:48:got struct MessageUnit_B *pmuB drivers/scsi/arcmsr/arcmsr_hba.c:568:57: warning: incorrect type in initializer (different address spaces) drivers/scsi/arcmsr/arcmsr_hba.c:568:57:expected struct MessageUnit_C *reg drivers/scsi/arcmsr/arcmsr_hba.c:568:57:got struct MessageUnit_C [noderef] asn:2*pmuC drivers/scsi/arcmsr/arcmsr_hba.c:1575:41: warning: incorrect type in initializer (different address spaces) drivers/scsi/arcmsr/arcmsr_hba.c:1575:41:expected struct MessageUnit_C *reg drivers/scsi/arcmsr/arcmsr_hba.c:1575:41:got struct MessageUnit_C [noderef] asn:2*pmuC drivers/scsi/arcmsr/arcmsr_hba.c:1577:71: warning: incorrect type in argument 2 (different address spaces) drivers/scsi/arcmsr/arcmsr_hba.c:1577:71:expected void volatile [noderef] asn:2*addr drivers/scsi/arcmsr/arcmsr_hba.c:1577:71:got unsigned int *noident drivers/scsi/arcmsr/arcmsr_hba.c:352:41: warning: cast removes address space of expression drivers/scsi/arcmsr/arcmsr_hba.c:356:28: warning: incorrect type in argument 1 (different address spaces) drivers/scsi/arcmsr/arcmsr_hba.c:356:28:expected void const volatile [noderef] asn:2*addr drivers/scsi/arcmsr/arcmsr_hba.c:356:28:got unsigned int *noident drivers/scsi/arcmsr/arcmsr_hba.c:359:34: warning: incorrect type in argument 2 (different address spaces) drivers/scsi/arcmsr/arcmsr_hba.c:359:34:expected void volatile [noderef] asn:2*addr drivers/scsi/arcmsr/arcmsr_hba.c:359:34:got unsigned int *noident drivers/scsi/arcmsr/arcmsr_hba.c:402:38: warning: cast removes address space of expression drivers/scsi/arcmsr/arcmsr_hba.c:404:51: warning: incorrect type in argument 2 (different address spaces) drivers/scsi/arcmsr/arcmsr_hba.c:404:51:expected void volatile [noderef] asn:2*addr drivers/scsi/arcmsr/arcmsr_hba.c:404:51:got unsigned int *noident drivers/scsi/arcmsr/arcmsr_hba.c:405:56: warning: incorrect type in argument 2 (different address spaces) drivers/scsi/arcmsr/arcmsr_hba.c:405:56:expected void volatile [noderef] asn:2*addr drivers/scsi/arcmsr/arcmsr_hba.c:405:56:got unsigned int *noident drivers/scsi/arcmsr/arcmsr_hba.c:741:38: warning: cast removes address space of expression drivers/scsi/arcmsr/arcmsr_hba.c:742:49: warning: incorrect type in argument 2 (different address spaces) drivers/scsi/arcmsr/arcmsr_hba.c:742:49:expected void volatile [noderef] asn:2*addr drivers/scsi/arcmsr/arcmsr_hba.c:742:49:got unsigned int *noident drivers/scsi/arcmsr/arcmsr_hba.c:743:56: warning: incorrect type in argument 2 (different address spaces) drivers/scsi/arcmsr/arcmsr_hba.c:743:56:expected void volatile
[patch] [SCSI] arcmsr: upper 32 of dma address lost
The original code always set the upper 32 bits to zero because it was
doing a shift of the wrong variable.
Fixes: 1a4f550a09f8 ('[SCSI] arcmsr: 1.20.00.15: add SATA RAID plus other
fixes')
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
index 4f6a30b8e5f9..9cfd399c47c0 100644
--- a/drivers/scsi/arcmsr/arcmsr_hba.c
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c
@@ -2500,16 +2500,15 @@ static int arcmsr_polling_ccbdone(struct
AdapterControlBlock *acb,
static int arcmsr_iop_confirm(struct AdapterControlBlock *acb)
{
uint32_t cdb_phyaddr, cdb_phyaddr_hi32;
- dma_addr_t dma_coherent_handle;
+
/*
** here we need to tell iop 331 our freeccb.HighPart
** if freeccb.HighPart is not zero
*/
- dma_coherent_handle = acb-dma_coherent_handle;
- cdb_phyaddr = (uint32_t)(dma_coherent_handle);
- cdb_phyaddr_hi32 = (uint32_t)((cdb_phyaddr 16) 16);
+ cdb_phyaddr = (uint32_t)(acb-dma_coherent_handle);
+ cdb_phyaddr_hi32 = (uint32_t)(acb-dma_coherent_handle 32);
acb-cdb_phyaddr_hi32 = cdb_phyaddr_hi32;
/*
***
--
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: [LSF/MM TOPIC] SMR: Disrupting recording technology meriting a new class of storage device
Hi, On Sat, Feb 01, 2014 at 02:24:33AM +, Albert Chen wrote: [LSF/MM TOPIC] SMR: Disrupting recording technology meriting a new class of storage device Shingle Magnetic Recording is a disruptive technology that delivers the next areal density gain for the HDD industry by partially overlapping tracks. Shingling requires physical writes to be sequential, and opens the question of how to address this behavior at a system level. Two general approaches contemplated are to either to do the block management in the device or in the host storage stack/file system through Zone Block Commands (ZBC). The use of ZBC to handle SMR block management yields several benefits such as: - Predictable performance and latency - Faster development time - Access to application and system level semantic information - Scalability / Fewer Drive Resources - Higher reliability Essential to a host managed approach (ZBC) is the openness of Linux and its community is a good place for WD to validate and seek feedback for our thinking - where in the Linux system stack is the best place to add ZBC handling? at the Device Mapper layer? or somewhere else in the storage stack? New ideas and comments are appreciated. If you add ZBC handling into the device-mapper layer, aren't you supposing that all SMR devices will be managed by device-mapper? This doesn't look right IMHO. These devices should be able to be managed via DM or either directly via de storage layer. And any other layers making use of these devices (like DM for example) should be able to communicate with them and send ZBC commands as needed. For more information about ZBC, please refer to Ted's ty...@mit.edu email to linux-fsde...@vger.kernel.org with the subject [RFC] Draft Linux kernel interfaces for ZBC drives. -- To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Carlos -- 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] arcmsr: upper 32 of dma address lost
On Fri, Feb 07, 2014 at 04:00:28PM +0300, Dan Carpenter wrote:
The original code always set the upper 32 bits to zero because it was
doing a shift of the wrong variable.
Actually let me redo this. I want to add a cast to prevent a static
checker warning on 32 bit systems. Sorry, for the noise.
regards,
dan carpenter
Fixes: 1a4f550a09f8 ('[SCSI] arcmsr: 1.20.00.15: add SATA RAID plus other
fixes')
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c
b/drivers/scsi/arcmsr/arcmsr_hba.c
index 4f6a30b8e5f9..9cfd399c47c0 100644
--- a/drivers/scsi/arcmsr/arcmsr_hba.c
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c
@@ -2500,16 +2500,15 @@ static int arcmsr_polling_ccbdone(struct
AdapterControlBlock *acb,
static int arcmsr_iop_confirm(struct AdapterControlBlock *acb)
{
uint32_t cdb_phyaddr, cdb_phyaddr_hi32;
- dma_addr_t dma_coherent_handle;
+
/*
** here we need to tell iop 331 our freeccb.HighPart
** if freeccb.HighPart is not zero
*/
- dma_coherent_handle = acb-dma_coherent_handle;
- cdb_phyaddr = (uint32_t)(dma_coherent_handle);
- cdb_phyaddr_hi32 = (uint32_t)((cdb_phyaddr 16) 16);
+ cdb_phyaddr = (uint32_t)(acb-dma_coherent_handle);
+ cdb_phyaddr_hi32 = (uint32_t)(acb-dma_coherent_handle 32);
acb-cdb_phyaddr_hi32 = cdb_phyaddr_hi32;
/*
***
--
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: [LSF/MM TOPIC] SMR: Disrupting recording technology meriting a new class of storage device
On 02/07/2014 02:00 PM, Carlos Maiolino wrote: Hi, On Sat, Feb 01, 2014 at 02:24:33AM +, Albert Chen wrote: [LSF/MM TOPIC] SMR: Disrupting recording technology meriting a new class of storage device Shingle Magnetic Recording is a disruptive technology that delivers the next areal density gain for the HDD industry by partially overlapping tracks. Shingling requires physical writes to be sequential, and opens the question of how to address this behavior at a system level. Two general approaches contemplated are to either to do the block management in the device or in the host storage stack/file system through Zone Block Commands (ZBC). The use of ZBC to handle SMR block management yields several benefits such as: - Predictable performance and latency - Faster development time - Access to application and system level semantic information - Scalability / Fewer Drive Resources - Higher reliability Essential to a host managed approach (ZBC) is the openness of Linux and its community is a good place for WD to validate and seek feedback for our thinking - where in the Linux system stack is the best place to add ZBC handling? at the Device Mapper layer? or somewhere else in the storage stack? New ideas and comments are appreciated. If you add ZBC handling into the device-mapper layer, aren't you supposing that all SMR devices will be managed by device-mapper? This doesn't look right IMHO. These devices should be able to be managed via DM or either directly via de storage layer. And any other layers making use of these devices (like DM for example) should be able to communicate with them and send ZBC commands as needed. Precisely. Adding a new device type (and a new ULD to the SCSI midlayer) seems to be the right idea here. Then we could think of how to integrate this into the block layer; eg we could identify the zones with partitions, or mirror the zones via block_limits. There is actually a good chance that we can tweak btrfs to run unmodified on such a disk; after all, sequential writes are not a big deal for btrfs. The only issue we might have is that we might need to re-allocate blocks to free up zones. But some btrfs developers have assured me this shouldn't be too hard. Personally I don't like the idea of _having_ to use a device-mapper module for these things. What I would like is giving the user a choice; if there are specialized fs around which can deal with such a disk (hello, ltfs :-) then fine. If not of course we should be having a device-mapper module to hide the grubby details for unsuspecting filesystems. 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][RFC] Add EVPD page 0x83 entries to sysfs
On 02/06/2014 08:14 PM, Douglas Gilbert wrote:
On 14-02-06 08:04 AM, Hannes Reinecke wrote:
EVPD page 0x83 is used to uniquely identify the device.
So instead of having each and every program issue a separate
SG_IO call to retrieve this information it does make far more
sense to display it in sysfs.
Cc: Jeremy Linton jlin...@tributary.com
Cc: Doug Gilbert dgilb...@interlog.com
See below.
Cc: Kai Makisara kai.makis...@kolumbus.fi
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/scsi_scan.c | 3 +
drivers/scsi/scsi_sysfs.c | 166
-
include/scsi/scsi_device.h | 3 +
3 files changed, 171 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 307a811..073fb84 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -929,6 +929,9 @@ static int scsi_add_lun(struct scsi_device
*sdev, unsigned char *inq_result,
if (*bflags BLIST_SKIP_VPD_PAGES)
sdev-skip_vpd_pages = 1;
+if (sdev-scsi_level = SCSI_3)
+scsi_attach_vpd_ident(sdev);
+
transport_configure_device(sdev-sdev_gendev);
if (sdev-host-hostt-slave_configure) {
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 9117d0b..ffe7cb5 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -725,8 +725,170 @@ show_queue_type_field(struct device *dev,
struct device_attribute *attr,
static DEVICE_ATTR(queue_type, S_IRUGO, show_queue_type_field,
NULL);
+void scsi_attach_vpd_ident(struct scsi_device *sdev)
+{
+int ret;
+int vpd_len = 255;
+unsigned char *buffer;
+retry:
+buffer = kmalloc(vpd_len, GFP_KERNEL);
+if (buffer) {
+ret = scsi_get_vpd_page(sdev, 0x83, buffer, vpd_len);
+if (ret == 0) {
+vpd_len = (buffer[2] 8) + buffer[3];
+if (vpd_len 255) {
+kfree(buffer);
+goto retry;
+}
+sdev-vpd_ident_len = vpd_len;
+sdev-vpd_ident = buffer;
+}
+}
+}
+
+#define SCSI_VPD_ASSOC_lun 0x0
+#define SCSI_VPD_ASSOC_port 0x10
+#define SCSI_VPD_ASSOC_target 0x20
+
+#define SCSI_VPD_DESIG_vendor 0x0
+#define SCSI_VPD_DESIG_t10 0x1
+#define SCSI_VPD_DESIG_eui 0x2
+#define SCSI_VPD_DESIG_naa 0x3
+#define SCSI_VPD_DESIG_relport 0x4
+#define SCSI_VPD_DESIG_tpgrp 0x5
+#define SCSI_VPD_DESIG_lugrp 0x6
+#define SCSI_VPD_DESIG_md5 0x7
+#define SCSI_VPD_DESIG_scsi_name 0x8
+
+int scsi_parse_vpd_ident(struct scsi_device *sdev,
+ int assoc, int desig, char *buf)
+{
+unsigned char *d;
+int len = 0;
+
+if (!sdev-vpd_ident)
+return -EINVAL;
+
+d = sdev-vpd_ident + 4;
+while (d sdev-vpd_ident + sdev-vpd_ident_len) {
+if ((d[1] 0x30) == assoc
Wouldn't it be clearer if:
if (((d[1] 0x30) 4) == assoc
and the lun, port and target defines were changed to agree
with T10?
Yes, I could. Just thought it a bit pointless given
that we're (currently) the only ones using it.
Will be fixing it up with the next version.
+(d[1] 0xf) == desig) {
+switch (d[1] 0xf) {
+case SCSI_VPD_DESIG_eui:
+case SCSI_VPD_DESIG_naa:
+case SCSI_VPD_DESIG_md5:
+switch (d[3]) {
+case 8:
+len += sprintf(buf + len,
+ %8phN\n, d + 4);
+break;
+case 12:
+len += sprintf(buf + len,
+ %12phN\n, d + 4);
+break;
+case 16:
+len += sprintf(buf + len,
+ %16phN\n, d + 4);
+break;
+}
+break;
+case SCSI_VPD_DESIG_relport:
+case SCSI_VPD_DESIG_tpgrp:
+case SCSI_VPD_DESIG_lugrp:
+len += sprintf(buf + len, %d\n,
+ (int)(d[6] 8) + d[7]);
+break;
+case SCSI_VPD_DESIG_vendor:
+case SCSI_VPD_DESIG_t10:
+case SCSI_VPD_DESIG_scsi_name:
+len += snprintf(buf + len, d[3] + 2, %s\n,
+d + 4);
+break;
+}
+}
+d += d[3] + 4;
+}
+
+return len ? len : -EINVAL;
+}
+
+#define sdev_evpd_ident(assoc,desig)\
+static ssize_t\
+sdev_show_evpd_ident_##assoc##_##desig (struct device *dev,\
+struct device_attribute *attr,\
+char * buf)\
+{\
+struct scsi_device *sdev = to_scsi_device(dev);\
+return scsi_parse_vpd_ident(sdev, SCSI_VPD_ASSOC_##assoc,\
+
RE: [LSF/MM TOPIC] SMR: Disrupting recording technology meriting a new class of storage device
-Original Message- From: Hannes Reinecke [mailto:h...@suse.de] Sent: Friday, February 07, 2014 5:46 AM To: Carlos Maiolino; Albert Chen Cc: lsf...@lists.linux-foundation.org; James Borden; Jim Malina; Curtis Stevens; linux-...@vger.kernel.org; linux-fsde...@vger.kernel.org; linux- s...@vger.kernel.org Subject: Re: [LSF/MM TOPIC] SMR: Disrupting recording technology meriting a new class of storage device On 02/07/2014 02:00 PM, Carlos Maiolino wrote: Hi, On Sat, Feb 01, 2014 at 02:24:33AM +, Albert Chen wrote: [LSF/MM TOPIC] SMR: Disrupting recording technology meriting a new class of storage device Shingle Magnetic Recording is a disruptive technology that delivers the next areal density gain for the HDD industry by partially overlapping tracks. Shingling requires physical writes to be sequential, and opens the question of how to address this behavior at a system level. Two general approaches contemplated are to either to do the block management in the device or in the host storage stack/file system through Zone Block Commands (ZBC). The use of ZBC to handle SMR block management yields several benefits such as: - Predictable performance and latency - Faster development time - Access to application and system level semantic information - Scalability / Fewer Drive Resources - Higher reliability Essential to a host managed approach (ZBC) is the openness of Linux and its community is a good place for WD to validate and seek feedback for our thinking - where in the Linux system stack is the best place to add ZBC handling? at the Device Mapper layer? or somewhere else in the storage stack? New ideas and comments are appreciated. If you add ZBC handling into the device-mapper layer, aren't you supposing that all SMR devices will be managed by device-mapper? This doesn't look right IMHO. These devices should be able to be managed via DM or either directly via de storage layer. And any other layers making use of these devices (like DM for example) should be able to communicate with them and send ZBC commands as needed. Clarification: ZBC is an interface protocol. A new device and command set. SMR is a recording technology. You may have ZBC without SMR or SMR without ZBC. For examples. SSD may benefit from ZBC protocol to improve performance and reduce wear. SMR may be 100% device managed and not provide information required of a ZBC device, like write pointers or zone boundaries. Precisely. Adding a new device type (and a new ULD to the SCSI midlayer) seems to be the right idea here. Then we could think of how to integrate this into the block layer; eg we could identify the zones with partitions, or mirror the zones via block_limits. There is actually a good chance that we can tweak btrfs to run unmodified on such a disk; after all, sequential writes are not a big deal for btrfs. The only issue we might have is that we might need to re-allocate blocks to free up zones. But some btrfs developers have assured me this shouldn't be too hard. Personally I don't like the idea of _having_ to use a device-mapper module for these things. What I would like is giving the user a choice; if there are specialized fs around which can deal with such a disk (hello, ltfs :-) then fine. If not of course we should be having a device-mapper module to hide the grubby details for unsuspecting filesystems. 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) jim -- 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 0/4] minor blk-mq updates
Hi Jens, these small blk-mq core updates fell out of the scsi multiqueue work. -- 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/4] blk-mq: support at_head inserations for blk_execute_rq
This is neede for proper SG_IO operation as well as various uses of
blk_execute_rq from the SCSI midlayer.
Signed-off-by: Christoph Hellwig h...@lst.de
---
block/blk-exec.c |2 +-
block/blk-mq.c | 17 ++---
include/linux/blk-mq.h |3 ++-
3 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/block/blk-exec.c b/block/blk-exec.c
index bbfc072..c68613b 100644
--- a/block/blk-exec.c
+++ b/block/blk-exec.c
@@ -65,7 +65,7 @@ void blk_execute_rq_nowait(struct request_queue *q, struct
gendisk *bd_disk,
* be resued after dying flag is set
*/
if (q-mq_ops) {
- blk_mq_insert_request(q, rq, true);
+ blk_mq_insert_request(q, rq, at_head, true);
return;
}
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 57039fc..40fc4dd 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -693,13 +693,16 @@ static void blk_mq_work_fn(struct work_struct *work)
}
static void __blk_mq_insert_request(struct blk_mq_hw_ctx *hctx,
- struct request *rq)
+ struct request *rq, bool at_head)
{
struct blk_mq_ctx *ctx = rq-mq_ctx;
trace_block_rq_insert(hctx-queue, rq);
- list_add_tail(rq-queuelist, ctx-rq_list);
+ if (at_head)
+ list_add(rq-queuelist, ctx-rq_list);
+ else
+ list_add_tail(rq-queuelist, ctx-rq_list);
blk_mq_hctx_mark_pending(hctx, ctx);
/*
@@ -709,7 +712,7 @@ static void __blk_mq_insert_request(struct blk_mq_hw_ctx
*hctx,
}
void blk_mq_insert_request(struct request_queue *q, struct request *rq,
- bool run_queue)
+ bool at_head, bool run_queue)
{
struct blk_mq_hw_ctx *hctx;
struct blk_mq_ctx *ctx, *current_ctx;
@@ -728,7 +731,7 @@ void blk_mq_insert_request(struct request_queue *q, struct
request *rq,
rq-mq_ctx = ctx;
}
spin_lock(ctx-lock);
- __blk_mq_insert_request(hctx, rq);
+ __blk_mq_insert_request(hctx, rq, at_head);
spin_unlock(ctx-lock);
blk_mq_put_ctx(current_ctx);
@@ -760,7 +763,7 @@ void blk_mq_run_request(struct request *rq, bool run_queue,
bool async)
/* ctx-cpu might be offline */
spin_lock(ctx-lock);
- __blk_mq_insert_request(hctx, rq);
+ __blk_mq_insert_request(hctx, rq, false);
spin_unlock(ctx-lock);
blk_mq_put_ctx(current_ctx);
@@ -798,7 +801,7 @@ static void blk_mq_insert_requests(struct request_queue *q,
rq = list_first_entry(list, struct request, queuelist);
list_del_init(rq-queuelist);
rq-mq_ctx = ctx;
- __blk_mq_insert_request(hctx, rq);
+ __blk_mq_insert_request(hctx, rq, false);
}
spin_unlock(ctx-lock);
@@ -950,7 +953,7 @@ static void blk_mq_make_request(struct request_queue *q,
struct bio *bio)
__blk_mq_free_request(hctx, ctx, rq);
else {
blk_mq_bio_to_request(rq, bio);
- __blk_mq_insert_request(hctx, rq);
+ __blk_mq_insert_request(hctx, rq, false);
}
spin_unlock(ctx-lock);
diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
index 161b231..8e6e710 100644
--- a/include/linux/blk-mq.h
+++ b/include/linux/blk-mq.h
@@ -119,7 +119,8 @@ void blk_mq_init_commands(struct request_queue *, void
(*init)(void *data, struc
void blk_mq_flush_plug_list(struct blk_plug *plug, bool from_schedule);
-void blk_mq_insert_request(struct request_queue *, struct request *, bool);
+void blk_mq_insert_request(struct request_queue *, struct request *,
+ bool, bool);
void blk_mq_run_queues(struct request_queue *q, bool async);
void blk_mq_free_request(struct request *rq);
bool blk_mq_can_queue(struct blk_mq_hw_ctx *);
--
1.7.10.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 2/4] blk-mq: divert __blk_put_request for MQ ops
__blk_put_request needs to call into the blk-mq code just like
blk_put_request. As we don't have the queue lock in this case both
end up calling the same function.
Signed-off-by: Christoph Hellwig h...@lst.de
---
block/blk-core.c |5 +
1 file changed, 5 insertions(+)
diff --git a/block/blk-core.c b/block/blk-core.c
index c00e0bd..06636f3 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1278,6 +1278,11 @@ void __blk_put_request(struct request_queue *q, struct
request *req)
if (unlikely(!q))
return;
+ if (q-mq_ops) {
+ blk_mq_free_request(req);
+ return;
+ }
+
blk_pm_put_request(req);
elv_completed_request(q, req);
--
1.7.10.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 4/4] blk-mq: initialize sg_reserved_size
To behave the same way as the old request path. Signed-off-by: Christoph Hellwig h...@lst.de --- block/blk-mq.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/block/blk-mq.c b/block/blk-mq.c index 35800e1..f5fcd9a 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -1373,6 +1373,8 @@ struct request_queue *blk_mq_init_queue(struct blk_mq_reg *reg, q-mq_ops = reg-ops; q-queue_flags |= QUEUE_FLAG_MQ_DEFAULT; + q-sg_reserved_size = INT_MAX; + blk_queue_make_request(q, blk_mq_make_request); blk_queue_rq_timed_out(q, reg-ops-timeout); if (reg-timeout) -- 1.7.10.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 3/4] blk-mq: handle dma_drain_size
Make blk-mq handle the dma_drain_size field the same way as the old request
path.
Signed-off-by: Christoph Hellwig h...@lst.de
---
block/blk-mq.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 40fc4dd..35800e1 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -561,6 +561,16 @@ static void __blk_mq_run_hw_queue(struct blk_mq_hw_ctx
*hctx)
list_del_init(rq-queuelist);
blk_mq_start_request(rq);
+ if (q-dma_drain_size blk_rq_bytes(rq)) {
+ /*
+* make sure space for the drain appears we
+* know we can do this because max_hw_segments
+* has been adjusted to be one fewer than the
+* device can handle
+*/
+ rq-nr_phys_segments++;
+ }
+
/*
* Last request in the series. Flag it as such, this
* enables drivers to know when IO should be kicked off,
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] minor blk-mq updates
On Fri, Feb 07 2014, Christoph Hellwig wrote: Hi Jens, these small blk-mq core updates fell out of the scsi multiqueue work. Thanks, all nice and simple, applied to for-linus. -- Jens Axboe -- 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 06/32] target: Convert lu_gp_ref_cnt to kref
On Thu, 2014-02-06 at 18:56 -0800, Andy Grover wrote: On 02/06/2014 03:51 PM, Nicholas A. Bellinger wrote: The problem with this patch and all of the other patches that follow the same logic is the false assumption that it's safe to return from configfs_group_operations-drop_item() before all references to the underlying data structure containing the associated struct config_group have been dropped. In this particular case, target_core_alua_drop_lu_gp() - config_item_put() - target_core_alua_lu_gp_release() - core_alua_free_lu_gp() is still being called from -drop_item() via target_core_alua_lu_gp_ops-release(), so the same holds true here as well. Yes exactly. That's why the configfs release() doesn't free the lu_gp, it just lowers the lu_gp refcount. release() being called doesn't mean the object is going away, it just means configfs is done with it. If do_port_transition has incremented it in the meantime, the lu_gp won't be freed from the release() (because the underlying object's refcount will still be nonzero) but only when do_port_transition is done. In the normal case where there isn't a ref from do_port_transition, then it is safe to free the lu_gp from release - put_alua_lu_gp - release_alua_lu_gp - kmem_cache_free. It's still completely wrong to return from -drop_item() before all references to the associated struct config_group have dropped because nothing prevents a parent struct config_group (and it's parent above that) from also being removed. The whole point is that this type of parent/child reference counting comes for free with configfs, and patches that introduce changes that don't actually wait for individual references to drop, but instead lazily allow references to drop in the background at their leisure break this model. --nab -- 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
Dynamic scsi_debug module
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is it possible to use the scsi_debug module to create more than one device? It seems to me that it needs rewritten to have an interface to dynamically create devices and set their parameters with a tool like losetup, rather than using module parameters. I found some references to being able to load certain modules multiple times using modprobe -o, but this option does not seem to exist. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS9TOaAAoJEI5FoCIzSKrwEPAH/07+mgbvCIYfJ60DPoZAOIoa tN5D0ABI1Qw3DGIUqHQcdT9pUDcGdXRfO+akBtsvmCGQGI3W7lZphVzie1OwhAEq OiEbeT07EbLCGhP/UY9tmKssAXjeai7UZrbUDfvuvxSgBEmqFzCxyGHMCOAG7pfj iYW38h1xiMq7vZyttSJ4yIFDJnm9IAa8+lemhnqs2XPwzrmpod2yfgJcm4cpxkfY Mcix+qw7YhBNNtuHXk7BSgQDEB01w1dB4jjmTzH0VwUsbf4F45zq5IvI21f/m7DO 9Tzsvhd3DVDgYYpEMJTgnuts9vE0L8hX5xjE50QlT7/izv1XR9gVSwgh8PJOA74= =GLCo -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 13/17] scsi: push host_lock down into scsi_{host,target}_queue_ready
On Fri, 2014-02-07 at 11:32 +0100, Bart Van Assche wrote: On 02/06/14 22:58, Nicholas A. Bellinger wrote: Starting with a baseline using scsi_debug that NOPs REQ_TYPE_FS commands to measure improvements would be a better baseline vs. scsi_request_fn() existing code that what your doing above. That way at least it's easier to measure specific scsi-core overhead down to the LLD's queuecommand without everything else in the way. Running initiator and target workload on the same system makes initiator and target code share CPUs and hence makes it hard to analyze which performance change is caused by initiator optimizations and which performance change is caused by interactions between initiator and target workloads. Huh..? There is no 'target workload' involved. All that scsi_debug with NOP'ed REQ_TYPE_FS commands is doing is calling scsi_cmd-done() as soon as the descriptor has been dispatched into LLD -queuecommand() code. It's useful for determining an absolute performance ceiling between scsi_mq vs. scsi_request_fn() based codepaths without involving any other LLD specific overheads. --nab -- 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 0/4] minor blk-mq updates
On Fri, 2014-02-07 at 10:22 -0800, Christoph Hellwig wrote:
Hi Jens,
these small blk-mq core updates fell out of the scsi multiqueue work.
That reminds me, the following blk-mq patch was required to get DIF
working with scsi-mq.
Jens, care to pick this up as well..?
--nab
From 1428a390cc16025f93905852777d4afd8aeba05d Mon Sep 17 00:00:00 2001
From: Nicholas Bellinger n...@linux-iscsi.org
Date: Sun, 22 Dec 2013 11:58:49 +
Subject: blk-mq: Add bio_integrity setup to blk_mq_make_request
This patch adds the missing bio_integrity_enabled() +
bio_integrity_prep() setup into blk_mq_make_request()
in order to use DIF protection with scsi-mq.
Cc: Jens Axboe ax...@kernel.dk
Cc: Martin K. Petersen martin.peter...@oracle.com
Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org
---
diff --git a/block/blk-mq.c b/block/blk-mq.c
index c79126e..a520c39 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -916,6 +916,11 @@ static void blk_mq_make_request(struct request_queue *q,
struct bio *bio)
blk_queue_bounce(q, bio);
+ if (bio_integrity_enabled(bio) bio_integrity_prep(bio)) {
+ bio_endio(bio, -EIO);
+ return;
+ }
+
if (use_plug blk_attempt_plug_merge(q, bio, request_count))
return;
--
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
[Bug 60758] module scsi_wait_scan not found kernel panic on boot
https://bugzilla.kernel.org/show_bug.cgi?id=60758 kome...@gmail.com changed: What|Removed |Added CC||kome...@gmail.com --- Comment #56 from kome...@gmail.com --- I also tried to introduced something to CentOS 6.5 and KVM on Ubuntu13.10, was the kernel compile the Kernel 3.13.2, but it does not start and continue to be output module scsi_wait_scan not found. In the following, there is no /block/virtio_blk.ko result of the execution of lsinitrd. # Lsinitrd /boot/initramfs-3.13.2.img | grep virt drwxr-xr-x 2 root root 0 Feb 8 00:50 lib/modules/3.13.2/kernel/drivers/virtio -rw-r - r - 1 root root 13216 Feb 8 00:50 lib/modules/3.13.2/kernel/drivers/virtio/virtio.ko -rw-r - r - 1 root root 19944 Feb 8 00:50 lib/modules/3.13.2/kernel/drivers/virtio/virtio_pci.ko -rw-r - r - 1 root root 19448 Feb 8 00:50 lib/modules/3.13.2/kernel/drivers/virtio/virtio_ring.ko it did not improve work even reconfigure the initramfs with dracut. Is there a way to deal about this? -- You are receiving this mail because: You are the assignee for the bug. -- 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: LSI SAS2008 SATA TRIM not working
Kurt == Kurt Miller k...@intricatesoftware.com writes: Kurt Is TRIM working for anyone using LSI SAS2008 controllers? Yes. But its SAT appears to be somewhat selective about which devices it flags as capable. Please send me the output of: # sg_readcap -l /dev/sdc # sg_vpd -p bl /dev/sdc # sg_vpd -p lbpv /dev/sdc -- 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
Re: Dynamic scsi_debug module
Phillip == Phillip Susi ps...@ubuntu.com writes: Phillip Is it possible to use the scsi_debug module to create more than Phillip one device? It seems to me that it needs rewritten to have an Phillip interface to dynamically create devices and set their Phillip parameters with a tool like losetup, rather than using module Phillip parameters. The question is how much sense it makes to invest in scsi_debug now that we have the LIO target in the kernel? -- 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
Re: [PATCH 0/4] minor blk-mq updates
On Fri, Feb 07 2014, Nicholas A. Bellinger wrote: On Fri, 2014-02-07 at 10:22 -0800, Christoph Hellwig wrote: Hi Jens, these small blk-mq core updates fell out of the scsi multiqueue work. That reminds me, the following blk-mq patch was required to get DIF working with scsi-mq. Jens, care to pick this up as well..? Yep, added, thanks! -- Jens Axboe -- 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: LSI SAS2008 SATA TRIM not working
On Thu, 2014-02-06 at 18:56 -0500, Kurt Miller wrote: Various sources indicate that LSI's SAS2008 controllers support TRIM when running their IT firmware (LSI [1] and this list [2]). However, I have not been able to get it working with Dell PERC H200 or H310 cross flashed into LSI IT firmware. Currently I'm testing with Samsung 840 EVO SATA SSDs. I have tried various LSI IT firmware versions (P14, P16, P18) and various Linux distributions (Ubuntu 13.10, Ubuntu 12.04, Ubuntu 14 beta, RHEL 7 beta, Fedora 19). Is TRIM working for anyone using LSI SAS2008 controllers? It turns out yes, TRIM is working for LSI SAS2008 controllers. However, the Samsung 840 EVO's are not compatible with it and are also missing from the LSI compatibility list for the controller [1]. When I got my hands on an SSD that is on the list, TRIM worked as expected. [1] http://www.lsi.com/downloads/Public/Host%20Bus%20Adapters/Host%20Bus %20Adapters%20Common%20Files/LSI_6Gb_SAS_SATA_HBA_Compatibility_List.pdf Regards, -Kurt -- 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: LSI SAS2008 SATA TRIM not working
On Fri, 2014-02-07 at 15:44 -0500, Martin K. Petersen wrote: Kurt == Kurt Miller k...@intricatesoftware.com writes: Kurt Is TRIM working for anyone using LSI SAS2008 controllers? Yes. But its SAT appears to be somewhat selective about which devices it flags as capable. Please send me the output of: # sg_readcap -l /dev/sdc # sg_vpd -p bl /dev/sdc # sg_vpd -p lbpv /dev/sdc Hi Martin, Thank you for your reply. Below is the output you requested. Note that when the EVO's are connected to a SATA AHCI port on my desktop motherboard, TRIM works okay. Please let me know if you need additional information. Regards, -Kurt # sg_readcap -l /dev/sdc Read Capacity results: Protection: prot_en=0, p_type=0, p_i_exponent=0 Logical block provisioning: lbpme=0, lbprz=0 Last logical block address=976773167 (0x3a38602f), Number of logical blocks=976773168 Logical block length=512 bytes Logical blocks per physical block exponent=0 Lowest aligned logical block address=0 Hence: Device size: 500107862016 bytes, 476940.0 MiB, 500.11 GB # sg_vpd -p bl /dev/sdc Block limits VPD page (SBC): Write same no zero (WSNZ): 0 Maximum compare and write length: 0 blocks Optimal transfer length granularity: 0 blocks Maximum transfer length: 0 blocks Optimal transfer length: 0 blocks Maximum prefetch length: 0 blocks Maximum unmap LBA count: 0 Maximum unmap block descriptor count: 0 Optimal unmap granularity: 0 Unmap granularity alignment valid: 0 Unmap granularity alignment: 0 Maximum write same length: 0x0 blocks # sg_vpd -p lbpv /dev/sdc Logical block provisioning VPD page (SBC): Unmap command supported (LBPU): 0 Write same (16) with unmap bit supported (LBWS): 0 Write same (10) with unmap bit supported (LBWS10): 0 Logical block provisioning read zeros (LBPRZ): 0 Anchored LBAs supported (ANC_SUP): 0 Threshold exponent: 0 Descriptor present (DP): 0 Provisioning type: 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: LSI SAS2008 SATA TRIM not working
Kurt == Kurt Miller k...@intricatesoftware.com writes: Kurt Thank you for your reply. Below is the output you requested. Note Kurt that when the EVO's are connected to a SATA AHCI port on my Kurt desktop motherboard, TRIM works okay. Please let me know if you Kurt need additional information. Kurtprovisioning: lbpme=0, lbprz=0 Last logical block ^^^ This indicates the SAT on the mpt2sas board didn't enable discard support for the drive. Please provide the full output of hdparm -I. Maybe we can get some clues as to why that is... -- 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
Re: LSI SAS2008 SATA TRIM not working
On Fri, 2014-02-07 at 15:59 -0500, Martin K. Petersen wrote:
Kurt == Kurt Miller k...@intricatesoftware.com writes:
Kurtprovisioning: lbpme=0, lbprz=0 Last logical block
^^^
This indicates the SAT on the mpt2sas board didn't enable discard
support for the drive.
Please provide the full output of hdparm -I. Maybe we can get some clues
as to why that is...
Thanks again.
# hdparm -I /dev/sdc
/dev/sdc:
ATA device, with non-removable media
Model Number: Samsung SSD 840 EVO 500GB
Serial Number: S1DHNSAD921246E
Firmware Revision: EXT0BB0Q
Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions,
SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
Used: unknown (minor revision code 0x0039)
Supported: 9 8 7 6 5
Likely used: 9
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBAuser addressable sectors: 268435455
LBA48 user addressable sectors: 976773168
Logical Sector size: 512 bytes
Physical Sector size: 512 bytes
Logical Sector-0 offset: 0 bytes
device size with M = 1024*1024: 476940 MBytes
device size with M = 1000*1000: 500107 MBytes (500 GB)
cache/buffer size = unknown
Nominal Media Rotation Rate: Solid State Device
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
*SMART feature set
Security Mode feature set
*Power Management feature set
*Write cache
*Look-ahead
*Host Protected Area feature set
*WRITE_BUFFER command
*READ_BUFFER command
*NOP cmd
*DOWNLOAD_MICROCODE
SET_MAX security extension
*48-bit Address feature set
*Device Configuration Overlay feature set
*Mandatory FLUSH_CACHE
*FLUSH_CACHE_EXT
*SMART error logging
*SMART self-test
*General Purpose Logging feature set
*WRITE_{DMA|MULTIPLE}_FUA_EXT
*64-bit World wide name
Write-Read-Verify feature set
*WRITE_UNCORRECTABLE_EXT command
*{READ,WRITE}_DMA_EXT_GPL commands
*Segmented DOWNLOAD_MICROCODE
*Gen1 signaling speed (1.5Gb/s)
*Gen2 signaling speed (3.0Gb/s)
*Gen3 signaling speed (6.0Gb/s)
*Native Command Queueing (NCQ)
*Phy event counters
*READ_LOG_DMA_EXT equivalent to READ_LOG_EXT
*DMA Setup Auto-Activate optimization
Device-initiated interface power management
*Asynchronous notification (eg. media change)
*Software settings preservation
*SMART Command Transport (SCT) feature set
*SCT Write Same (AC2)
*SCT Error Recovery Control (AC3)
*SCT Features Control (AC4)
*SCT Data Tables (AC5)
*reserved 69[4]
*DOWNLOAD MICROCODE DMA command
*SET MAX SETPASSWORD/UNLOCK DMA commands
*WRITE BUFFER DMA command
*READ BUFFER DMA command
*Data Set Management TRIM supported (limit 8 blocks)
Security:
Master password revision code = 65534
supported
not enabled
not locked
not frozen
not expired: security count
supported: enhanced erase
2min for SECURITY ERASE UNIT. 8min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 50025388a003c374
NAA : 5
IEEE OUI: 002538
Unique ID : 8a003c374
Checksum: correct
--
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: Dynamic scsi_debug module
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/7/2014 3:46 PM, Martin K. Petersen wrote: The question is how much sense it makes to invest in scsi_debug now that we have the LIO target in the kernel? Thanks, I hadn't heard of this. It looks interesting, though a bit complicated. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS9VHPAAoJEI5FoCIzSKrwZAsH/iXhw0Ng+eH8Jnad0/iv00+U ZHDThYnCiTUe9NcxDwQ0gFBkWAXrQsLk6pHajCTXghETt4ZSfhLrM8TU9x128shH FW3z0TfSdLka4Q2V8pA1UOCGTXYF1+/KUtknxE2UWUnXMXiiUcKdlkSmWvfx6UBP 8H4KzLXoPSnmPQ8rGAI1fTWZhvHqYyIqDcRktNg1u3I4CLTUeqmXcudOhs5ZJPNZ BMDH3IKht5P6PpGfWvHvham97ho8Sj4PeoBPQNVjGGu8CtC8fQFkVh1sBezH0M0f mi1Fq9ddEOxgfFlJZAHs15iwCQKepCm4gYArRwrUD24w9s5ceT5Uni57Yxa4W5E= =xQ6u -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 06/17] scsi: add support for per-host cmd pools
On 02/07/2014 06:46 AM, Christoph Hellwig wrote:
On Fri, Feb 07, 2014 at 03:35:00AM -0600, Mike Christie wrote:
It seems there is a issue with using the cmd_size to indicate the driver
has its own cmd pool and also using that for scsi mq enabled drivers to
indicate that we want the LLD's struct allocated by blk/scsi mq.
If a driver sets cmd_size for only the scsi/blk mq purpose, this patch
wants the driver to also setup a cmd pool which I do not think is used
when doing scsi/blk mq.
I don't quite understand what you mean. cmd_size means that each
scsi_cmnd passed to the driver will have additional per-driver data.
For the old path it's implemented by creating a slab cache and storing
it in the host template to easily find it, for blk-mq it is used to
increase the allocation in the block core as scsi doesn't do it's own
allocations in this case.
Ah ok. There is a bug then. I thought you were doing something crazy and
trying to do both at the same time for the same host, and that is why in
the other thread I was asking for a way to figure out where per-driver
data is.
The problem is that if a driver is using scsi-mq and sets cmd_size,
scsi-ml is trying to also setup a shost-cmd_pool. We do:
scsi_add_host_with_dma-scsi_setup_command_freelist-scsi_get_host_cmd_pool-
scsi_find_host_cmd_pool
and that function uses cmd_size to determine if we are using the driver
allocated hostt-cmd_pool or the scsi-ml caches. In the case of where we
are setting cmd_size because we want the mq code to setup the per driver
data we do not want any cmd_pool and have not set one up. The problem is
that scsi_find_host_cmd_pool then returns NULL and
scsi_get_host_cmd_pool does scsi_alloc_host_cmd_pool.
Later when scsi_destroy_command_freelist calls scsi_put_host_cmd_pool,
scsi_find_host_cmd_pool returns NULL again and we oops when we access
the pool in there.
We need something like the attached patch which just prevents scsi-ml
from creating a host pool when mq is used. Note that when
scsi_destroy_command_freelist is called shost-cmd_pool will be NULL so
it will return immediately so no extra check is needed in there.
diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
index f28ea07..2924252 100644
--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -213,9 +213,11 @@ int scsi_add_host_with_dma(struct Scsi_Host *shost, struct
device *dev,
goto fail;
}
- error = scsi_setup_command_freelist(shost);
- if (error)
- goto fail;
+ if (!sht-use_blk_mq) {
+ error = scsi_setup_command_freelist(shost);
+ if (error)
+ goto fail;
+ }
if (!shost-shost_gendev.parent)
shost-shost_gendev.parent = dev ? dev : platform_bus;
Re: Dynamic scsi_debug module
On Fri, 2014-02-07 at 16:36 -0500, Phillip Susi wrote: On 2/7/2014 3:46 PM, Martin K. Petersen wrote: The question is how much sense it makes to invest in scsi_debug now that we have the LIO target in the kernel? Thanks, I hadn't heard of this. It looks interesting, though a bit complicated. Just FYI, a 'apt-get install targetcli' should set you up with everything on the user-space side required to run LIO target + associated fabric drivers. --nab -- 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: LSI SAS2008 SATA TRIM not working
Kurt == Kurt Miller k...@intricatesoftware.com writes: Kurt # hdparm -I /dev/sdc [...] I don't see any deterministic read after trim/read zero after trim support on your drive. And I have a sneaking suspicion that those are two of the fields that the LSI firmware looks at when deciding whether to support logical block provisioning (in addition to support for the DSM TRIM command). -- 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
