Re: [PATCH 13/28] megaraid_sas: switch to generic DMA API
instance->vf_affiliation_111 = > - pci_alloc_consistent(pdev, sizeof(struct > MR_LD_VF_AFFILIATION_111), > - > >vf_affiliation_111_h); > + dma_alloc_coherent(>dev, > + sizeof(struct > MR_LD_VF_AFFILIATION_111), > + >vf_affiliation_111_h, > + GFP_KERNEL); > if (!instance->vf_affiliation_111) > dev_warn(>dev, "Can't allocate " >"memory for VF affiliation buffer\n"); > } else { > instance->vf_affiliation = > - pci_alloc_consistent(pdev, > -(MAX_LOGICAL_DRIVES + 1) > * > -sizeof(struct > MR_LD_VF_AFFILIATION), > - > >vf_affiliation_h); > + dma_alloc_coherent(>dev, > + (MAX_LOGICAL_DRIVES + 1) * > + sizeof(struct MR_LD_VF_AFFILIATION), > + >vf_affiliation_h, > + GFP_KERNEL); > if (!instance->vf_affiliation) > dev_warn(>dev, "Can't allocate " >"memory for VF affiliation buffer\n"); > @@ -6994,19 +6994,19 @@ static void megasas_detach_one(struct pci_dev *pdev) > } > > if (instance->vf_affiliation) > - pci_free_consistent(pdev, (MAX_LOGICAL_DRIVES + 1) * > + dma_free_coherent(>dev, (MAX_LOGICAL_DRIVES + 1) * > sizeof(struct MR_LD_VF_AFFILIATION), > instance->vf_affiliation, > instance->vf_affiliation_h); > > if (instance->vf_affiliation_111) > - pci_free_consistent(pdev, > + dma_free_coherent(>dev, > sizeof(struct MR_LD_VF_AFFILIATION_111), > instance->vf_affiliation_111, > instance->vf_affiliation_111_h); > > if (instance->hb_host_mem) > - pci_free_consistent(pdev, sizeof(struct MR_CTRL_HB_HOST_MEM), > + dma_free_coherent(>dev, sizeof(struct > MR_CTRL_HB_HOST_MEM), > instance->hb_host_mem, > instance->hb_host_mem_h); > > @@ -7254,7 +7254,7 @@ megasas_mgmt_fw_ioctl(struct megasas_instance *instance, > > /* > * We don't change the dma_coherent_mask, so > -* pci_alloc_consistent only returns 32bit addresses > +* dma_alloc_coherent only returns 32bit addresses > */ > if (instance->consistent_mask_64bit) { > kern_sge64[i].phys_addr = cpu_to_le64(buf_handle); > diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c > b/drivers/scsi/megaraid/megaraid_sas_fusion.c > index c7f95bace353..f74b5ea24f0f 100644 > --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c > +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c > @@ -684,8 +684,8 @@ megasas_alloc_rdpq_fusion(struct megasas_instance > *instance) > array_size = sizeof(struct MPI2_IOC_INIT_RDPQ_ARRAY_ENTRY) * > MAX_MSIX_QUEUES_FUSION; > > - fusion->rdpq_virt = pci_zalloc_consistent(instance->pdev, array_size, > - >rdpq_phys); > + fusion->rdpq_virt = dma_zalloc_coherent(>pdev->dev, > + array_size, >rdpq_phys, GFP_KERNEL); > if (!fusion->rdpq_virt) { > dev_err(>pdev->dev, > "Failed from %s %d\n", __func__, __LINE__); > @@ -813,7 +813,7 @@ megasas_free_rdpq_fusion(struct megasas_instance > *instance) { > dma_pool_destroy(fusion->reply_frames_desc_pool_align); > > if (fusion->rdpq_virt) > - pci_free_consistent(instance->pdev, > + dma_free_coherent(>pdev->dev, > sizeof(struct MPI2_IOC_INIT_RDPQ_ARRAY_ENTRY) * > MAX_MSIX_QUEUES_FUSION, > fusion->rdpq_virt, fusion->rdpq_phys); > } > @@ -2209,7 +2209,7 @@ megasas_set_pd_lba(struct MPI2_RAID_SCSI_IO_REQUEST > *io_request, u8 cdb_len, > cdb[0] = MEGASAS_SCSI_VARIABLE_LENGTH_CMD; > cdb[7] = MEGASAS_SCSI_ADDL_CDB_LEN; > > - if (scp->sc_data_direction == PCI_DMA_FROMDEVICE) > + if (scp->sc_data_direction == DMA_FROM_DEVICE) > cdb[9] = MEGASAS_SCSI_SERVICE_ACTION_READ32; > else > cdb[9] = MEGASAS_SCSI_SERVICE_ACTION_WRITE32; > @@ -2238,7 +2238,7 @@ megasas_set_pd_lba(struct MPI2_RAID_SCSI_IO_REQUEST > *io_request, u8 cdb_len, > cdb[31] = (u8)(num_blocks & 0xff); > > /* set SCSI IO EEDPFlags */ > - if (scp->sc_data_direction == PCI_DMA_FROMDEVICE) { > + if (scp->sc_data_direction == DMA_FROM_DEVICE) { > io_request->EEDPFlags = cpu_to_le16( > MPI2_SCSIIO_EEDPFLAGS_INC_PRI_REFTAG | > MPI2_SCSIIO_EEDPFLAGS_CHECK_REFTAG | > @@ -2621,7 +2621,7 @@ megasas_build_ldio_fusion(struct megasas_instance > *instance, > scsi_buff_len = scsi_bufflen(scp); > io_request->DataLength = cpu_to_le32(scsi_buff_len); > > - if (scp->sc_data_direction == PCI_DMA_FROMDEVICE) > + if (scp->sc_data_direction == DMA_FROM_DEVICE) > io_info.isRead = 1; > > local_map_ptr = fusion->ld_drv_map[(instance->map_id & 1)]; > @@ -3088,9 +3088,9 @@ megasas_build_io_fusion(struct megasas_instance > *instance, > > io_request->SGLFlags = cpu_to_le16(MPI2_SGE_FLAGS_64_BIT_ADDRESSING); > > - if (scp->sc_data_direction == PCI_DMA_TODEVICE) > + if (scp->sc_data_direction == DMA_TO_DEVICE) > io_request->Control |= cpu_to_le32(MPI2_SCSIIO_CONTROL_WRITE); > - else if (scp->sc_data_direction == PCI_DMA_FROMDEVICE) > + else if (scp->sc_data_direction == DMA_FROM_DEVICE) > io_request->Control |= cpu_to_le32(MPI2_SCSIIO_CONTROL_READ); > > io_request->SGLOffset0 = Acked-by: Sumit Saxena > -- > 2.19.1 >
RE: [PATCH] scsi: megaraid: Use dma_pool_zalloc()
-Original Message- From: Souptick Joarder [mailto:jrdr.li...@gmail.com] Sent: Thursday, February 15, 2018 9:55 PM To: kashyap.de...@broadcom.com; sumit.sax...@broadcom.com; shivasharan.srikanteshw...@broadcom.com Cc: megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org Subject: [PATCH] scsi: megaraid: Use dma_pool_zalloc() Use dma_pool_zalloc() instead of dma_pool_alloc + memset Signed-off-by: Souptick Joarder <jrdr.li...@gmail.com> --- drivers/scsi/megaraid/megaraid_sas_base.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index a71ee67..905ea36 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -4022,7 +4022,7 @@ static int megasas_create_frame_pool(struct megasas_instance *instance) cmd = instance->cmd_list[i]; - cmd->frame = dma_pool_alloc(instance->frame_dma_pool, + cmd->frame = dma_pool_zalloc(instance->frame_dma_pool, GFP_KERNEL, >frame_phys_addr); cmd->sense = dma_pool_alloc(instance->sense_dma_pool, @@ -4038,7 +4038,6 @@ static int megasas_create_frame_pool(struct megasas_instance *instance) return -ENOMEM; } - memset(cmd->frame, 0, instance->mfi_frame_size); cmd->frame->io.context = cpu_to_le32(cmd->index); cmd->frame->io.pad_0 = 0; if ((instance->adapter_type == MFI_SERIES) && reset_devices) Acked-by: Sumit Saxena <sumit.sax...@broadcom.com> -- 1.9.1
RE: [PATCH] scsi: megaraid: Convert timers to use timer_setup()
-Original Message- From: Kees Cook [mailto:keesc...@chromium.org] Sent: Wednesday, October 25, 2017 3:37 PM To: Martin K. Petersen Cc: Kashyap Desai; Sumit Saxena; Shivasharan S; James E.J. Bottomley; megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org; linux-ker...@vger.kernel.org Subject: [PATCH] scsi: megaraid: Convert timers to use timer_setup() In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. Also consolidates the timer setup functions arguments, which are all identical, and corrects on-stack timer usage. Cc: Kashyap Desai <kashyap.de...@broadcom.com> Cc: Sumit Saxena <sumit.sax...@broadcom.com> Cc: Shivasharan S <shivasharan.srikanteshw...@broadcom.com> Cc: "James E.J. Bottomley" <j...@linux.vnet.ibm.com> Cc: "Martin K. Petersen" <martin.peter...@oracle.com> Cc: megaraidlinux@broadcom.com Cc: linux-scsi@vger.kernel.org Signed-off-by: Kees Cook <keesc...@chromium.org> --- drivers/scsi/megaraid/megaraid_ioctl.h | 6 + drivers/scsi/megaraid/megaraid_mbox.c | 26 ++--- drivers/scsi/megaraid/megaraid_mm.c | 27 +++--- drivers/scsi/megaraid/megaraid_sas_base.c | 35 +++-- drivers/scsi/megaraid/megaraid_sas_fusion.c | 15 +++-- 5 files changed, 47 insertions(+), 62 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_ioctl.h b/drivers/scsi/megaraid/megaraid_ioctl.h index 05f6e4ec3453..eedcbde46459 100644 --- a/drivers/scsi/megaraid/megaraid_ioctl.h +++ b/drivers/scsi/megaraid/megaraid_ioctl.h @@ -19,6 +19,7 @@ #include #include +#include #include "mbox_defs.h" @@ -153,6 +154,11 @@ typedef struct uioc { } __attribute__ ((aligned(1024),packed)) uioc_t; +/* For on-stack uioc timers. */ +struct uioc_timeout { + struct timer_list timer; + uioc_t*uioc; +}; /** * struct mraid_hba_info - information about the controller diff --git a/drivers/scsi/megaraid/megaraid_mbox.c b/drivers/scsi/megaraid/megaraid_mbox.c index ec3c43854978..530358cdcb39 100644 --- a/drivers/scsi/megaraid/megaraid_mbox.c +++ b/drivers/scsi/megaraid/megaraid_mbox.c @@ -3904,19 +3904,19 @@ megaraid_sysfs_get_ldmap_done(uioc_t *uioc) wake_up(_dev->sysfs_wait_q); } - /** * megaraid_sysfs_get_ldmap_timeout - timeout handling for get ldmap - * @data : timed out packet + * @t : timed out timer * * Timeout routine to recover and return to application, in case the adapter * has stopped responding. A timeout of 60 seconds for this command seems like * a good value. */ static void -megaraid_sysfs_get_ldmap_timeout(unsigned long data) +megaraid_sysfs_get_ldmap_timeout(struct timer_list *t) { - uioc_t *uioc = (uioc_t *)data; + struct uioc_timeout *timeout = from_timer(timeout, t, timer); + uioc_t *uioc = timeout->uioc; adapter_t *adapter = (adapter_t *)uioc->buf_vaddr; mraid_device_t *raid_dev = ADAP2RAIDDEV(adapter); @@ -3951,8 +3951,7 @@ megaraid_sysfs_get_ldmap(adapter_t *adapter) mbox64_t*mbox64; mbox_t *mbox; char*raw_mbox; - struct timer_list sysfs_timer; - struct timer_list *timerp; + struct uioc_timeout timeout; caddr_t ldmap; int rval = 0; @@ -3988,14 +3987,12 @@ megaraid_sysfs_get_ldmap(adapter_t *adapter) /* * Setup a timer to recover from a non-responding controller */ - timerp = _timer; - init_timer(timerp); - - timerp->function= megaraid_sysfs_get_ldmap_timeout; - timerp->data= (unsigned long)uioc; - timerp->expires = jiffies + 60 * HZ; + timeout.uioc = uioc; + timer_setup_on_stack(, +megaraid_sysfs_get_ldmap_timeout, 0); Kees, Does calling "timer_setup_on_stack" instead of "timer_setup" intentional ? If yes, please help me understand the reason. Otherwise changes look good to me. - add_timer(timerp); + timeout.timer.expires = jiffies + 60 * HZ; + add_timer(); /* * Send the command to the firmware @@ -4033,7 +4030,8 @@ megaraid_sysfs_get_ldmap(adapter_t *adapter) } - del_timer_sync(timerp); + del_timer_sync(); + destroy_timer_on_stack(); mutex_unlock(_dev->sysfs_mtx); diff --git a/drivers/scsi/megaraid/megaraid_mm.c b/drivers/scsi/megaraid/megaraid_mm.c index 65b6f6ace3a5..bb802b0c12b8 100644 --- a/drivers/scsi/megaraid/megaraid_mm.c +++ b/drivers/scsi/megaraid/megaraid_mm.c @@ -35,7 +35,7 @@ static int kioc_to_mimd(uioc_t *, mimd_t __user *); static int handle_drvrcmd(void __user *, ui
RE: [PATCH 1/2] scsi: megaraid: Remove redundant code in megasas_alloc_cmds
-Original Message- From: Yisheng Xie [mailto:xieyishe...@huawei.com] Sent: Wednesday, October 25, 2017 3:27 PM To: kashyap.de...@broadcom.com; sumit.sax...@broadcom.com; shivasharan.srikanteshw...@broadcom.com; j...@linux.vnet.ibm.com; martin.peter...@oracle.com Cc: megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org; linux-ker...@vger.kernel.org; Yisheng Xie Subject: [PATCH 1/2] scsi: megaraid: Remove redundant code in megasas_alloc_cmds megasas_alloc_cmds is to alloc cmd_list of instance instead of fusion, and fusion is useless in this function. Just remove it. Signed-off-by: Yisheng Xie <xieyishe...@huawei.com> --- drivers/scsi/megaraid/megaraid_sas_base.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index e518dad..0640168 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -4033,9 +4033,7 @@ int megasas_alloc_cmds(struct megasas_instance *instance) int j; u16 max_cmd; struct megasas_cmd *cmd; - struct fusion_context *fusion; - fusion = instance->ctrl_context; max_cmd = instance->max_mfi_cmds; /* Acked-by: Sumit Saxena <sumit.sax...@broadcom.com> -- 1.7.12.4
RE: [PATCH] megaraid: kmemleak: Track page allocation for fusion
-Original Message- From: shuw...@redhat.com [mailto:shuw...@redhat.com] Sent: Thursday, September 14, 2017 11:47 AM To: kashyap.de...@broadcom.com; sumit.sax...@broadcom.com; shivasharan.srikanteshw...@broadcom.com; j...@linux.vnet.ibm.com; martin.peter...@oracle.com Cc: megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org; linux-ker...@vger.kernel.org; catalin.mari...@arm.com; liw...@redhat.com; ch...@redhat.com; Shu Wang Subject: [PATCH] megaraid: kmemleak: Track page allocation for fusion From: Shu Wang <shuw...@redhat.com> Kmemleak reports about a thousand false positives for fusion-> cmd_list[]. Root casue is the cmd_list objects are allocated from slab allocator, and stored its pointer in object allocated by page allocator. The fix will tell kmemleak to track and scan fusion object. Before patch: kmemleak: 1004 new suspected memory leaks (see /sys/kernel/debug/kmemleak) unreferenced object 0x88042584e000 (size 8192): backtrace: kmemleak_alloc+0x4a/0xa0 __kmalloc+0xec/0x220 megasas_alloc_cmdlist_fusion+0x3e/0x140 [megaraid_sas] megasas_alloc_cmds_fusion+0x44/0x450 [megaraid_sas] megasas_init_adapter_fusion+0x21d/0x6e0 [megaraid_sas] megasas_init_fw+0x357/0xd30 [megaraid_sas] megasas_probe_one.part.34+0x5be/0x1040 [megaraid_sas] megasas_probe_one+0x46/0xc0 [megaraid_sas] local_pci_probe+0x45/0xa0 work_for_cpu_fn+0x14/0x20 process_one_work+0x149/0x360 worker_thread+0x1d8/0x3c0 kthread+0x109/0x140 ret_from_fork+0x25/0x30 Signed-off-by: Shu Wang <shuw...@redhat.com> --- drivers/scsi/megaraid/megaraid_sas_fusion.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c b/drivers/scsi/megaraid/megaraid_sas_fusion.c index 11bd2e698b84..621299edd8de 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c @@ -48,6 +48,7 @@ #include #include #include +#include #include #include @@ -4512,7 +4513,9 @@ megasas_alloc_fusion_context(struct megasas_instance *instance) dev_err(>pdev->dev, "Failed from %s %d\n", __func__, __LINE__); return -ENOMEM; } - } + } else + kmemleak_alloc(instance->ctrl_context, + sizeof(struct fusion_context), 1, GFP_KERNEL); fusion = instance->ctrl_context; @@ -4548,9 +4551,11 @@ megasas_free_fusion_context(struct megasas_instance *instance) if (is_vmalloc_addr(fusion)) vfree(fusion); - else + else { free_pages((ulong)fusion, instance->ctrl_context_pages); + kmemleak_free(fusion); + } } } Looks good. Thanks for catching this. Acked-by: Sumit Saxena <sumit.sax...@broadcom.com> -- 2.13.5
RE: [PATCH] megaraid_sas: boot hangs while LD is offline
>-Original Message- >From: Hannes Reinecke [mailto:h...@suse.de] >Sent: Tuesday, August 15, 2017 5:29 PM >To: Martin K. Petersen >Cc: Christoph Hellwig; James Bottomley; Sumit Saxena; Kashyap Desai; >megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org; Hannes >Reinecke; Hannes Reinecke >Subject: [PATCH] megaraid_sas: boot hangs while LD is offline > >Offline Logical drives (LDs) should not allowed to be visible to the OS, as the >OS will hang trying to send commands to it. >This patch skips offline LDs like it already does for non-system physical drives >(PDs). Hi Hannes, You have submitted this patch in past as it was part of SLES kernel but missing in upstream and it was concluded to drop this patch then. This issue was fixed in firmware 4 years back and many firmware versions should be available with the fix so this fix is not required in driver(upstream as well SLES kernel). Do you see any functional issue without this patch ? If not, I would request to back out this patch from SLES kernel also. Thanks, Sumit > >Signed-off-by: Hannes Reinecke <h...@suse.com> >--- > drivers/scsi/megaraid/megaraid_sas_base.c | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > >diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c >b/drivers/scsi/megaraid/megaraid_sas_base.c >index 5202c2f..39b08fc 100644 >--- a/drivers/scsi/megaraid/megaraid_sas_base.c >+++ b/drivers/scsi/megaraid/megaraid_sas_base.c >@@ -1897,14 +1897,19 @@ static void >megasas_set_static_target_properties(struct scsi_device *sdev, > > static int megasas_slave_configure(struct scsi_device *sdev) { >- u16 pd_index = 0; >+ u16 pd_index = 0, ld_index; > struct megasas_instance *instance; > int ret_target_prop = DCMD_FAILED; > bool is_target_prop = false; > > instance = megasas_lookup_instance(sdev->host->host_no); > if (instance->pd_list_not_supported) { >- if (!MEGASAS_IS_LOGICAL(sdev) && sdev->type == >TYPE_DISK) { >+ if (MEGASAS_IS_LOGICAL(sdev)) { >+ ld_index = ((sdev->channel - >MEGASAS_MAX_PD_CHANNELS) * >+ MEGASAS_MAX_DEV_PER_CHANNEL) + >sdev->id; >+ if (instance->ld_ids[ld_index] == 0xff) >+ return -ENXIO; >+ } else if (sdev->type == TYPE_DISK) { > pd_index = (sdev->channel * >MEGASAS_MAX_DEV_PER_CHANNEL) + > sdev->id; > if (instance->pd_list[pd_index].driveState != >-- >1.8.5.6
RE: [PATCH] megaraid_sas: Fallback to older scanning if no disks are found
>-Original Message- >From: Hannes Reinecke [mailto:h...@suse.de] >Sent: Tuesday, August 15, 2017 5:36 PM >To: Martin K. Petersen >Cc: Christoph Hellwig; James Bottomley; Sumit Saxena; Kashyap Desai; >megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org; Hannes >Reinecke >Subject: [PATCH] megaraid_sas: Fallback to older scanning if no disks are >found > >commit 21c9e160a51383d4cb0b882398534b0c95c0cc3b implemented a new >driver lookup using the MR_DCMD_LD_LIST_QUERY firmware command. >However, this command might not work properly on older firmware, causing >the command to return no drives instead of an error. >This causes a regression on older firmware as the driver will no longer detect >any drives. >This patch checks if MR_DCMD_LD_LIST_QUERY return no drives, and falls >back to the original method if so. > >Signed-off-by: Hannes Reinecke <h...@suse.de> >--- > drivers/scsi/megaraid/megaraid_sas_base.c | 29 >+++-- > 1 file changed, 23 insertions(+), 6 deletions(-) > >diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c >b/drivers/scsi/megaraid/megaraid_sas_base.c >index 39b08fc..a1cf2c3 100644 >--- a/drivers/scsi/megaraid/megaraid_sas_base.c >+++ b/drivers/scsi/megaraid/megaraid_sas_base.c >@@ -4502,7 +4502,6 @@ int megasas_alloc_cmds(struct megasas_instance >*instance) > dev_info(>pdev->dev, > "DCMD not supported by firmware - %s %d\n", > __func__, __LINE__); >- ret = megasas_get_ld_list(instance); > break; > case DCMD_TIMEOUT: > switch (dcmd_timeout_ocr_possible(instance)) { @@ -4530,6 >+4529,14 @@ int megasas_alloc_cmds(struct megasas_instance *instance) > break; > case DCMD_SUCCESS: > tgtid_count = le32_to_cpu(ci->count); >+ /* >+ * Some older firmware return '0' if the LD LIST QUERY >+ * command is not supported. >+ */ >+ if (tgtid_count == 0) { >+ ret = DCMD_FAILED; >+ break; >+ } If firmware does not support LD_LIST_QUERY, "DCMD_FAILED" should be returned by megasas_issue_blocked_cmd (function which fires command to firmware) instead of DCMD_SCCESS. Can you please help with older firmware version which returns DCMD_SUCCESS(0) if LD_LIST_QUERY is not supported ? "tgtid_count" may be zero(in case of no logical disks configured) even when firmware supports LD LIST QUERY and in that case also driver will fire old command by calling megasas_get_ld_list() but that's not a problem. Thanks, Sumit > > if ((tgtid_count > (instance->fw_supported_vd_count))) > break; >@@ -5146,7 +5153,7 @@ static int megasas_init_fw(struct megasas_instance >*instance) > struct megasas_register_set __iomem *reg_set; > struct megasas_ctrl_info *ctrl_info = NULL; > unsigned long bar_list; >- int i, j, loop, fw_msix_count = 0; >+ int i, j, loop, fw_msix_count = 0, ret; > struct IOV_111 *iovPtr; > struct fusion_context *fusion; > >@@ -5384,8 +5391,11 @@ static int megasas_init_fw(struct megasas_instance >*instance) > } > } > >- if (megasas_ld_list_query(instance, >-MR_LD_QUERY_TYPE_EXPOSED_TO_HOST)) >+ ret = megasas_ld_list_query(instance, >+ MR_LD_QUERY_TYPE_EXPOSED_TO_HOST); >+ if (ret == DCMD_FAILED) >+ ret = megasas_get_ld_list(instance); >+ if (ret) > goto fail_get_ld_pd_list; > > /* >@@ -7426,8 +7436,12 @@ static inline void >megasas_remove_scsi_device(struct scsi_device *sdev) > case MR_EVT_LD_DELETED: > case MR_EVT_LD_CREATED: > if (!instance->requestorId || >- (instance->requestorId && >megasas_get_ld_vf_affiliation(instance, 0))) >+ (instance->requestorId && >+ megasas_get_ld_vf_affiliation(instance, 0))) { > dcmd_ret = megasas_ld_list_query(instance, >MR_LD_QUERY_TYPE_EXPOSED_TO_HOST); >+ if (dcmd_ret == DCMD_FAILED) >+ dcmd_ret = >megasas_get_ld_list(instance); >+ } > > if (dcmd_ret == DCMD_SUCCESS) > doscan = SCAN_VD_CHANNEL; >@@ -7443,8 +7457,11 @@ static inline void >megasas_remove_scsi_device(struct scsi_device *sdev) &g
RE: [PATCH v2] scsi: megaraid_sas: fix allocate instance->pd_info twice
>-Original Message- >From: weiping zhang [mailto:zhangweip...@didichuxing.com] >Sent: Tuesday, August 08, 2017 10:46 AM >To: kashyap.de...@broadcom.com; sumit.sax...@broadcom.com; >shivasharan.srikanteshw...@broadcom.com >Cc: megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org >Subject: [PATCH v2] scsi: megaraid_sas: fix allocate instance->pd_info twice > >fix allocate instance->pd_info twice which was introduced by 96188a89cc6d. > >Signed-off-by: weiping zhang <zhangweip...@didichuxing.com> >--- > drivers/scsi/megaraid/megaraid_sas_base.c | 8 +++- > 1 file changed, 3 insertions(+), 5 deletions(-) > >diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c >b/drivers/scsi/megaraid/megaraid_sas_base.c >index 71c4746..a0f057c 100644 >--- a/drivers/scsi/megaraid/megaraid_sas_base.c >+++ b/drivers/scsi/megaraid/megaraid_sas_base.c >@@ -6096,14 +6096,12 @@ static int megasas_probe_one(struct pci_dev >*pdev, > instance->pd_info = pci_alloc_consistent(pdev, > sizeof(struct MR_PD_INFO), >pd_info_h); > >- instance->pd_info = pci_alloc_consistent(pdev, >- sizeof(struct MR_PD_INFO), >pd_info_h); >- instance->tgt_prop = pci_alloc_consistent(pdev, >- sizeof(struct MR_TARGET_PROPERTIES), >>tgt_prop_h); >- > if (!instance->pd_info) > dev_err(>pdev->dev, "Failed to alloc mem >for pd_info\n"); > >+ instance->tgt_prop = pci_alloc_consistent(pdev, >+ sizeof(struct MR_TARGET_PROPERTIES), >>tgt_prop_h); >+ > if (!instance->tgt_prop) > dev_err(>pdev->dev, "Failed to alloc mem >for tgt_prop\n"); Acked-by: Sumit Saxena <sumit.sax...@broadcom.com> > >-- >2.9.4
RE: [PATCH] megaraid_sas: move command counter to correct place
>-Original Message- >From: Martin K. Petersen [mailto:martin.peter...@oracle.com] >Sent: Monday, August 07, 2017 11:07 PM >To: Tomas Henzl >Cc: linux-scsi@vger.kernel.org; sumit.sax...@broadcom.com; >kashyap.de...@broadcom.com >Subject: Re: [PATCH] megaraid_sas: move command counter to correct place > > >Tomas, > >> the eh reset function returns success when fw_outstanding equals zero, >> that means that the counter shouldn't be decremented when the driver >> still owns the command > >Applied to 4.13/scsi-fixes. Thank you! Just realized that this patch may cause performance regression. With this patch below scenario may occur- -Consider outstanding IOs reaches to controller's Queue depth. -Driver frees up command and complete it back to SML. -Since host_busy is decremented, SML can issue one new IO to driver. -By the time, if "fw_outstanding" is not decremented by driver, then driver will return newly submitted IO back to SML with return status SCSI_MLQUEUE_HOST_BUSY because of below code in megaraid_sas driver's IO submission path- if (atomic_inc_return(>fw_outstanding) > instance->host->can_queue) { atomic_dec(>fw_outstanding); return SCSI_MLQUEUE_HOST_BUSY; } This situation will be more evident when RAID1 fastpath IOs are running as in that case driver will be issuing two IOs to firmware for single IO issued from SML. Above situation can be avoided, if this patch is removed. Regarding Tomas' concern, there should not be any problem as driver calls "synchronize_irq" before checking "fw_outstanding". Once fw_outstanding is decremented and driver frees up command, then only driver will be checking "fw_outstanding" equals to zero or not so all this will always fall in a sequence and will not cause the problem stated by Tomas. I am sorry for confusion and would request to revert this patch. Thanks, Sumit > >-- >Martin K. Petersen Oracle Linux Engineering
RE: [PATCH] scsi: megaraid_sas: fix error handle in megasas_probe_one
>-Original Message- >From: weiping zhang [mailto:zhangweip...@didichuxing.com] >Sent: Monday, August 07, 2017 10:57 PM >To: kashyap.de...@broadcom.com; sumit.sax...@broadcom.com; >shivasharan.srikanteshw...@broadcom.com >Cc: megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org >Subject: [PATCH] scsi: megaraid_sas: fix error handle in megasas_probe_one > >megasas_mgmt_info.max_index has increased by 1 before >megasas_io_attach, if megasas_io_attach return error, then goto >fail_io_attach, megasas_mgmt_info.instance has a wrong index here. So first >reduce max_index and then set that instance to NULL. > >Signed-off-by: weiping zhang <zhangweip...@didichuxing.com> >--- > drivers/scsi/megaraid/megaraid_sas_base.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c >b/drivers/scsi/megaraid/megaraid_sas_base.c >index b5b9ba7..91eeec9 100644 >--- a/drivers/scsi/megaraid/megaraid_sas_base.c >+++ b/drivers/scsi/megaraid/megaraid_sas_base.c >@@ -6226,8 +6226,8 @@ static int megasas_probe_one(struct pci_dev *pdev, > fail_start_aen: > fail_io_attach: > megasas_mgmt_info.count--; >- megasas_mgmt_info.instance[megasas_mgmt_info.max_index] = >NULL; > megasas_mgmt_info.max_index--; >+ megasas_mgmt_info.instance[megasas_mgmt_info.max_index] = >NULL; > > instance->instancet->disable_intr(instance); > megasas_destroy_irqs(instance); Acked-by: Sumit Saxena <sumit.sax...@broadcom.com> >-- >2.9.4
RE: [PATCH] megaraid_sas: move command counter to correct place
>-Original Message- >From: Tomas Henzl [mailto:the...@redhat.com] >Sent: Friday, July 28, 2017 7:34 PM >To: linux-scsi@vger.kernel.org >Cc: sumit.sax...@broadcom.com; kashyap.de...@broadcom.com >Subject: [PATCH] megaraid_sas: move command counter to correct place > >the eh reset function returns success when fw_outstanding equals zero, that >means that the counter shouldn't be decremented when the driver still owns >the command > > >Signed-off-by: Tomas Henzl <the...@redhat.com> >--- > drivers/scsi/megaraid/megaraid_sas_fusion.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c >b/drivers/scsi/megaraid/megaraid_sas_fusion.c >index f990ab4d45..c615aadb2b 100644 >--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c >+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c >@@ -3046,7 +3046,6 @@ complete_cmd_fusion(struct megasas_instance >*instance, u32 MSIxIndex) > } > //Fall thru and complete IO > case MEGASAS_MPI2_FUNCTION_LD_IO_REQUEST: /* LD-IO >Path */ >- atomic_dec(>fw_outstanding); > if (cmd_fusion->r1_alt_dev_handle == >MR_DEVHANDLE_INVALID) { > map_cmd_status(fusion, scmd_local, status, > extStatus, >le32_to_cpu(data_length), @@ -3060,6 +3059,7 @@ >complete_cmd_fusion(struct megasas_instance *instance, u32 MSIxIndex) > scmd_local->scsi_done(scmd_local); > } else /* Optimal VD - R1 FP command completion. >*/ > megasas_complete_r1_command(instance, >cmd_fusion); >+ atomic_dec(>fw_outstanding); > break; > case MEGASAS_MPI2_FUNCTION_PASSTHRU_IO_REQUEST: >/*MFI command */ > cmd_mfi = instance->cmd_list[cmd_fusion- >>sync_cmd_idx]; Acked-by: Sumit Saxena <sumit.sax...@broadcom.com> >-- >2.9.4
RE: [PATCH] scsi: megaraid_sas: fix memleak in megasas_alloc_cmdlist_fusion
>-Original Message- >From: shuw...@redhat.com [mailto:shuw...@redhat.com] >Sent: Friday, July 21, 2017 4:24 PM >To: kashyap.de...@broadcom.com; sumit.sax...@broadcom.com; >shivasharan.srikanteshw...@broadcom.com; j...@linux.vnet.ibm.com; >martin.peter...@oracle.com >Cc: megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org; linux- >ker...@vger.kernel.org; ch...@redhat.com; liw...@redhat.com; Shu Wang >Subject: [PATCH] scsi: megaraid_sas: fix memleak in >megasas_alloc_cmdlist_fusion > >From: Shu Wang <shuw...@redhat.com> > >Found this issue by kmemleak, a few kb mem was leaked in >megasas_alloc_cmdlist_fusion when kzalloc failed for one >megasas_cmd_fusion allocation. > >unreferenced object 0x88045dbd2000 (size 8192): > comm "systemd-udevd", pid 323, jiffies 4294671759 (age 49.008s) > backtrace: >[] kmemleak_alloc+0x4a/0xa0 >[] __kmalloc+0xe8/0x220 >[] megasas_alloc_cmdlist_fusion+0x34/0xe0 >[megaraid_sas] >(gdb) list *megasas_alloc_cmdlist_fusion+0x34 >0xd5c4 is in megasas_alloc_cmdlist_fusion > (drivers/scsi/megaraid/megaraid_sas_fusion.c:443). >[] megasas_alloc_cmds_fusion+0x25/0x410 >[megaraid_sas] >[] megasas_init_adapter_fusion+0x21f/0x640 >[megaraid_sas] >[] megasas_init_fw+0x357/0xd30 [megaraid_sas] >[] megasas_probe_one.part.33+0x636/0x1100 >[megaraid_sas] >[] megasas_probe_one+0x46/0xc0 [megaraid_sas] >[] local_pci_probe+0x45/0xa0 >[] pci_device_probe+0x192/0x1b0 >[] driver_probe_device+0x2a8/0x460 >[] __driver_attach+0xdd/0xe0 >[] bus_for_each_dev+0x6c/0xc0 >[] driver_attach+0x1e/0x20 >[] bus_add_driver+0x45/0x270 >[] driver_register+0x60/0xe0 unreferenced object >0x880454ce3600 (size 192): > backtrace: >[] kmemleak_alloc+0x4a/0xa0 >[] kmem_cache_alloc_trace+0xca/0x1d0 >[] megasas_alloc_cmdlist_fusion+0x77/0xe0 >[megaraid_sas] >(gdb) list *megasas_alloc_cmdlist_fusion+0x77 >0xd607 is in megasas_alloc_cmdlist_fusion >(drivers/scsi/megaraid/megaraid_sas_fusion.c:450). >[] megasas_alloc_cmds_fusion+0x25/0x410 >[megaraid_sas] >[] megasas_init_adapter_fusion+0x21f/0x640 >[megaraid_sas] >[] megasas_init_fw+0x357/0xd30 [megaraid_sas] >[] megasas_probe_one.part.33+0x636/0x1100 >[megaraid_sas] >[] megasas_probe_one+0x46/0xc0 [megaraid_sas] >[] local_pci_probe+0x45/0xa0 >[] pci_device_probe+0x192/0x1b0 >[] driver_probe_device+0x2a8/0x460 >[] __driver_attach+0xdd/0xe0 >[] bus_for_each_dev+0x6c/0xc0 >[] driver_attach+0x1e/0x20 >[] bus_add_driver+0x45/0x270 >[] driver_register+0x60/0xe0 > >Signed-off-by: Shu Wang <shuw...@redhat.com> >--- > drivers/scsi/megaraid/megaraid_sas_fusion.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > >diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c >b/drivers/scsi/megaraid/megaraid_sas_fusion.c >index f990ab4d..9855106 100644 >--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c >+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c >@@ -425,7 +425,7 @@ static int megasas_create_sg_sense_fusion(struct >megasas_instance *instance) int megasas_alloc_cmdlist_fusion(struct >megasas_instance *instance) { >- u32 max_mpt_cmd, i; >+ u32 max_mpt_cmd, i, j; > struct fusion_context *fusion; > > fusion = instance->ctrl_context; >@@ -450,11 +450,15 @@ megasas_alloc_cmdlist_fusion(struct >megasas_instance *instance) > fusion->cmd_list[i] = kzalloc(sizeof(struct >megasas_cmd_fusion), > GFP_KERNEL); > if (!fusion->cmd_list[i]) { >+ for (j = 0; j < i; j++) >+ kfree(fusion->cmd_list[j]); >+ kfree(fusion->cmd_list); > dev_err(>pdev->dev, > "Failed from %s %d\n", __func__, __LINE__); > return -ENOMEM; > } > } >+ > return 0; > } > int Acked-by: Sumit Saxena <sumit.sax...@broadcom.com> >-- >2.5.0
RE: [PATCH 1/2] Drop legacy megaraid controller
>-Original Message- >From: Hannes Reinecke [mailto:h...@suse.de] >Sent: Friday, June 30, 2017 11:46 PM >To: Christoph Hellwig >Cc: Martin K. Petersen; James Bottomley; Kashyap Desai; Sumit Saxena; >linux- >s...@vger.kernel.org; Hannes Reinecke >Subject: Re: [PATCH 1/2] Drop legacy megaraid controller > >On 06/30/2017 07:33 PM, Christoph Hellwig wrote: >> On Fri, Jun 30, 2017 at 01:05:53PM +0200, Hannes Reinecke wrote: >>> The hardware is ancient, and support for most cards has been moved to >>> megaraid_mbox. So drop it. >> >> >> This seems to drop support for the PCI_DEVICE_ID_AMI_MEGARAID and >> PCI_DEVICE_ID_AMI_MEGARAID2 cards. Do we have any suggestions this >> code is so broken to not care anymore? Is there any reason why they >> can't just work with the megaraid_mbox driver? >> >Hmm. Probably no good reason at all. >I'll check which version I have here. Hannes, We are willing to keep only megaraid_sas driver and intent is rest of megaraid* drivers (it includes megaraid, megaraid_mm, megaraid_mbox) should be removed. Broadcom(LSI) has stopped supporting hardware associated with these old drivers. Thanks, Sumit > >Cheers, > >Hannes >-- >Dr. Hannes Reinecke Teamlead Storage & Networking >h...@suse.de +49 911 74053 688 >SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg >GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 >(AG Nürnberg)
RE: [PATCH 13/47] megaraid: pass in NULL scb for host reset
>-Original Message- >From: Hannes Reinecke [mailto:h...@suse.de] >Sent: Thursday, June 29, 2017 11:23 AM >To: Kashyap Desai; Sumit Saxena; Christoph Hellwig >Cc: Martin K. Petersen; James Bottomley; linux-scsi@vger.kernel.org; Hannes >Reinecke >Subject: Re: [PATCH 13/47] megaraid: pass in NULL scb for host reset > >On 06/28/2017 07:40 PM, Kashyap Desai wrote: >>> -Original Message- >>> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- >>> ow...@vger.kernel.org] On Behalf Of Hannes Reinecke >>> Sent: Wednesday, June 28, 2017 9:00 PM >>> To: Sumit Saxena; Christoph Hellwig >>> Cc: Martin K. Petersen; James Bottomley; linux-scsi@vger.kernel.org; >>> Hannes Reinecke >>> Subject: Re: [PATCH 13/47] megaraid: pass in NULL scb for host reset >>> >>> On 06/28/2017 03:41 PM, Sumit Saxena wrote: >>>>> -Original Message- >>>>> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- >>>>> ow...@vger.kernel.org] On Behalf Of Hannes Reinecke >>>>> Sent: Wednesday, June 28, 2017 2:03 PM >>>>> To: Christoph Hellwig >>>>> Cc: Martin K. Petersen; James Bottomley; >>>>> linux-scsi@vger.kernel.org; >>>> Hannes >>>>> Reinecke; Hannes Reinecke >>>>> Subject: [PATCH 13/47] megaraid: pass in NULL scb for host reset >>>>> >>>>> When calling a host reset we shouldn't rely on the command >>>>> triggering the reset, so allow megaraid_abort_and_reset() to be >>>>> called with a NULL >>> scb. >>>>> And drop the pointless 'bus_reset' and 'target_reset' handlers, >>>>> which >>>> just call >>>>> the same function as host_reset. >>>> >>>> If this patch address any functional issue, then we should consider >>>> this. >>>> If it's code optimization, can we ignore this as this is being very >>>> old driver and no more maintained by Broadcom/LSI ? >>>> >>> Sadly, ignoring is not an option. >>> I'm planning to update the calling convention for SCSI EH, to resolve >>> the >>> long- >>> standing problem with sg_reset ioctls. >>> sg_reset ioctl will allocate an out-of-band SCSI command, which does >>> no longer work with the new command allocation scheme in multiqueue. >>> So it's not possible to just 'ignore' it, as then SCSI EH will cease >>> to function with that driver. >> >> Hannes - We are in process of sending megaraid and 3ware driver >> removal as LSI/Broadcom stopped supporting those products. >> I agree we should review this closely, but lack of test coverage and >> end of life cycle of product is requesting us to know the rational. >> For now, let's consider NACK for this patch. We will be removing old >> megaraid (mbox) driver and 3Ware drivers soon. >> >Hmm. >Can't we do the removal now? >There is not a lot of testing involved with _that_, surely? > >I'd be happy to do a patch if you like ... We are fine with you submitting the patch to remove megaraid and megaraid_mm drivers. 3ware drivers are maintained by Adam Radford so we can not remove them. > >Cheers, > >Hannes >-- >Dr. Hannes Reinecke Teamlead Storage & Networking >h...@suse.de +49 911 74053 688 >SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg >GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 >(AG Nürnberg)
RE: [PATCH 13/47] megaraid: pass in NULL scb for host reset
>-Original Message- >From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- >ow...@vger.kernel.org] On Behalf Of Hannes Reinecke >Sent: Wednesday, June 28, 2017 2:03 PM >To: Christoph Hellwig >Cc: Martin K. Petersen; James Bottomley; linux-scsi@vger.kernel.org; Hannes >Reinecke; Hannes Reinecke >Subject: [PATCH 13/47] megaraid: pass in NULL scb for host reset > >When calling a host reset we shouldn't rely on the command triggering the >reset, so allow megaraid_abort_and_reset() to be called with a NULL scb. >And drop the pointless 'bus_reset' and 'target_reset' handlers, which just call >the same function as host_reset. If this patch address any functional issue, then we should consider this. If it's code optimization, can we ignore this as this is being very old driver and no more maintained by Broadcom/LSI ? > >Signed-off-by: Hannes Reinecke>--- > drivers/scsi/megaraid.c | 42 -- > 1 file changed, 16 insertions(+), 26 deletions(-) > >diff --git a/drivers/scsi/megaraid.c b/drivers/scsi/megaraid.c index >3c63c29..7e504d3 100644 >--- a/drivers/scsi/megaraid.c >+++ b/drivers/scsi/megaraid.c >@@ -1909,7 +1909,7 @@ static DEF_SCSI_QCMD(megaraid_queue) > > spin_lock_irq(>lock); > >- rval = megaraid_abort_and_reset(adapter, cmd, SCB_RESET); >+ rval = megaraid_abort_and_reset(adapter, NULL, SCB_RESET); If cmd=NULL is passed, it will crash inside function megaraid_abort_and_reset() while dereferencing "cmd" pointer. Below is the code of function megaraid_abort_and_reset() where it will crash- static int megaraid_abort_and_reset(adapter_t *adapter, Scsi_Cmnd *cmd, int aor) { struct list_head*pos, *next; scb_t *scb; dev_warn(>dev->dev, "%s cmd=%x
RE: Application stops due to ext4 filesytsem IO error
Gentle ping. I have opened kernel BZ for this. Here is the BZ link- https://bugzilla.kernel.org/show_bug.cgi?id=196057 Thanks, Sumit >-Original Message- >From: Sumit Saxena [mailto:sumit.sax...@broadcom.com] >Sent: Tuesday, June 06, 2017 9:05 PM >To: 'Jens Axboe' >Cc: 'linux-bl...@vger.kernel.org'; 'linux-scsi@vger.kernel.org' >Subject: RE: Application stops due to ext4 filesytsem IO error > >Gentle ping.. > >>-----Original Message- >>From: Sumit Saxena [mailto:sumit.sax...@broadcom.com] >>Sent: Monday, June 05, 2017 12:59 PM >>To: 'Jens Axboe' >>Cc: 'linux-bl...@vger.kernel.org'; 'linux-scsi@vger.kernel.org' >>Subject: Application stops due to ext4 filesytsem IO error >> >>Jens, >> >>We am observing application stops while running ext4 filesystem IOs >>along with target reset in parallel. >>Our suspect is this behavior can be attributed to linux block layer. >>See below for details- >> >>Problem statement - " Application stops due to IO error from file >>system buffered IO. (Note - It is always a FS meta data read failure)" >>Issue is reproducible - "Yes. It is consistently reproducible." >>Brief about setup - >>Latest 4.11 kernel. Issue hits irrespective of whether SCSI MQ is >>enabled or disabled. use_blk_mq=Y and use_blk_mq=N has similar issue. >>Direct attached 4 SAS/SATA drives connected to MegaRAID Invader >>controller. >> >>Reproduction steps - >>-Create ext4 FS on 4 JBODs(non RAID volumes) behind MegaRAID SAS >>controller. >>-Start Data integrity test on all four ext4 mounted partition. (Tool >>should be configured to send Buffered FS IO). >>-Send Target Reset (have some delay between next reset to allow some >>IO on device) on each JBOD to simulate error condition. (sg_reset -d >/dev/sdX). >> >>End result - >>Combination of target resets and FS IOs in parallel causes application >>halt with ext4 Filesystem IO error. >>We are able to restart application without cleaning and unmounting >>filesystem. >>Below are the error logs at the time of application stop- >> >>-- >>sd 0:0:53:0: target reset called for >>scmd(88003cf25148) >>sd 0:0:53:0: attempting target reset! >>scmd(88003cf25148) tm_dev_handle 0xb >>sd 0:0:53:0: [sde] tag#519 BRCM Debug: request->cmd_flags: 0x80700 >bio- >>>bi_flags: 0x2 bio->bi_opf: 0x3000 rq_flags 0x20e3 >>.. >>sd 0:0:53:0: [sde] tag#519 CDB: Read(10) 28 00 15 00 11 10 00 00 f8 00 >>EXT4-fs error (device sde): __ext4_get_inode_loc:4465: inode #11018287: >>block 44040738: comm chaos: unable to read itable block >>--- >> >>We debug further to understand what is happening above LLD. See below- >> >>During target reset, there may be IO coming from target with CHECK >>CONDITION with below sense information-. >>Sense Key : Aborted Command [current] >>Add. Sense: No additional sense information >> >>Such Aborted command should be retried by SML/Block layer. This happens >>from SML expect for FS Meta data read. >>From driver level debug, we found IOs with REQ_FAILFAST_DEV bit set in >>scmd->request->cmd_flags are not retried by SML and that is also as >>expected. >> >>Below is the code in scsi_error.c(function- scsi_noretry_cmd) which >>causes IOs with REQ_FAILFAST_DEV enabled not getting retried bit >>completed back to upper layer- >> >>/* >> * assume caller has checked sense and determined >> * the check condition was retryable. >> */ >>if (scmd->request->cmd_flags & REQ_FAILFAST_DEV || >>scmd->request->cmd_type == REQ_TYPE_BLOCK_PC) >>return 1; >>else >>return 0; >> >> >>IO which causes application to stop has REQ_FAILFAST_DEV enabled inside >>"scmd->request->cmd_flags". We noticed that this bit will be set for >>filesystem Read ahead meta data IOs. In order to confirm the same, we >>mounted with option inode_readahead_blks=0 to disable ext4's inode >>table readahead algorithm and did not observe the issue. Issue does not >>hit with DIRECT IOs but only with cached/buffered IOs. >> >>2. From driver level debug prints, we also noticed - There are many IO >>failures with REQ_FAILFAST_DEV handled gracefully by filesystem. >>Application level failure happens only If IO has RQF_MIXED_MERGE set. >>If IO merging is disabled through sysfs parameter for SCSI device in >>question- nomerges set to 2, we are not seein
RE: Application stops due to ext4 filesytsem IO error
Gentle ping.. >-Original Message- >From: Sumit Saxena [mailto:sumit.sax...@broadcom.com] >Sent: Monday, June 05, 2017 12:59 PM >To: 'Jens Axboe' >Cc: 'linux-bl...@vger.kernel.org'; 'linux-scsi@vger.kernel.org' >Subject: Application stops due to ext4 filesytsem IO error > >Jens, > >We am observing application stops while running ext4 filesystem IOs along >with target reset in parallel. >Our suspect is this behavior can be attributed to linux block layer. See below >for details- > >Problem statement - " Application stops due to IO error from file system >buffered IO. (Note - It is always a FS meta data read failure)" >Issue is reproducible - "Yes. It is consistently reproducible." >Brief about setup - >Latest 4.11 kernel. Issue hits irrespective of whether SCSI MQ is enabled or >disabled. use_blk_mq=Y and use_blk_mq=N has similar issue. >Direct attached 4 SAS/SATA drives connected to MegaRAID Invader >controller. > >Reproduction steps - >-Create ext4 FS on 4 JBODs(non RAID volumes) behind MegaRAID SAS >controller. >-Start Data integrity test on all four ext4 mounted partition. (Tool should be >configured to send Buffered FS IO). >-Send Target Reset (have some delay between next reset to allow some IO >on device) on each JBOD to simulate error condition. (sg_reset -d /dev/sdX). > >End result - >Combination of target resets and FS IOs in parallel causes application halt >with ext4 Filesystem IO error. >We are able to restart application without cleaning and unmounting >filesystem. >Below are the error logs at the time of application stop- > >-- >sd 0:0:53:0: target reset called for >scmd(88003cf25148) >sd 0:0:53:0: attempting target reset! >scmd(88003cf25148) tm_dev_handle 0xb >sd 0:0:53:0: [sde] tag#519 BRCM Debug: request->cmd_flags: 0x80700 bio- >>bi_flags: 0x2 bio->bi_opf: 0x3000 rq_flags 0x20e3 >.. >sd 0:0:53:0: [sde] tag#519 CDB: Read(10) 28 00 15 00 11 10 00 00 f8 00 >EXT4-fs error (device sde): __ext4_get_inode_loc:4465: inode #11018287: >block 44040738: comm chaos: unable to read itable block >--- > >We debug further to understand what is happening above LLD. See below- > >During target reset, there may be IO coming from target with CHECK >CONDITION with below sense information-. >Sense Key : Aborted Command [current] >Add. Sense: No additional sense information > >Such Aborted command should be retried by SML/Block layer. This happens >from SML expect for FS Meta data read. >From driver level debug, we found IOs with REQ_FAILFAST_DEV bit set in >scmd->request->cmd_flags are not retried by SML and that is also as >expected. > >Below is the code in scsi_error.c(function- scsi_noretry_cmd) which causes >IOs with REQ_FAILFAST_DEV enabled not getting retried bit completed back >to upper layer- > >/* > * assume caller has checked sense and determined > * the check condition was retryable. > */ >if (scmd->request->cmd_flags & REQ_FAILFAST_DEV || >scmd->request->cmd_type == REQ_TYPE_BLOCK_PC) >return 1; >else >return 0; > > >IO which causes application to stop has REQ_FAILFAST_DEV enabled inside >"scmd->request->cmd_flags". We noticed that this bit will be set for >filesystem Read ahead meta data IOs. In order to confirm the same, we >mounted with option inode_readahead_blks=0 to disable ext4's inode table >readahead algorithm and did not observe the issue. Issue does not hit with >DIRECT IOs but only with cached/buffered IOs. > >2. From driver level debug prints, we also noticed - There are many IO >failures with REQ_FAILFAST_DEV handled gracefully by filesystem. >Application level failure happens only If IO has RQF_MIXED_MERGE set. >If IO merging is disabled through sysfs parameter for SCSI device in question- >nomerges set to 2, we are not seeing the issue. > >3. We added few prints in driver to dump "scmd->request->cmd_flags" and >"scmd->request->rq_flags" for IOs completed with CHECK CONDITION and >culprit IOs has all these bits- REQ_FAILFAST_DEV and REQ_RAHEAD bit set in >"scmd->request->cmd_flags" and RQF_MIXED_MERGE bit set in "scmd- >>request->rq_flags". Also it's not necessarily true that all IOs with these >three bits set will cause issue but whenever issue hits, these three bits are >set for IO causing failure. > > >In summary, >FS mechanism of using READ AHEAD for meta data works fine (in case of IO >failure) if there is no mix/merge at block layer. >FS mechanism of using READ AHEAD for meta data has some corner case >which is not handled properly (in case of IO failure) if there was mix/merge >at block layer. >megaraid_sas driver's behavior seems correct here. Aborted IO goes to SML >with CHECK CONDITION settings and SML decided to fail fast IO as it was >requested. > >Query - Is this block layer (page cache) issue? What should be the ideal fix ? > >Thanks, >Sumit
Application stops due to ext4 filesytsem IO error
Jens, We am observing application stops while running ext4 filesystem IOs along with target reset in parallel. Our suspect is this behavior can be attributed to linux block layer. See below for details- Problem statement - " Application stops due to IO error from file system buffered IO. (Note - It is always a FS meta data read failure)" Issue is reproducible - "Yes. It is consistently reproducible." Brief about setup - Latest 4.11 kernel. Issue hits irrespective of whether SCSI MQ is enabled or disabled. use_blk_mq=Y and use_blk_mq=N has similar issue. Direct attached 4 SAS/SATA drives connected to MegaRAID Invader controller. Reproduction steps - -Create ext4 FS on 4 JBODs(non RAID volumes) behind MegaRAID SAS controller. -Start Data integrity test on all four ext4 mounted partition. (Tool should be configured to send Buffered FS IO). -Send Target Reset (have some delay between next reset to allow some IO on device) on each JBOD to simulate error condition. (sg_reset -d /dev/sdX). End result - Combination of target resets and FS IOs in parallel causes application halt with ext4 Filesystem IO error. We are able to restart application without cleaning and unmounting filesystem. Below are the error logs at the time of application stop- -- sd 0:0:53:0: target reset called for scmd(88003cf25148) sd 0:0:53:0: attempting target reset! scmd(88003cf25148) tm_dev_handle 0xb sd 0:0:53:0: [sde] tag#519 BRCM Debug: request->cmd_flags: 0x80700 bio->bi_flags: 0x2 bio->bi_opf: 0x3000 rq_flags 0x20e3 .. sd 0:0:53:0: [sde] tag#519 CDB: Read(10) 28 00 15 00 11 10 00 00 f8 00 EXT4-fs error (device sde): __ext4_get_inode_loc:4465: inode #11018287: block 44040738: comm chaos: unable to read itable block --- We debug further to understand what is happening above LLD. See below- During target reset, there may be IO coming from target with CHECK CONDITION with below sense information-. Sense Key : Aborted Command [current] Add. Sense: No additional sense information Such Aborted command should be retried by SML/Block layer. This happens from SML expect for FS Meta data read. >From driver level debug, we found IOs with REQ_FAILFAST_DEV bit set in scmd->request->cmd_flags are not retried by SML and that is also as expected. Below is the code in scsi_error.c(function- scsi_noretry_cmd) which causes IOs with REQ_FAILFAST_DEV enabled not getting retried bit completed back to upper layer- /* * assume caller has checked sense and determined * the check condition was retryable. */ if (scmd->request->cmd_flags & REQ_FAILFAST_DEV || scmd->request->cmd_type == REQ_TYPE_BLOCK_PC) return 1; else return 0; IO which causes application to stop has REQ_FAILFAST_DEV enabled inside "scmd->request->cmd_flags". We noticed that this bit will be set for filesystem Read ahead meta data IOs. In order to confirm the same, we mounted with option inode_readahead_blks=0 to disable ext4's inode table readahead algorithm and did not observe the issue. Issue does not hit with DIRECT IOs but only with cached/buffered IOs. 2. From driver level debug prints, we also noticed - There are many IO failures with REQ_FAILFAST_DEV handled gracefully by filesystem. Application level failure happens only If IO has RQF_MIXED_MERGE set. If IO merging is disabled through sysfs parameter for SCSI device in question- nomerges set to 2, we are not seeing the issue. 3. We added few prints in driver to dump "scmd->request->cmd_flags" and "scmd->request->rq_flags" for IOs completed with CHECK CONDITION and culprit IOs has all these bits- REQ_FAILFAST_DEV and REQ_RAHEAD bit set in "scmd->request->cmd_flags" and RQF_MIXED_MERGE bit set in "scmd->request->rq_flags". Also it's not necessarily true that all IOs with these three bits set will cause issue but whenever issue hits, these three bits are set for IO causing failure. In summary, FS mechanism of using READ AHEAD for meta data works fine (in case of IO failure) if there is no mix/merge at block layer. FS mechanism of using READ AHEAD for meta data has some corner case which is not handled properly (in case of IO failure) if there was mix/merge at block layer. megaraid_sas driver's behavior seems correct here. Aborted IO goes to SML with CHECK CONDITION settings and SML decided to fail fast IO as it was requested. Query - Is this block layer (page cache) issue? What should be the ideal fix ? Thanks, Sumit
RE: [PATCH] megaraid: Fix a sleep-in-atomic bug
>-Original Message- >From: Jia-Ju Bai [mailto:baijiaju1...@163.com] >Sent: Wednesday, May 31, 2017 8:27 AM >To: kashyap.de...@broadcom.com; sumit.sax...@broadcom.com; >shivasharan.srikanteshw...@broadcom.com; j...@linux.vnet.ibm.com; >martin.peter...@oracle.com >Cc: megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org; linux- >ker...@vger.kernel.org; Jia-Ju Bai >Subject: [PATCH] megaraid: Fix a sleep-in-atomic bug > >The driver may sleep under a spin lock, and the function call path is: >mraid_mm_attach_buf (acquire the lock by spin_lock_irqsave) > pci_pool_alloc(GFP_KERNEL) --> may sleep > >To fix it, the "GFP_KERNEL" is replaced with "GFP_ATOMIC". > >Signed-off-by: Jia-Ju Bai <baijiaju1...@163.com> >--- > drivers/scsi/megaraid/megaraid_mm.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/drivers/scsi/megaraid/megaraid_mm.c >b/drivers/scsi/megaraid/megaraid_mm.c >index 4cf9ed9..c43afb8 100644 >--- a/drivers/scsi/megaraid/megaraid_mm.c >+++ b/drivers/scsi/megaraid/megaraid_mm.c >@@ -574,7 +574,7 @@ > > kioc->pool_index= right_pool; > kioc->free_buf = 1; >- kioc->buf_vaddr = pci_pool_alloc(pool->handle, GFP_KERNEL, >+ kioc->buf_vaddr = pci_pool_alloc(pool->handle, GFP_ATOMIC, > >buf_paddr); > spin_unlock_irqrestore(>lock, flags); This is very old driver and reached EOL. Did you face any issue because of this bug or discover this through code review? Anyways patch looks good to me. Acked-by: Sumit Saxena <sumit.sax...@broadcom.com> > >-- >1.7.9.5 >
RE: [PATCH v4 11/19] scsi: megaraid: Replace PCI pool old API
VME_PAGE_SIZE, 0); > /* SCSI_SENSE_BUFFERSIZE = 96 bytes */ > fusion->sense_dma_pool = >- pci_pool_create("mr_sense", instance->pdev, >+ dma_pool_create("mr_sense", >pdev->dev, > SCSI_SENSE_BUFFERSIZE, 64, 0); > > if (!fusion->sense_dma_pool || !fusion->sg_dma_pool) { @@ -395,10 >+389,10 @@ static int megasas_create_sg_sense_fusion(struct >megasas_instance *instance) >*/ > for (i = 0; i < max_cmd; i++) { > cmd = fusion->cmd_list[i]; >- cmd->sg_frame = pci_pool_alloc(fusion->sg_dma_pool, >+ cmd->sg_frame = dma_pool_alloc(fusion->sg_dma_pool, > GFP_KERNEL, >>sg_frame_phys_addr); > >- cmd->sense = pci_pool_alloc(fusion->sense_dma_pool, >+ cmd->sense = dma_pool_alloc(fusion->sense_dma_pool, > GFP_KERNEL, >sense_phys_addr); > if (!cmd->sg_frame || !cmd->sense) { > dev_err(>pdev->dev, >@@ -410,7 +404,7 @@ static int megasas_create_sg_sense_fusion(struct >megasas_instance *instance) > /* create sense buffer for the raid 1/10 fp */ > for (i = max_cmd; i < instance->max_mpt_cmds; i++) { > cmd = fusion->cmd_list[i]; >- cmd->sense = pci_pool_alloc(fusion->sense_dma_pool, >+ cmd->sense = dma_pool_alloc(fusion->sense_dma_pool, > GFP_KERNEL, >sense_phys_addr); > if (!cmd->sense) { > dev_err(>pdev->dev, >@@ -475,7 +469,7 @@ megasas_alloc_request_fusion(struct megasas_instance >*instance) > } > > fusion->io_request_frames_pool = >- pci_pool_create("mr_ioreq", instance->pdev, >+ dma_pool_create("mr_ioreq", >pdev->dev, > fusion->io_frames_alloc_sz, 16, 0); > > if (!fusion->io_request_frames_pool) { @@ -485,7 +479,7 @@ >megasas_alloc_request_fusion(struct megasas_instance *instance) > } > > fusion->io_request_frames = >- pci_pool_alloc(fusion->io_request_frames_pool, >+ dma_pool_alloc(fusion->io_request_frames_pool, > GFP_KERNEL, >>io_request_frames_phys); > if (!fusion->io_request_frames) { > dev_err(>pdev->dev, >@@ -505,7 +499,7 @@ megasas_alloc_reply_fusion(struct megasas_instance >*instance) > > count = instance->msix_vectors > 0 ? instance->msix_vectors : 1; > fusion->reply_frames_desc_pool = >- pci_pool_create("mr_reply", instance->pdev, >+ dma_pool_create("mr_reply", >pdev->dev, > fusion->reply_alloc_sz * count, 16, 0); > > if (!fusion->reply_frames_desc_pool) { @@ -515,7 +509,7 @@ >megasas_alloc_reply_fusion(struct megasas_instance *instance) > } > > fusion->reply_frames_desc[0] = >- pci_pool_alloc(fusion->reply_frames_desc_pool, >+ dma_pool_alloc(fusion->reply_frames_desc_pool, > GFP_KERNEL, >reply_frames_desc_phys[0]); > if (!fusion->reply_frames_desc[0]) { > dev_err(>pdev->dev, >@@ -558,8 +552,10 @@ megasas_alloc_rdpq_fusion(struct megasas_instance >*instance) > memset(fusion->rdpq_virt, 0, > sizeof(struct MPI2_IOC_INIT_RDPQ_ARRAY_ENTRY) * >MAX_MSIX_QUEUES_FUSION); > count = instance->msix_vectors > 0 ? instance->msix_vectors : 1; >- fusion->reply_frames_desc_pool = pci_pool_create("mr_rdpq", >- instance->pdev, fusion- >>reply_alloc_sz, 16, 0); >+ fusion->reply_frames_desc_pool = dma_pool_create("mr_rdpq", >+ >pdev->dev, >+ fusion->reply_alloc_sz, >+ 16, 0); > > if (!fusion->reply_frames_desc_pool) { > dev_err(>pdev->dev, >@@ -569,7 +565,7 @@ megasas_alloc_rdpq_fusion(struct megasas_instance >*instance) > > for (i = 0; i < count; i++) { > fusion->reply_frames_desc[i] = >- pci_pool_alloc(fusion- >>reply_frames_desc_pool, >+ dma_pool_alloc(fusion- >>reply_frames_desc_pool, > GFP_KERNEL, >>reply_frames_desc_phys[i]); > if (!fusion->reply_frames_desc[i]) { > dev_err(>pdev->dev, >@@ -597,13 +593,12 @@ megasas_free_rdpq_fusion(struct megasas_instance >*instance) { > > for (i = 0; i < MAX_MSIX_QUEUES_FUSION; i++) { > if (fusion->reply_frames_desc[i]) >- pci_pool_free(fusion->reply_frames_desc_pool, >+ dma_pool_free(fusion->reply_frames_desc_pool, > fusion->reply_frames_desc[i], > fusion->reply_frames_desc_phys[i]); > } > >- if (fusion->reply_frames_desc_pool) >- pci_pool_destroy(fusion->reply_frames_desc_pool); >+ dma_pool_destroy(fusion->reply_frames_desc_pool); > > if (fusion->rdpq_virt) > pci_free_consistent(instance->pdev, >@@ -619,12 +614,11 @@ megasas_free_reply_fusion(struct megasas_instance >*instance) { > fusion = instance->ctrl_context; > > if (fusion->reply_frames_desc[0]) >- pci_pool_free(fusion->reply_frames_desc_pool, >+ dma_pool_free(fusion->reply_frames_desc_pool, > fusion->reply_frames_desc[0], > fusion->reply_frames_desc_phys[0]); > >- if (fusion->reply_frames_desc_pool) >- pci_pool_destroy(fusion->reply_frames_desc_pool); >+ dma_pool_destroy(fusion->reply_frames_desc_pool); > > } Acked-by: Sumit Saxena <sumit.sax...@broadcom.com> > >-- >2.9.3
RE: [patch] scsi: megaraid_sas: array overflow in megasas_dump_frame()
>-Original Message- >From: Dan Carpenter [mailto:dan.carpen...@oracle.com] >Sent: Tuesday, February 14, 2017 10:09 PM >To: Kashyap Desai; Shivasharan S >Cc: Sumit Saxena; James E.J. Bottomley; Martin K. Petersen; >megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org; kernel- >janit...@vger.kernel.org >Subject: [patch] scsi: megaraid_sas: array overflow in megasas_dump_frame() > >The "sz" variable is in terms of bytes, but we're treating the buffer as an array of >__le32 so we have to divide by 4. > >Fixes: def0eab3af86 ("scsi: megaraid_sas: enhance debug logs in OCR context") >Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com> > >diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c >b/drivers/scsi/megaraid/megaraid_sas_base.c >index dc9f42e135bb..7ac9a9ee9bd4 100644 >--- a/drivers/scsi/megaraid/megaraid_sas_base.c >+++ b/drivers/scsi/megaraid/megaraid_sas_base.c >@@ -2754,7 +2754,7 @@ megasas_dump_frame(void *mpi_request, int sz) > __le32 *mfp = (__le32 *)mpi_request; > > printk(KERN_INFO "IO request frame:\n\t"); >- for (i = 0; i < sz; i++) { >+ for (i = 0; i < sz / sizeof(__le32); i++) { > if (i && ((i % 8) == 0)) > printk("\n\t"); > printk("%08x ", le32_to_cpu(mfp[i])); Patch looks good. In last reply, Acked-by tag was not in proper format. Fixing it now. Sorry for inconvenience. Acked-by: Sumit Saxena <sumit.sax...@broadcom.com>
RE: [PATCH] scsi: megaraid_sas: handle dma_addr_t right on 32-bit
>-Original Message- >From: Arnd Bergmann [mailto:a...@arndb.de] >Sent: Wednesday, February 15, 2017 2:52 AM >To: James E.J. Bottomley; Martin K. Petersen >Cc: Arnd Bergmann; Kashyap Desai; Sumit Saxena; Shivasharan S; Tomas Henzl; >Hannes Reinecke; Sasikumar Chandrasekaran; >megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org; linux- >ker...@vger.kernel.org >Subject: [PATCH] scsi: megaraid_sas: handle dma_addr_t right on 32-bit > >When building with a dma_addr_t that is different from pointer size, we get this >warning: > >drivers/scsi/megaraid/megaraid_sas_fusion.c: In function >'megasas_make_prp_nvme': >drivers/scsi/megaraid/megaraid_sas_fusion.c:1654:17: error: cast to pointer >from integer of different size [-Werror=int-to-pointer-cast] > >It's better to not pretend that the dma address is a pointer and instead use a >dma_addr_t consistently. > >Fixes: 33203bc4d61b ("scsi: megaraid_sas: NVME fast path io support") >Signed-off-by: Arnd Bergmann <a...@arndb.de> >--- > drivers/scsi/megaraid/megaraid_sas_fusion.c | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) > >diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c >b/drivers/scsi/megaraid/megaraid_sas_fusion.c >index 750090119f81..29650ba669da 100644 >--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c >+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c >@@ -1619,7 +1619,8 @@ megasas_make_prp_nvme(struct megasas_instance >*instance, struct scsi_cmnd *scmd, { > int sge_len, offset, num_prp_in_chain = 0; > struct MPI25_IEEE_SGE_CHAIN64 *main_chain_element, *ptr_first_sgl; >- u64 *ptr_sgl, *ptr_sgl_phys; >+ u64 *ptr_sgl; >+ dma_addr_t ptr_sgl_phys; > u64 sge_addr; > u32 page_mask, page_mask_result; > struct scatterlist *sg_scmd; >@@ -1651,14 +1652,14 @@ megasas_make_prp_nvme(struct megasas_instance >*instance, struct scsi_cmnd *scmd, >*/ > page_mask = mr_nvme_pg_size - 1; > ptr_sgl = (u64 *)cmd->sg_frame; >- ptr_sgl_phys = (u64 *)cmd->sg_frame_phys_addr; >+ ptr_sgl_phys = cmd->sg_frame_phys_addr; > memset(ptr_sgl, 0, instance->max_chain_frame_sz); > > /* Build chain frame element which holds all prps except first*/ > main_chain_element = (struct MPI25_IEEE_SGE_CHAIN64 *) > ((u8 *)sgl_ptr + sizeof(struct MPI25_IEEE_SGE_CHAIN64)); > >- main_chain_element->Address = cpu_to_le64((uintptr_t)ptr_sgl_phys); >+ main_chain_element->Address = cpu_to_le64(ptr_sgl_phys); > main_chain_element->NextChainOffset = 0; > main_chain_element->Flags = IEEE_SGE_FLAGS_CHAIN_ELEMENT | > IEEE_SGE_FLAGS_SYSTEM_ADDR | >@@ -1696,16 +1697,15 @@ megasas_make_prp_nvme(struct megasas_instance >*instance, struct scsi_cmnd *scmd, > scmd_printk(KERN_NOTICE, > scmd, "page boundary ptr_sgl: 0x%p\n", > ptr_sgl); >- ptr_sgl_phys++; >- *ptr_sgl = >- cpu_to_le64((uintptr_t)ptr_sgl_phys); >+ ptr_sgl_phys += 8; >+ *ptr_sgl = cpu_to_le64(ptr_sgl_phys); > ptr_sgl++; > num_prp_in_chain++; > } > > *ptr_sgl = cpu_to_le64(sge_addr); > ptr_sgl++; >- ptr_sgl_phys++; >+ ptr_sgl_phys += 8; > num_prp_in_chain++; > > sge_addr += mr_nvme_pg_size; Patch looks good. In last reply, Acked-by tag was not in proper format. Fixing it now. Sorry for inconvenience. Acked-by: Sumit Saxena <sumit.sax...@broadcom.com> >-- >2.9.0
RE: [PATCH] scsi: megaraid_sas: handle dma_addr_t right on 32-bit
>-Original Message- >From: Arnd Bergmann [mailto:a...@arndb.de] >Sent: Wednesday, February 15, 2017 2:52 AM >To: James E.J. Bottomley; Martin K. Petersen >Cc: Arnd Bergmann; Kashyap Desai; Sumit Saxena; Shivasharan S; Tomas Henzl; >Hannes Reinecke; Sasikumar Chandrasekaran; >megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org; linux- >ker...@vger.kernel.org >Subject: [PATCH] scsi: megaraid_sas: handle dma_addr_t right on 32-bit > >When building with a dma_addr_t that is different from pointer size, we get this >warning: > >drivers/scsi/megaraid/megaraid_sas_fusion.c: In function >'megasas_make_prp_nvme': >drivers/scsi/megaraid/megaraid_sas_fusion.c:1654:17: error: cast to pointer >from integer of different size [-Werror=int-to-pointer-cast] > >It's better to not pretend that the dma address is a pointer and instead use a >dma_addr_t consistently. Patch looks good from review but we need to have some test runs before acking this. I will get back after some test runs. Thanks, Sumit > >Fixes: 33203bc4d61b ("scsi: megaraid_sas: NVME fast path io support") >Signed-off-by: Arnd Bergmann <a...@arndb.de> >--- > drivers/scsi/megaraid/megaraid_sas_fusion.c | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) > >diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c >b/drivers/scsi/megaraid/megaraid_sas_fusion.c >index 750090119f81..29650ba669da 100644 >--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c >+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c >@@ -1619,7 +1619,8 @@ megasas_make_prp_nvme(struct megasas_instance >*instance, struct scsi_cmnd *scmd, { > int sge_len, offset, num_prp_in_chain = 0; > struct MPI25_IEEE_SGE_CHAIN64 *main_chain_element, *ptr_first_sgl; >- u64 *ptr_sgl, *ptr_sgl_phys; >+ u64 *ptr_sgl; >+ dma_addr_t ptr_sgl_phys; > u64 sge_addr; > u32 page_mask, page_mask_result; > struct scatterlist *sg_scmd; >@@ -1651,14 +1652,14 @@ megasas_make_prp_nvme(struct megasas_instance >*instance, struct scsi_cmnd *scmd, >*/ > page_mask = mr_nvme_pg_size - 1; > ptr_sgl = (u64 *)cmd->sg_frame; >- ptr_sgl_phys = (u64 *)cmd->sg_frame_phys_addr; >+ ptr_sgl_phys = cmd->sg_frame_phys_addr; > memset(ptr_sgl, 0, instance->max_chain_frame_sz); > > /* Build chain frame element which holds all prps except first*/ > main_chain_element = (struct MPI25_IEEE_SGE_CHAIN64 *) > ((u8 *)sgl_ptr + sizeof(struct MPI25_IEEE_SGE_CHAIN64)); > >- main_chain_element->Address = cpu_to_le64((uintptr_t)ptr_sgl_phys); >+ main_chain_element->Address = cpu_to_le64(ptr_sgl_phys); > main_chain_element->NextChainOffset = 0; > main_chain_element->Flags = IEEE_SGE_FLAGS_CHAIN_ELEMENT | > IEEE_SGE_FLAGS_SYSTEM_ADDR | >@@ -1696,16 +1697,15 @@ megasas_make_prp_nvme(struct megasas_instance >*instance, struct scsi_cmnd *scmd, > scmd_printk(KERN_NOTICE, > scmd, "page boundary ptr_sgl: 0x%p\n", > ptr_sgl); >- ptr_sgl_phys++; >- *ptr_sgl = >- cpu_to_le64((uintptr_t)ptr_sgl_phys); >+ ptr_sgl_phys += 8; >+ *ptr_sgl = cpu_to_le64(ptr_sgl_phys); > ptr_sgl++; > num_prp_in_chain++; > } > > *ptr_sgl = cpu_to_le64(sge_addr); > ptr_sgl++; >- ptr_sgl_phys++; >+ ptr_sgl_phys += 8; > num_prp_in_chain++; > > sge_addr += mr_nvme_pg_size; >-- >2.9.0
RE: [patch] scsi: megaraid_sas: array overflow in megasas_dump_frame()
>-Original Message- >From: Dan Carpenter [mailto:dan.carpen...@oracle.com] >Sent: Tuesday, February 14, 2017 10:09 PM >To: Kashyap Desai; Shivasharan S >Cc: Sumit Saxena; James E.J. Bottomley; Martin K. Petersen; >megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org; kernel- >janit...@vger.kernel.org >Subject: [patch] scsi: megaraid_sas: array overflow in megasas_dump_frame() > >The "sz" variable is in terms of bytes, but we're treating the buffer as an array of >__le32 so we have to divide by 4. > >Fixes: def0eab3af86 ("scsi: megaraid_sas: enhance debug logs in OCR context") >Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com> > >diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c >b/drivers/scsi/megaraid/megaraid_sas_base.c >index dc9f42e135bb..7ac9a9ee9bd4 100644 >--- a/drivers/scsi/megaraid/megaraid_sas_base.c >+++ b/drivers/scsi/megaraid/megaraid_sas_base.c >@@ -2754,7 +2754,7 @@ megasas_dump_frame(void *mpi_request, int sz) > __le32 *mfp = (__le32 *)mpi_request; > > printk(KERN_INFO "IO request frame:\n\t"); >- for (i = 0; i < sz; i++) { >+ for (i = 0; i < sz / sizeof(__le32); i++) { > if (i && ((i % 8) == 0)) > printk("\n\t"); > printk("%08x ", le32_to_cpu(mfp[i])); Thanks for fixing this. Acked-by: Sumit Saxena<sumit.sax...@broadcom.com>
RE: [bug report] megaraid_sas: Make PI enabled VD 8 byte DMA aligned
>-Original Message- >From: Dan Carpenter [mailto:dan.carpen...@oracle.com] >Sent: Tuesday, February 14, 2017 9:54 PM >To: sumit.sax...@avagotech.com >Cc: megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org >Subject: [bug report] megaraid_sas: Make PI enabled VD 8 byte DMA aligned > >Hello sumit.sax...@avagotech.com, > >The patch 0b48d12d0365: "megaraid_sas: Make PI enabled VD 8 byte DMA >aligned" from Oct 15, 2015, leads to the following static checker >warning: > > drivers/scsi/megaraid/megaraid_sas_base.c:1784 >megasas_set_dynamic_target_properties() > warn: if statement not indented I will post patch to fix this indentation issue. > >drivers/scsi/megaraid/megaraid_sas_base.c > 1757 void megasas_set_dynamic_target_properties(struct scsi_device *sdev) > 1758 { > 1759 u16 pd_index = 0, ld; > 1760 u32 device_id; > 1761 struct megasas_instance *instance; > 1762 struct fusion_context *fusion; > 1763 struct MR_PRIV_DEVICE *mr_device_priv_data; > 1764 struct MR_PD_CFG_SEQ_NUM_SYNC *pd_sync; > 1765 struct MR_LD_RAID *raid; > 1766 struct MR_DRV_RAID_MAP_ALL *local_map_ptr; > 1767 > 1768 instance = megasas_lookup_instance(sdev->host->host_no); > 1769 fusion = instance->ctrl_context; > 1770 mr_device_priv_data = sdev->hostdata; > 1771 > 1772 if (!fusion || !mr_device_priv_data) > 1773 return; > 1774 > 1775 if (MEGASAS_IS_LOGICAL(sdev)) { > 1776 device_id = ((sdev->channel % 2) * >MEGASAS_MAX_DEV_PER_CHANNEL) > 1777 + sdev->id; > 1778 local_map_ptr = fusion->ld_drv_map[(instance->map_id & 1)]; > 1779 ld = MR_TargetIdToLdGet(device_id, local_map_ptr); > 1780 if (ld >= instance->fw_supported_vd_count) > 1781 return; > 1782 raid = MR_LdRaidGet(ld, local_map_ptr); > 1783 > 1784 if (raid->capability.ldPiMode == >MR_PROT_INFO_TYPE_CONTROLLER) > 1785 blk_queue_update_dma_alignment(sdev->request_queue, 0x7); > > > > 1786 > 1787 mr_device_priv_data->is_tm_capable = > 1788 raid->capability.tmCapable; > 1789 } else if (instance->use_seqnum_jbod_fp) { > 1790 pd_index = (sdev->channel * >MEGASAS_MAX_DEV_PER_CHANNEL) + > 1791 sdev->id; > 1792 pd_sync = (void *)fusion->pd_seq_sync > 1793 [(instance->pd_seq_map_id - 1) & 1]; > 1794 mr_device_priv_data->is_tm_capable = > 1795 pd_sync->seq[pd_index].capability.tmCapable; > 1796 } > 1797 } > > >regards, >dan carpenter
RE: SCSI: usage of DID_REQUEUE vs DID_RESET for returning SCSI commands to be retried
Adding direct email addresses of few people to avoid any filters. Hannes/Martin/James/Tomas/Christoph, Can you please comment on this? Thanks, Sumit >-Original Message- >From: Sumit Saxena [mailto:sumit.sax...@broadcom.com] >Sent: Tuesday, December 13, 2016 6:50 PM >To: 'linux-scsi' >Subject: SCSI: usage of DID_REQUEUE vs DID_RESET for returning SCSI >commands to be retried > >Hi all, > >I have query regarding usage of host_byte DID_REQUEUE vs DID_RESET returned >by LLD to SCSI mid layer. > >Let me give some background here. >I am using megaraid_sas controller. megaraid_sas driver returns all outstanding >SCSI commands back to SCSI layer with DID_RESET host_byte before resetting >controller. >The intent is- all these commands returned with DID_RESET before controller >reset should be retried by SCSI. > >In few distros, I have observed that if SYNCHRONIZE_CACHE command(should be >applicable for all non Read write commands) is outstanding before resetting >controller and driver returns those commands back with DID_RESET then >SYNCHRONIZE_CACHE command not retried but failed to upper layer but other >READ/WRITE commands were not failed but retried. I was running filesystem IOs >and SYNHRONIZE_CACHE returned with error cause filesystem to go in READ only >mode. > >Later I checked and realized below commit was missing in that distro kernel and >seems to cause the problem- > >a621bac scsi_lib: correctly retry failed zero length REQ_TYPE_FS commands > >But distro kernel has below commit- > >89fb4cd scsi: handle flush errors properly > >Issue does not hit on the kernels which don't have both commits but hits when >commit- "89fb4cd scsi: handle flush errors properly " is there but commit- >"a621bac scsi_lib: correctly retry failed zero length REQ_TYPE_FS commands" is >missing. > >This issue is observed with mpt3sas driver as well and should be applicable to all >LLDs returning non read write commands with DID_RESET. > >Returning DID_REQUEUE instead of DID_RESET from driver solves the problem >irrespective of whether these above mentioned commits are there or not in >kernel. >So I am thinking to use DID_REQUEUE instead of DID_RESET in megaraid_sas >driver for all SCSI commands(not only limited to SYNCHRONIZE_CACHE or non >read write commands) before resetting controller. As I mentioned intent is those >outstanding commands returned by driver before doing controller reset should be >retried and as soon as reset is complete, driver will be processing those >commands. There is no sense key associated with SCSI commands returned. > >I browsed SCSI code and get to know DID_REQUEUE causes command to be >retried by calling- scsi_queue_insert(cmd, SCSI_MLQUEUE_DEVICE_BUSY). >This seems to be good enough for our requirement of commands to be re-tried >by SCSI layer. > >Please provide feedback if anyone forsee any issue with using DID_REQUEUE for >this use case. >I will be doing some testing with DID_REQUEUE in place of DID_RESET in >megaraid_sas driver. > >I have attached here a proposed patch for megaraid_sas driver. >If there are no concerns, I will send this patch to SCSI mailing list. > >Thanks, >Sumit --- Begin Message --- Driver returns outstanding SCSI commands to SCSI layer with host_byte set to DID_RESET before resetting controller so that SCSI layer should retry those commands. Sending DID_RESET for non RW commands(e.g SYNCHRONIZE_CACHE) may cause those commands getting failed and returning I/O erros on few distros which has included commit- 89fb4cd scsi: handle flush errors properly but missed commit- a621bac scsi_lib: correctly retry failed zero length REQ_TYPE_FS commands. However Read write commands returned with DID_RESET are not failed but retried. DID_REQUEUE seems safer to use instead of DID_RESET for all outstanding commands before doing chip reset as it serves purpose of getting all commands to be retried by SCSI layer. Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com> --- drivers/scsi/megaraid/megaraid_sas_base.c | 4 ++-- drivers/scsi/megaraid/megaraid_sas_fusion.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index 6484c38..959ce3e 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -1662,7 +1662,7 @@ megasas_queue_command(struct Scsi_Host *shost, struct scsi_cmnd *scmd) /* Check for an mpio path and adjust behavior */ if (atomic_read(>adprecovery) == MEGASAS_ADPRESET_SM_INFAULT) { if (megasas_check_mpio_paths(instance, scmd) == - (DID_RESET << 16)) { +
SCSI: usage of DID_REQUEUE vs DID_RESET for returning SCSI commands to be retried
Hi all, I have query regarding usage of host_byte DID_REQUEUE vs DID_RESET returned by LLD to SCSI mid layer. Let me give some background here. I am using megaraid_sas controller. megaraid_sas driver returns all outstanding SCSI commands back to SCSI layer with DID_RESET host_byte before resetting controller. The intent is- all these commands returned with DID_RESET before controller reset should be retried by SCSI. In few distros, I have observed that if SYNCHRONIZE_CACHE command(should be applicable for all non Read write commands) is outstanding before resetting controller and driver returns those commands back with DID_RESET then SYNCHRONIZE_CACHE command not retried but failed to upper layer but other READ/WRITE commands were not failed but retried. I was running filesystem IOs and SYNHRONIZE_CACHE returned with error cause filesystem to go in READ only mode. Later I checked and realized below commit was missing in that distro kernel and seems to cause the problem- a621bac scsi_lib: correctly retry failed zero length REQ_TYPE_FS commands But distro kernel has below commit- 89fb4cd scsi: handle flush errors properly Issue does not hit on the kernels which don't have both commits but hits when commit- "89fb4cd scsi: handle flush errors properly " is there but commit- "a621bac scsi_lib: correctly retry failed zero length REQ_TYPE_FS commands" is missing. This issue is observed with mpt3sas driver as well and should be applicable to all LLDs returning non read write commands with DID_RESET. Returning DID_REQUEUE instead of DID_RESET from driver solves the problem irrespective of whether these above mentioned commits are there or not in kernel. So I am thinking to use DID_REQUEUE instead of DID_RESET in megaraid_sas driver for all SCSI commands(not only limited to SYNCHRONIZE_CACHE or non read write commands) before resetting controller. As I mentioned intent is those outstanding commands returned by driver before doing controller reset should be retried and as soon as reset is complete, driver will be processing those commands. There is no sense key associated with SCSI commands returned. I browsed SCSI code and get to know DID_REQUEUE causes command to be retried by calling- scsi_queue_insert(cmd, SCSI_MLQUEUE_DEVICE_BUSY). This seems to be good enough for our requirement of commands to be re-tried by SCSI layer. Please provide feedback if anyone forsee any issue with using DID_REQUEUE for this use case. I will be doing some testing with DID_REQUEUE in place of DID_RESET in megaraid_sas driver. I have attached here a proposed patch for megaraid_sas driver. If there are no concerns, I will send this patch to SCSI mailing list. Thanks, Sumit --- Begin Message --- Driver returns outstanding SCSI commands to SCSI layer with host_byte set to DID_RESET before resetting controller so that SCSI layer should retry those commands. Sending DID_RESET for non RW commands(e.g SYNCHRONIZE_CACHE) may cause those commands getting failed and returning I/O erros on few distros which has included commit- 89fb4cd scsi: handle flush errors properly but missed commit- a621bac scsi_lib: correctly retry failed zero length REQ_TYPE_FS commands. However Read write commands returned with DID_RESET are not failed but retried. DID_REQUEUE seems safer to use instead of DID_RESET for all outstanding commands before doing chip reset as it serves purpose of getting all commands to be retried by SCSI layer. Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com> --- drivers/scsi/megaraid/megaraid_sas_base.c | 4 ++-- drivers/scsi/megaraid/megaraid_sas_fusion.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index 6484c38..959ce3e 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -1662,7 +1662,7 @@ megasas_queue_command(struct Scsi_Host *shost, struct scsi_cmnd *scmd) /* Check for an mpio path and adjust behavior */ if (atomic_read(>adprecovery) == MEGASAS_ADPRESET_SM_INFAULT) { if (megasas_check_mpio_paths(instance, scmd) == - (DID_RESET << 16)) { + (DID_REQUEUE << 16)) { return SCSI_MLQUEUE_HOST_BUSY; } else { scmd->result = DID_NO_CONNECT << 16; @@ -2483,7 +2483,7 @@ static int megasas_wait_for_outstanding(struct megasas_instance *instance) struct megasas_cmd, list); list_del_init(_cmd->list); if (reset_cmd->scmd) { - reset_cmd->scmd->result = DID_RESET << 16; + reset_cmd->scmd->result = DID_REQUEUE <
RE: [PATCH RESEND] Update 3ware driver email addresses
>-Original Message- >From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- >ow...@vger.kernel.org] On Behalf Of adam radford >Sent: Saturday, December 10, 2016 12:38 AM >To: linux-scsi >Subject: [PATCH RESEND] Update 3ware driver email addresses > >This change updates the 3ware drivers (3w-, 3w-9xxx, 3w-sas) email >addresses from linuxr...@lsi.com to aradf...@gmail.com, since the old email >address doesn't exist. > >This patch was updated to remove www.lsi.com text. > >Signed-off-by: Adam Radford <aradf...@gmail.com> >--- > MAINTAINERS| 2 +- > drivers/scsi/3w-9xxx.c | 9 +++-- > drivers/scsi/3w-9xxx.h | 9 +++-- > drivers/scsi/3w-sas.c | 7 ++- > drivers/scsi/3w-sas.h | 7 ++- > drivers/scsi/3w-.c | 7 ++- > drivers/scsi/3w-.h | 7 ++- > 7 files changed, 15 insertions(+), 33 deletions(-) > >diff --git a/MAINTAINERS b/MAINTAINERS >index b3a7774..1b5ddd0 100644 >--- a/MAINTAINERS >+++ b/MAINTAINERS >@@ -138,7 +138,7 @@ S: Maintained > F: drivers/net/ethernet/3com/typhoon* > > 3WARE SAS/SATA-RAID SCSI DRIVERS (3W-, 3W-9XXX, 3W-SAS) >-M: Adam Radford <linuxr...@lsi.com> >+M: Adam Radford <aradf...@gmail.com> > L: linux-scsi@vger.kernel.org > W: http://www.lsi.com > S: Supported >diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c index >a56a7b2..316f87f 100644 >--- a/drivers/scsi/3w-9xxx.c >+++ b/drivers/scsi/3w-9xxx.c >@@ -1,8 +1,8 @@ > /* >3w-9xxx.c -- 3ware 9000 Storage Controller device driver for Linux. > >- Written By: Adam Radford <linuxr...@lsi.com> >- Modifications By: Tom Couch <linuxr...@lsi.com> >+ Written By: Adam Radford <aradf...@gmail.com> >+ Modifications By: Tom Couch > >Copyright (C) 2004-2009 Applied Micro Circuits Corporation. >Copyright (C) 2010 LSI Corporation. >@@ -41,10 +41,7 @@ >Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 > USA > >Bugs/Comments/Suggestions should be mailed to: >- linuxr...@lsi.com >- >- For more information, goto: >- http://www.lsi.com >+ aradf...@gmail.com > >Note: This version of the driver does not contain a bundled firmware > image. >diff --git a/drivers/scsi/3w-9xxx.h b/drivers/scsi/3w-9xxx.h index >0fdc83c..b6c208c 100644 >--- a/drivers/scsi/3w-9xxx.h >+++ b/drivers/scsi/3w-9xxx.h >@@ -1,8 +1,8 @@ > /* >3w-9xxx.h -- 3ware 9000 Storage Controller device driver for Linux. > >- Written By: Adam Radford <linuxr...@lsi.com> >- Modifications By: Tom Couch <linuxr...@lsi.com> >+ Written By: Adam Radford <aradf...@gmail.com> >+ Modifications By: Tom Couch > >Copyright (C) 2004-2009 Applied Micro Circuits Corporation. >Copyright (C) 2010 LSI Corporation. >@@ -41,10 +41,7 @@ >Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 > USA > >Bugs/Comments/Suggestions should be mailed to: >- linuxr...@lsi.com >- >- For more information, goto: >- http://www.lsi.com >+ aradf...@gmail.com > */ > > #ifndef _3W_9XXX_H >diff --git a/drivers/scsi/3w-sas.c b/drivers/scsi/3w-sas.c index >f837485..970d8fa >100644 >--- a/drivers/scsi/3w-sas.c >+++ b/drivers/scsi/3w-sas.c >@@ -1,7 +1,7 @@ > /* >3w-sas.c -- LSI 3ware SAS/SATA-RAID Controller device driver for Linux. > >- Written By: Adam Radford <linuxr...@lsi.com> >+ Written By: Adam Radford <aradf...@gmail.com> > >Copyright (C) 2009 LSI Corporation. > >@@ -43,10 +43,7 @@ >LSI 3ware 9750 6Gb/s SAS/SATA-RAID > >Bugs/Comments/Suggestions should be mailed to: >- linuxr...@lsi.com >- >- For more information, goto: >- http://www.lsi.com [] >+ aradf...@gmail.com > >History >--- >diff --git a/drivers/scsi/3w-sas.h b/drivers/scsi/3w-sas.h index >fec6449..05e77d8 >100644 >--- a/drivers/scsi/3w-sas.h >+++ b/drivers/scsi/3w-sas.h >@@ -1,7 +1,7 @@ > /* >3w-sas.h -- LSI 3ware SAS/SATA-RAID Controller device driver for Linux. > >- Written By: Adam Radford <linuxr...@lsi.com> >+ Written By: Adam Radford <aradf...@gmail.com> > Acked-by: Sumit Saxena <sumit.sax...@broadcom.com> >Copyright (C) 2009 LSI Corporation. > >@@ -39,10 +39,7 @@ >Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 > USA > >Bugs/Comments/Suggestions should be mailed to: >- linuxr...@lsi.com >- >- For more information, goto: >- http://www.lsi.com >+ aradf...@gmail.com > */ > > #ifndef _3W_SAS_H >diff --git a/drivers/scsi/3w-.c b/drivers/scsi/3w-.c index
RE: [PATCH] megaraid_sas: switch to pci_alloc_irq_vectors
@ -6155,9 +6147,15 @@ static void megasas_shutdown_controller(struct >megasas_instance *instance, > goto fail_ready_state; > > /* Now re-enable MSI-X */ >- if (instance->msix_vectors && >- pci_enable_msix_exact(instance->pdev, instance->msixentry, >-instance->msix_vectors)) >+ if (instance->msix_vectors) { >+ irq_flags = PCI_IRQ_MSIX; >+ if (smp_affinity_enable) >+ irq_flags |= PCI_IRQ_AFFINITY; >+ } >+ rval = pci_alloc_irq_vectors(instance->pdev, 1, >+ instance->msix_vectors ? >+ instance->msix_vectors : 1, irq_flags); >+ if (rval < 0) > goto fail_reenable_msix; > > if (instance->ctrl_context) { >@@ -6330,7 +6328,7 @@ static void megasas_detach_one(struct pci_dev *pdev) > megasas_destroy_irqs(instance); > > if (instance->msix_vectors) >- pci_disable_msix(instance->pdev); >+ pci_free_irq_vectors(instance->pdev); > > if (instance->ctrl_context) { > megasas_release_fusion(instance); >@@ -6425,7 +6423,7 @@ static void megasas_shutdown(struct pci_dev *pdev) > megasas_destroy_irqs(instance); > > if (instance->msix_vectors) >- pci_disable_msix(instance->pdev); >+ pci_free_irq_vectors(instance->pdev); > } > Looks good to me. There are few patches for megaraid_sas pending posted by Sasikumar so either you have to rebase this patch once Sasi's patches are committed Or Sasi has to rebase his patches once this patch are applied. If you are ok, then I can post this patch once Sasi's patches are committed. Acked by: Sumit Saxena<sumit.sax...@broadcom.com> > /** >-- >1.8.5.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 -- 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] megaraid-sas: request irqs later
>-Original Message- >From: Martin K. Petersen [mailto:martin.peter...@oracle.com] >Sent: Tuesday, November 15, 2016 5:18 AM >To: Tomas Henzl >Cc: linux-scsi@vger.kernel.org; sumit.sax...@broadcom.com; >kashyap.de...@broadcom.com >Subject: Re: [PATCH] megaraid-sas: request irqs later > >>>>>> "Tomas" == Tomas Henzl <the...@redhat.com> writes: > >Tomas> It is not good when an irq arrives before driver structures are >Tomas> allocated. > >Sumit, Kashyap: Please review! Looks good.. I think I have acked this patch earlier also. Acked-by: Sumit Saxena<sumit.sax...@broadcom.com> > >-- >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 4/5] megaraid_sas: scsi-mq support
>-Original Message- >From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- >ow...@vger.kernel.org] On Behalf Of Hannes Reinecke >Sent: Friday, November 11, 2016 3:15 PM >To: Martin K. Petersen >Cc: Christoph Hellwig; James Bottomley; Sumit Saxena; linux- >s...@vger.kernel.org; Hannes Reinecke; Hannes Reinecke >Subject: [PATCH 4/5] megaraid_sas: scsi-mq support > >This patch enables full scsi multiqueue support. But as I have been seeing >performance regressions I've also added a module parameter 'use_blk_mq', >allowing multiqueue to be switched off if required. I may need sometime to comment on this patch. I will have some performance runs with this patch. Can you share your test configuration details? Thanks, Sumit > >Signed-off-by: Hannes Reinecke <h...@suse.com> >--- > drivers/scsi/megaraid/megaraid_sas_base.c | 22 + > drivers/scsi/megaraid/megaraid_sas_fusion.c | 38 >+ > 2 files changed, 50 insertions(+), 10 deletions(-) > >diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c >b/drivers/scsi/megaraid/megaraid_sas_base.c >index d580406..1af47e6 100644 >--- a/drivers/scsi/megaraid/megaraid_sas_base.c >+++ b/drivers/scsi/megaraid/megaraid_sas_base.c >@@ -48,6 +48,7 @@ > #include > #include > #include >+#include > > #include > #include >@@ -104,6 +105,9 @@ > module_param(scmd_timeout, int, S_IRUGO); >MODULE_PARM_DESC(scmd_timeout, "scsi command timeout (10-90s), default >90s. See megasas_reset_timer."); > >+bool use_blk_mq = true; >+module_param_named(use_blk_mq, use_blk_mq, bool, 0); >+ > MODULE_LICENSE("GPL"); > MODULE_VERSION(MEGASAS_VERSION); > MODULE_AUTHOR("megaraidlinux@avagotech.com"); >@@ -1882,6 +1886,17 @@ static void megasas_slave_destroy(struct scsi_device >*sdev) > sdev->hostdata = NULL; > } > >+static int megasas_map_queues(struct Scsi_Host *shost) { >+ struct megasas_instance *instance = (struct megasas_instance *) >+ shost->hostdata; >+ >+ if (!instance->ctrl_context) >+ return 0; >+ >+ return blk_mq_pci_map_queues(>tag_set, instance->pdev, 0); } >+ > /* > * megasas_complete_outstanding_ioctls - Complete outstanding ioctls after a > * kill adapter >@@ -2986,6 +3001,7 @@ struct device_attribute *megaraid_host_attrs[] = { > .slave_configure = megasas_slave_configure, > .slave_alloc = megasas_slave_alloc, > .slave_destroy = megasas_slave_destroy, >+ .map_queues = megasas_map_queues, > .queuecommand = megasas_queue_command, > .eh_target_reset_handler = megasas_reset_target, > .eh_abort_handler = megasas_task_abort, @@ -5610,6 +5626,12 @@ >static int megasas_io_attach(struct megasas_instance *instance) > host->max_id = MEGASAS_MAX_DEV_PER_CHANNEL; > host->max_lun = MEGASAS_MAX_LUN; > host->max_cmd_len = 16; >+ host->nr_hw_queues = instance->msix_vectors ? >+ instance->msix_vectors : 1; >+ if (use_blk_mq) { >+ host->can_queue = instance->max_scsi_cmds / >host->nr_hw_queues; >+ host->use_blk_mq = 1; >+ } > > /* >* Notify the mid-layer about the new controller diff --git >a/drivers/scsi/megaraid/megaraid_sas_fusion.c >b/drivers/scsi/megaraid/megaraid_sas_fusion.c >index eb3cb0f..aba53c0 100644 >--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c >+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c >@@ -1703,6 +1703,7 @@ static int megasas_create_sg_sense_fusion(struct >megasas_instance *instance) > struct IO_REQUEST_INFO io_info; > struct fusion_context *fusion; > struct MR_DRV_RAID_MAP_ALL *local_map_ptr; >+ u16 msix_index; > u8 *raidLUN; > > device_id = MEGASAS_DEV_INDEX(scp); >@@ -1792,11 +1793,13 @@ static int megasas_create_sg_sense_fusion(struct >megasas_instance *instance) > fp_possible = io_info.fpOkForIo; > } > >- /* Use raw_smp_processor_id() for now until cmd->request->cpu is >CPU >- id by default, not CPU group id, otherwise all MSI-X queues >won't >- be utilized */ >- cmd->request_desc->SCSIIO.MSIxIndex = instance->msix_vectors ? >- raw_smp_processor_id() % instance->msix_vectors : 0; >+ if (shost_use_blk_mq(instance->host)) { >+ u32 blk_tag = blk_mq_unique_tag(scp->request); >+ msix_index = blk_mq_unique_tag_to_hwq(blk_tag); >+ } else >+ msix_index = instance->msix_vectors ? >+ raw_sm
RE: [PATCH 3/5] megaraid_sas: do not crash on invalid completion
>-Original Message- >From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- >ow...@vger.kernel.org] On Behalf Of Hannes Reinecke >Sent: Friday, November 11, 2016 3:15 PM >To: Martin K. Petersen >Cc: Christoph Hellwig; James Bottomley; Sumit Saxena; linux- >s...@vger.kernel.org; Hannes Reinecke; Hannes Reinecke >Subject: [PATCH 3/5] megaraid_sas: do not crash on invalid completion > >Avoid a kernel oops when receiving an invalid command completion. scmd_local set to NULL(for cases MPI2_FUNCTION_SCSI_IO_REQUEST and MEGASAS_MPI2_FUNCTION_LD_IO_REQUEST) will be serious bug(either in driver or firmware) which should be debugged and driver should not really continue beyond that. This indicates that driver internal frames are corrupted. If needed, whenever driver detects it, it can mark the adapter as dead(stopping further activities). If OS is installed behind megasas controller then after declaring adapter dead, system reboot will be required. Kernel panic may give here more information whenever this condition hits so we kept it like this. If you are facing this issue, please share the details. I will work on this. Thanks, Sumit > >Signed-off-by: Hannes Reinecke <h...@suse.com> >--- > drivers/scsi/megaraid/megaraid_sas_fusion.c | 22 +++--- > 1 file changed, 15 insertions(+), 7 deletions(-) > >diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c >b/drivers/scsi/megaraid/megaraid_sas_fusion.c >index 38137de..eb3cb0f 100644 >--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c >+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c >@@ -2298,13 +2298,15 @@ static void megasas_build_ld_nonrw_fusion(struct >megasas_instance *instance, > break; > case MPI2_FUNCTION_SCSI_IO_REQUEST: /*Fast Path IO.*/ > /* Update load balancing info */ >- device_id = MEGASAS_DEV_INDEX(scmd_local); >- lbinfo = >load_balance_info[device_id]; >- if (cmd_fusion->scmd->SCp.Status & >- MEGASAS_LOAD_BALANCE_FLAG) { >- >atomic_dec(>scsi_pending_cmds[cmd_fusion->pd_r1_lb]); >- cmd_fusion->scmd->SCp.Status &= >- ~MEGASAS_LOAD_BALANCE_FLAG; >+ if (scmd_local) { >+ device_id = MEGASAS_DEV_INDEX(scmd_local); >+ lbinfo = >>load_balance_info[device_id]; >+ if (cmd_fusion->scmd->SCp.Status & >+ MEGASAS_LOAD_BALANCE_FLAG) { >+ >atomic_dec(>scsi_pending_cmds[cmd_fusion->pd_r1_lb]); >+ cmd_fusion->scmd->SCp.Status &= >+ >~MEGASAS_LOAD_BALANCE_FLAG; >+ } > } > if (reply_descript_type == > MPI2_RPY_DESCRIPT_FLAGS_SCSI_IO_SUCCESS) { @@ >-2315,6 +2317,12 @@ static void megasas_build_ld_nonrw_fusion(struct >megasas_instance *instance, > /* Fall thru and complete IO */ > case MEGASAS_MPI2_FUNCTION_LD_IO_REQUEST: /* LD-IO >Path */ > /* Map the FW Cmd Status */ >+ if (!scmd_local) { >+ dev_err(>pdev->dev, >+ "cmd[%d:%d] already completed\n", >+ MSIxIndex, smid); >+ break; >+ } > map_cmd_status(cmd_fusion, status, extStatus); > scsi_io_req->RaidContext.status = 0; > scsi_io_req->RaidContext.exStatus = 0; >-- >1.8.5.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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/5] megaraid_sas: switch to pci_alloc_irq_vectors
>-Original Message- >From: Hannes Reinecke [mailto:h...@suse.de] >Sent: Friday, November 11, 2016 3:15 PM >To: Martin K. Petersen >Cc: Christoph Hellwig; James Bottomley; Sumit Saxena; linux- >s...@vger.kernel.org; Hannes Reinecke; Hannes Reinecke >Subject: [PATCH 1/5] megaraid_sas: switch to pci_alloc_irq_vectors > >Cleanup the MSI-X handling allowing us to use the PCI-layer provided vector >allocation. > >Signed-off-by: Hannes Reinecke <h...@suse.com> >--- > drivers/scsi/megaraid/megaraid_sas.h | 1 - > drivers/scsi/megaraid/megaraid_sas_base.c | 63 ++- > 2 files changed, 29 insertions(+), 35 deletions(-) > >diff --git a/drivers/scsi/megaraid/megaraid_sas.h >b/drivers/scsi/megaraid/megaraid_sas.h >index ca86c88..8f1d2b4 100644 >--- a/drivers/scsi/megaraid/megaraid_sas.h >+++ b/drivers/scsi/megaraid/megaraid_sas.h >@@ -2118,7 +2118,6 @@ struct megasas_instance { > u32 ctrl_context_pages; > struct megasas_ctrl_info *ctrl_info; > unsigned int msix_vectors; >- struct msix_entry msixentry[MEGASAS_MAX_MSIX_QUEUES]; > struct megasas_irq_context >irq_context[MEGASAS_MAX_MSIX_QUEUES]; > u64 map_id; > u64 pd_seq_map_id; >diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c >b/drivers/scsi/megaraid/megaraid_sas_base.c >index 3236632..e7e3efd 100644 >--- a/drivers/scsi/megaraid/megaraid_sas_base.c >+++ b/drivers/scsi/megaraid/megaraid_sas_base.c >@@ -4843,7 +4843,7 @@ int megasas_set_crash_dump_params(struct >megasas_instance *instance, } > > /* >- * megasas_setup_irqs_msix - register legacy interrupts. >+ * megasas_setup_irqs_ioapic -register legacy interrupts. > * @instance: Adapter soft state > * > * Do not enable interrupt, only setup ISRs. >@@ -4858,8 +4858,9 @@ int megasas_set_crash_dump_params(struct >megasas_instance *instance, > pdev = instance->pdev; > instance->irq_context[0].instance = instance; > instance->irq_context[0].MSIxIndex = 0; >- if (request_irq(pdev->irq, instance->instancet->service_isr, >- IRQF_SHARED, "megasas", >irq_context[0])) { >+ if (request_irq(pci_irq_vector(pdev, 0), >+ instance->instancet->service_isr, IRQF_SHARED, >+ "megasas", >irq_context[0])) { > dev_err(>pdev->dev, > "Failed to register IRQ from %s %d\n", > __func__, __LINE__); >@@ -4880,28 +4881,23 @@ int megasas_set_crash_dump_params(struct >megasas_instance *instance, static int megasas_setup_irqs_msix(struct >megasas_instance *instance, u8 is_probe) { >- int i, j, cpu; >+ int i, j; > struct pci_dev *pdev; > > pdev = instance->pdev; > > /* Try MSI-x */ >- cpu = cpumask_first(cpu_online_mask); > for (i = 0; i < instance->msix_vectors; i++) { > instance->irq_context[i].instance = instance; > instance->irq_context[i].MSIxIndex = i; >- if (request_irq(instance->msixentry[i].vector, >+ if (request_irq(pci_irq_vector(pdev, i), > instance->instancet->service_isr, 0, "megasas", > >irq_context[i])) { > dev_err(>pdev->dev, > "Failed to register IRQ for vector %d.\n", i); >- for (j = 0; j < i; j++) { >- if (smp_affinity_enable) >- irq_set_affinity_hint( >- instance->msixentry[j].vector, >NULL); >- free_irq(instance->msixentry[j].vector, >- >irq_context[j]); >- } >+ for (j = 0; j < i; j++) >+ free_irq(pci_irq_vector(pdev, j), >+ >irq_context[j]); > /* Retry irq register for IO_APIC*/ > instance->msix_vectors = 0; > if (is_probe) >@@ -4909,14 +4905,6 @@ int megasas_set_crash_dump_params(struct >megasas_instance *instance, > else > return -1; > } >- if (smp_affinity_enable) { >- if (irq_set_affinity_hint(instance->msixentry[i].vector, >- get_cpu_mask(cpu))) >- dev_err(>pdev->dev, >-
RE: [PATCH 5/5] megaraid_sas: add mmio barrier after register writes
>-Original Message- >From: Hannes Reinecke [mailto:h...@suse.de] >Sent: Friday, November 11, 2016 3:15 PM >To: Martin K. Petersen >Cc: Christoph Hellwig; James Bottomley; Sumit Saxena; linux- >s...@vger.kernel.org; Hannes Reinecke; Hannes Reinecke >Subject: [PATCH 5/5] megaraid_sas: add mmio barrier after register writes > >The megaraid_sas HBA only has a single register for I/O submission, which will be >hit pretty hard with scsi-mq. To ensure that the PCI writes have made it across we >need to add a mmio barrier after each write; otherwise I've been seeing spurious >command completions and I/O stalls. > >Signed-off-by: Hannes Reinecke <h...@suse.com> Acked-by: Sumit Saxena <sumit.sax...@broadcom.com> >--- > drivers/scsi/megaraid/megaraid_sas_fusion.c | 1 + > 1 file changed, 1 insertion(+) > >diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c >b/drivers/scsi/megaraid/megaraid_sas_fusion.c >index aba53c0..729a654 100644 >--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c >+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c >@@ -196,6 +196,7 @@ inline void megasas_return_cmd_fusion(struct >megasas_instance *instance, > le32_to_cpu(req_desc->u.low)); > > writeq(req_data, >reg_set->inbound_low_queue_port); >+ mmiowb(); > #else > unsigned long flags; > >-- >1.8.5.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 2/5] megaraid_sas: avoid calling megasas_lookup_instance()
>-Original Message- >From: Hannes Reinecke [mailto:h...@suse.de] >Sent: Friday, November 11, 2016 3:15 PM >To: Martin K. Petersen >Cc: Christoph Hellwig; James Bottomley; Sumit Saxena; linux- >s...@vger.kernel.org; Hannes Reinecke; Hannes Reinecke >Subject: [PATCH 2/5] megaraid_sas: avoid calling megasas_lookup_instance() > >It's quite pointless to call megasas_lookup_instance() if we can derive a pointer >to the structure directly. > >Signed-off-by: Hannes Reinecke <h...@suse.com> Acked-by: Sumit Saxena <sumit.sax...@broadcom.com> >--- > drivers/scsi/megaraid/megaraid_sas.h| 3 ++- > drivers/scsi/megaraid/megaraid_sas_base.c | 24 +++- > drivers/scsi/megaraid/megaraid_sas_fusion.c | 2 +- > 3 files changed, 14 insertions(+), 15 deletions(-) > >diff --git a/drivers/scsi/megaraid/megaraid_sas.h >b/drivers/scsi/megaraid/megaraid_sas.h >index 8f1d2b4..296e692 100644 >--- a/drivers/scsi/megaraid/megaraid_sas.h >+++ b/drivers/scsi/megaraid/megaraid_sas.h >@@ -2375,7 +2375,8 @@ void megasas_return_mfi_mpt_pthr(struct >megasas_instance *instance, int megasas_cmd_type(struct scsi_cmnd *cmd); >void megasas_setup_jbod_map(struct megasas_instance *instance); > >-void megasas_update_sdev_properties(struct scsi_device *sdev); >+void megasas_update_sdev_properties(struct megasas_instance *instance, >+ struct scsi_device *sdev); > int megasas_reset_fusion(struct Scsi_Host *shost, int reason); int >megasas_task_abort_fusion(struct scsi_cmnd *scmd); int >megasas_reset_target_fusion(struct scsi_cmnd *scmd); diff --git >a/drivers/scsi/megaraid/megaraid_sas_base.c >b/drivers/scsi/megaraid/megaraid_sas_base.c >index e7e3efd..d580406 100644 >--- a/drivers/scsi/megaraid/megaraid_sas_base.c >+++ b/drivers/scsi/megaraid/megaraid_sas_base.c >@@ -1736,22 +1736,22 @@ static struct megasas_instance >*megasas_lookup_instance(u16 host_no) > /* > * megasas_update_sdev_properties - Update sdev structure based on >controller's FW capabilities > * >+* @instance: Megasas instance > * @sdev: OS provided scsi device > * > * Returns void > */ >-void megasas_update_sdev_properties(struct scsi_device *sdev) >+void megasas_update_sdev_properties(struct megasas_instance *instance, >+ struct scsi_device *sdev) > { > u16 pd_index = 0; > u32 device_id, ld; >- struct megasas_instance *instance; > struct fusion_context *fusion; > struct MR_PRIV_DEVICE *mr_device_priv_data; > struct MR_PD_CFG_SEQ_NUM_SYNC *pd_sync; > struct MR_LD_RAID *raid; > struct MR_DRV_RAID_MAP_ALL *local_map_ptr; > >- instance = megasas_lookup_instance(sdev->host->host_no); > fusion = instance->ctrl_context; > mr_device_priv_data = sdev->hostdata; > >@@ -1780,13 +1780,11 @@ void megasas_update_sdev_properties(struct >scsi_device *sdev) > } > } > >-static void megasas_set_device_queue_depth(struct scsi_device *sdev) >+static void megasas_set_device_queue_depth(struct megasas_instance >*instance, >+ struct scsi_device *sdev) > { > u16 pd_index = 0; > int ret = DCMD_FAILED; >- struct megasas_instance *instance; >- >- instance = megasas_lookup_instance(sdev->host->host_no); > > if (sdev->channel < MEGASAS_MAX_PD_CHANNELS) { > pd_index = (sdev->channel * >MEGASAS_MAX_DEV_PER_CHANNEL) + sdev->id; @@ -1822,9 +1820,9 @@ >static void megasas_set_device_queue_depth(struct scsi_device *sdev) static int >megasas_slave_configure(struct scsi_device *sdev) { > u16 pd_index = 0; >- struct megasas_instance *instance; >+ struct megasas_instance *instance = (struct megasas_instance *) >+ sdev->host->hostdata; > >- instance = megasas_lookup_instance(sdev->host->host_no); > if (instance->pd_list_not_supported) { > if (sdev->channel < MEGASAS_MAX_PD_CHANNELS && > sdev->type == TYPE_DISK) { >@@ -1835,8 +1833,8 @@ static int megasas_slave_configure(struct scsi_device >*sdev) > return -ENXIO; > } > } >- megasas_set_device_queue_depth(sdev); >- megasas_update_sdev_properties(sdev); >+ megasas_set_device_queue_depth(instance, sdev); >+ megasas_update_sdev_properties(instance, sdev); > > /* >* The RAID firmware may require extended timeouts. >@@ -1850,10 +1848,10 @@ static int megasas_slave_configure(struct >scsi_device *sdev) static
[PATCH] megaraid_sas: fix macro MEGASAS_IS_LOGICAL to avoid regression caused by commit 1e793f6fc0db920400574211c48f9157a37e3945
This patch will fix regression caused by below commit- 1e793f6 scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) devices The problem was MEGASAS_IS_LOGICAL macro does not have braces and because of above commit using this macro was exposing lot of non-existing SCSI devices(all SCSI commands to channels-1,2,3 was returned as SUCCESS-DID_OK by driver). Fixes: 1e793f6fc0db920400574211c48f9157a37e3945 Reported-by: Jens Axboe <ax...@kernel.dk> CC: sta...@vger.kernel.org Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com> Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> Tested-by: Sumit Saxena <sumit.sax...@broadcom.com> --- drivers/scsi/megaraid/megaraid_sas.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/megaraid/megaraid_sas.h b/drivers/scsi/megaraid/megaraid_sas.h index ca86c88..3aaea71 100644 --- a/drivers/scsi/megaraid/megaraid_sas.h +++ b/drivers/scsi/megaraid/megaraid_sas.h @@ -2233,7 +2233,7 @@ struct megasas_instance_template { }; #define MEGASAS_IS_LOGICAL(scp) \ - (scp->device->channel < MEGASAS_MAX_PD_CHANNELS) ? 0 : 1 + ((scp->device->channel < MEGASAS_MAX_PD_CHANNELS) ? 0 : 1) #define MEGASAS_DEV_INDEX(scp) \ (((scp->device->channel % 2) * MEGASAS_MAX_DEV_PER_CHANNEL) + \ -- 1.8.3.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] megaraid-sas: request irqs later
>-Original Message- >From: Tomas Henzl [mailto:the...@redhat.com] >Sent: Tuesday, November 01, 2016 10:02 PM >To: linux-scsi@vger.kernel.org >Cc: sumit.sax...@broadcom.com; kashyap.de...@broadcom.com >Subject: [PATCH] megaraid-sas: request irqs later > >It is not good when an irq arrives before driver structures are allocated. > >Signed-off-by: Tomas Henzl <the...@redhat.com> >--- > drivers/scsi/megaraid/megaraid_sas_base.c | 12 +--- > 1 file changed, 5 insertions(+), 7 deletions(-) > >diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c >b/drivers/scsi/megaraid/megaraid_sas_base.c >index c3efcc7255..e207410150 100644 >--- a/drivers/scsi/megaraid/megaraid_sas_base.c >+++ b/drivers/scsi/megaraid/megaraid_sas_base.c >@@ -5155,11 +5155,6 @@ static int megasas_init_fw(struct megasas_instance >*instance) > tasklet_init(>isr_tasklet, instance->instancet->tasklet, > (unsigned long)instance); > >- if (instance->msix_vectors ? >- megasas_setup_irqs_msix(instance, 1) : >- megasas_setup_irqs_ioapic(instance)) >- goto fail_setup_irqs; >- > instance->ctrl_info = kzalloc(sizeof(struct megasas_ctrl_info), > GFP_KERNEL); > if (instance->ctrl_info == NULL) >@@ -5175,6 +5170,10 @@ static int megasas_init_fw(struct megasas_instance >*instance) > if (instance->instancet->init_adapter(instance)) > goto fail_init_adapter; > >+ if (instance->msix_vectors ? >+ megasas_setup_irqs_msix(instance, 1) : >+ megasas_setup_irqs_ioapic(instance)) >+ goto fail_init_adapter; > > instance->instancet->enable_intr(instance); > >@@ -5314,9 +5313,8 @@ static int megasas_init_fw(struct megasas_instance >*instance) > > fail_get_pd_list: > instance->instancet->disable_intr(instance); >-fail_init_adapter: > megasas_destroy_irqs(instance); >-fail_setup_irqs: >+fail_init_adapter: > if (instance->msix_vectors) > pci_disable_msix(instance->pdev); > instance->msix_vectors = 0; Looks good to me. Acked-by: Sumit Saxena <sumit.sax...@broadcom.com> >-- >2.7.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 v2 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware
>From previous patch we have below changes in v2 - 1. Updated change log. Provided more detail in change log. 2. Agreed to remove module parameter. If we remove module parameter, we can ask customer to disable WCE on drive to get similar impact. 3. Always Send SYNCHRONIZE_CACHE for JBOD (non Raid) Device to Firmware. Current megaraid_sas driver returns SYNCHRONIZE_CACHE(related to Drive Cache) command back to SCSI layer without sending it down to firmware as firmware supposed to take care of flushing disk cache for all drives belongs to Virtual Disk at the time of system reboot/shutdown. We evaluate and understood that for Raid Volume, why driver should not send SYNC_CACHE command to the Firmware. There may be a some reason in past, but now it looks to be not required and we have fixed this issue as part of this patch. Commit- " 02b01e0 [SCSI] megaraid_sas: return sync cache call with success" added the code in driver to return SYNCHRONIZE_CACHE without sending it to firmware back in 2007. Earlier MR was mainly for Virtual Disk, so same code continue for JBOD as well whenever JBOD support was added and it introduced bug that SYNCHRONIZE_CACHE is not passed to FW for JBOD (non Raid disk). But our recent analysis indicates that, From Day-1 MR Firmware always expect Driver to forward SYNCHRONIZE_CACHE for JBOD (non Raid disk) to the Firmware. We have fixed this as part of this patch. - Additional background - There are some instance of MegaRaid FW (E.a Gen2 and Gen2.5 FW) set WCE bit for Virtual Disk but firmware does not reply correct status for SYNCH_CACHE. It is very difficult to find out which Device ID and firmware has capability to manage SYNC_CACHE, so we managed to figure out which are the new firmware (canHandleSyncCache is set in scratch pad register at 0xB4) and use that interface for correct behavior as explained above. E.g Liberator/Thunderbolt MegaRaid FW returns SYNC_CACHE as Unsupported command (this is a firmware bug) and eventually command will be failed to SML. This will cause File system to go Read-only. - New behavior described - IF application requests SYNCH_CACHE IF 'JBOD' Driver sends SYNCH_CACHE command to the FW FW sends SYNCH_CACHE to drive FW obtains status from drive and returns same status back to driver ELSEIF 'VirtualDisk' IF any FW which supports new API bit called canHandleSyncCache Driver sends SYNCH_CACHE command to the FW FW does not send SYNCH_CACHE to drives FW returns SUCCESS ELSE Driver does not send SYNCH_CACHE command to the FW. Driver return SUCCESS for that command. ENDIF ENDIF ENDIF CC: sta...@vger.kernel.org Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com> Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> --- drivers/scsi/megaraid/megaraid_sas.h| 3 +++ drivers/scsi/megaraid/megaraid_sas_base.c | 10 ++ drivers/scsi/megaraid/megaraid_sas_fusion.c | 5 + 3 files changed, 10 insertions(+), 8 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas.h b/drivers/scsi/megaraid/megaraid_sas.h index ca86c88..43fd14f 100644 --- a/drivers/scsi/megaraid/megaraid_sas.h +++ b/drivers/scsi/megaraid/megaraid_sas.h @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT { #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14 #define MR_MAX_MSIX_REG_ARRAY 16 #define MR_RDPQ_MODE_OFFSET0X0080 +#define MR_CAN_HANDLE_SYNC_CACHE_OFFSET0X0100 + /* * register set for both 1068 and 1078 controllers * structure extended for 1078 registers @@ -2140,6 +2142,7 @@ struct megasas_instance { u8 is_imr; u8 is_rdpq; bool dev_handle; + bool fw_sync_cache_support; }; struct MR_LD_VF_MAP { u32 size; diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index 3236632..f7a2ab1 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -1700,16 +1700,10 @@ inline int megasas_cmd_type(struct scsi_cmnd *cmd) goto out_done; } - switch (scmd->cmnd[0]) { - case SYNCHRONIZE_CACHE: - /* -* FW takes care of flush cache on its own -* No need to send it down -*/ + if (MEGASAS_IS_LOGICAL(scmd) && (scmd->cmnd[0] == SYNCHRONIZE_CACHE) && + (!instance->fw_sync_cache_support)) { scmd->result = DID_OK << 16; goto out_done; - default: - break; } return instance->instancet->build_and_issue_cmd(instance, scmd); diff --git a/drivers/scsi/megaraid/megaraid_sas_fusi
[PATCH v2 7/7] megaraid_sas: driver version upgrade
Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> --- drivers/scsi/megaraid/megaraid_sas.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas.h b/drivers/scsi/megaraid/megaraid_sas.h index 43fd14f..1d4de90 100644 --- a/drivers/scsi/megaraid/megaraid_sas.h +++ b/drivers/scsi/megaraid/megaraid_sas.h @@ -35,8 +35,8 @@ /* * MegaRAID SAS Driver meta data */ -#define MEGASAS_VERSION"06.811.02.00-rc1" -#define MEGASAS_RELDATE"April 12, 2016" +#define MEGASAS_VERSION"06.812.07.00-rc1" +#define MEGASAS_RELDATE"August 22, 2016" /* * Device IDs -- 1.8.3.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 0/7] megaraid_sas: Updates for scsi-next
Changes in v2: 1. Removed unconditional msleep and moved calls to atomic_read into megasas_wait_for_adapter_operational 2. Updated change log for patch #4. Provided more detail in change log. 3. Agreed to remove module parameter. If we remove module parameter, we can ask customer to disable WCE on drive to get similar impact. 4. Always Send SYNCHRONIZE_CACHE for JBOD (non Raid) Device to Firmware. 5. Add log message printing the state of FW sync cache support 6. Moved version update patch to end of series Sumit Saxena (7): megaraid_sas: For SRIOV enabled firmware, ensure VF driver waits for 30secs before reset megaraid_sas: Send correct PhysArm to FW for R1 VD downgrade megaraid_sas: Do not fire DCMDs during PCI shutdown/detach megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware MAINTAINERS: Update megaraid maintainers list megaraid_sas: Do not set MPI2_TYPE_CUDA for JBOD FP path for FW which does not support JBOD sequence map megaraid_sas: driver version upgrade MAINTAINERS | 10 +++--- drivers/scsi/megaraid/megaraid_sas.h| 7 +++-- drivers/scsi/megaraid/megaraid_sas_base.c | 49 - drivers/scsi/megaraid/megaraid_sas_fp.c | 6 ++-- drivers/scsi/megaraid/megaraid_sas_fusion.c | 23 +- 5 files changed, 71 insertions(+), 24 deletions(-) -- 1.8.3.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 1/7] megaraid_sas: For SRIOV enabled firmware, ensure VF driver waits for 30secs before reset
For SRIOV enabled firmware, if there is a OCR(online controller reset) possibility driver set the convert flag to 1, which is not happening if there are outstanding commands even after 180 seconds. As driver does not set convert flag to 1 and still making the OCR to run, VF(Virtual function) driver is directly writing on to the register instead of waiting for 30 seconds. Setting convert flag to 1 will cause VF driver will wait for 30 secs before going for reset. CC: sta...@vger.kernel.org Signed-off-by: Kiran Kumar Kasturi <kiran-kumar.kast...@broadcom.com> Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> Reviewed-by: Hannes Reinecke <h...@suse.com> Reviewed-by: Tomas Henzl <the...@redhat.com> --- drivers/scsi/megaraid/megaraid_sas_fusion.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c b/drivers/scsi/megaraid/megaraid_sas_fusion.c index 52d8bbf..61be7ed 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c @@ -2823,6 +2823,7 @@ int megasas_wait_for_outstanding_fusion(struct megasas_instance *instance, dev_err(>pdev->dev, "pending commands remain after waiting, " "will reset adapter scsi%d.\n", instance->host->host_no); + *convert = 1; retval = 1; } out: -- 1.8.3.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 2/7] megaraid_sas: Send correct PhysArm to FW for R1 VD downgrade
This patch fixes the issue of wrong PhysArm was sent to firmware for R1 VD downgrade. Signed-off-by: Kiran Kumar Kasturi <kiran-kumar.kast...@broadcom.com> Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> Reviewed-by: Hannes Reinecke <h...@suse.com> Reviewed-by: Tomas Henzl <the...@redhat.com> --- drivers/scsi/megaraid/megaraid_sas_fp.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_fp.c b/drivers/scsi/megaraid/megaraid_sas_fp.c index e413113..f237d00 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fp.c +++ b/drivers/scsi/megaraid/megaraid_sas_fp.c @@ -782,7 +782,8 @@ static u8 mr_spanset_get_phy_params(struct megasas_instance *instance, u32 ld, (raid->regTypeReqOnRead != REGION_TYPE_UNUSED pRAID_Context->regLockFlags = REGION_TYPE_EXCLUSIVE; else if (raid->level == 1) { - pd = MR_ArPdGet(arRef, physArm + 1, map); + physArm = physArm + 1; + pd = MR_ArPdGet(arRef, physArm, map); if (pd != MR_PD_INVALID) *pDevHandle = MR_PdDevHandleGet(pd, map); } @@ -879,7 +880,8 @@ u8 MR_GetPhyParams(struct megasas_instance *instance, u32 ld, u64 stripRow, pRAID_Context->regLockFlags = REGION_TYPE_EXCLUSIVE; else if (raid->level == 1) { /* Get alternate Pd. */ - pd = MR_ArPdGet(arRef, physArm + 1, map); + physArm = physArm + 1; + pd = MR_ArPdGet(arRef, physArm, map); if (pd != MR_PD_INVALID) /* Get dev handle from Pd */ *pDevHandle = MR_PdDevHandleGet(pd, map); -- 1.8.3.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 3/7] megaraid_sas: Do not fire DCMDs during PCI shutdown/detach
This patch addresses the issue of driver firing DCMDs in PCI shutdown/detach path irrespective of firmware state. Driver will check for whether firmware is operational state or not before firing DCMDs. If firmware is in unrecoverbale state or does not become operational within specfied time, driver will skip firing DCMDs. Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> Signed-off-by: Shivasharan Srikanteshwara <shivasharan.srikanteshw...@broadcom.com> --- drivers/scsi/megaraid/megaraid_sas_base.c | 39 + drivers/scsi/megaraid/megaraid_sas_fusion.c | 9 --- 2 files changed, 45 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index 9ff57de..3236632 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -6248,6 +6248,34 @@ static void megasas_shutdown_controller(struct megasas_instance *instance, #define megasas_resume NULL #endif +static inline int +megasas_wait_for_adapter_operational(struct megasas_instance *instance) +{ + int wait_time = MEGASAS_RESET_WAIT_TIME * 2; + int i; + + if (atomic_read(>adprecovery) == MEGASAS_HW_CRITICAL_ERROR) + return 1; + + for (i = 0; i < wait_time; i++) { + if (atomic_read(>adprecovery) == MEGASAS_HBA_OPERATIONAL) + break; + + if (!(i % MEGASAS_RESET_NOTICE_INTERVAL)) + dev_notice(>pdev->dev, "waiting for controller reset to finish\n"); + + msleep(1000); + } + + if (atomic_read(>adprecovery) != MEGASAS_HBA_OPERATIONAL) { + dev_info(>pdev->dev, "%s timed out while waiting for HBA to recover.\n", + __func__); + return 1; + } + + return 0; +} + /** * megasas_detach_one -PCI hot"un"plug entry point * @pdev: PCI device structure @@ -6272,9 +6300,14 @@ static void megasas_detach_one(struct pci_dev *pdev) if (instance->fw_crash_state != UNAVAILABLE) megasas_free_host_crash_buffer(instance); scsi_remove_host(instance->host); + + if (megasas_wait_for_adapter_operational(instance)) + goto skip_firing_dcmds; + megasas_flush_cache(instance); megasas_shutdown_controller(instance, MR_DCMD_CTRL_SHUTDOWN); +skip_firing_dcmds: /* cancel the delayed work if this work still in queue*/ if (instance->ev != NULL) { struct megasas_aen_event *ev = instance->ev; @@ -6388,8 +6421,14 @@ static void megasas_shutdown(struct pci_dev *pdev) struct megasas_instance *instance = pci_get_drvdata(pdev); instance->unload = 1; + + if (megasas_wait_for_adapter_operational(instance)) + goto skip_firing_dcmds; + megasas_flush_cache(instance); megasas_shutdown_controller(instance, MR_DCMD_CTRL_SHUTDOWN); + +skip_firing_dcmds: instance->instancet->disable_intr(instance); megasas_destroy_irqs(instance); diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c b/drivers/scsi/megaraid/megaraid_sas_fusion.c index 61be7ed..2159f6a 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c @@ -2463,12 +2463,15 @@ irqreturn_t megasas_isr_fusion(int irq, void *devp) /* Start collecting crash, if DMA bit is done */ if ((fw_state == MFI_STATE_FAULT) && dma_state) schedule_work(>crash_init); - else if (fw_state == MFI_STATE_FAULT) - schedule_work(>work_init); + else if (fw_state == MFI_STATE_FAULT) { + if (instance->unload == 0) + schedule_work(>work_init); + } } else if (fw_state == MFI_STATE_FAULT) { dev_warn(>pdev->dev, "Iop2SysDoorbellInt" "for scsi%d\n", instance->host->host_no); - schedule_work(>work_init); + if (instance->unload == 0) + schedule_work(>work_init); } } -- 1.8.3.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 5/7] MAINTAINERS: Update megaraid maintainers list
Update MEGARAID drivers maintainers list. Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> Reviewed-by: Hannes Reinecke <h...@suse.com> --- MAINTAINERS | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 4c1f3f9..05c0624 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7823,12 +7823,12 @@ S: Maintained F: drivers/net/wireless/mediatek/mt7601u/ MEGARAID SCSI/SAS DRIVERS -M: Kashyap Desai <kashyap.de...@avagotech.com> -M: Sumit Saxena <sumit.sax...@avagotech.com> -M: Uday Lingala <uday.ling...@avagotech.com> -L: megaraidlinux@avagotech.com +M: Kashyap Desai <kashyap.de...@broadcom.com> +M: Sumit Saxena <sumit.sax...@broadcom.com> +M: Shivasharan S <shivasharan.srikanteshw...@broadcom.com> +L: megaraidlinux@broadcom.com L: linux-scsi@vger.kernel.org -W: http://www.lsi.com +W: http://www.avagotech.com/support/ S: Maintained F: Documentation/scsi/megaraid.txt F: drivers/scsi/megaraid.* -- 1.8.3.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 6/7] megaraid_sas: Do not set MPI2_TYPE_CUDA for JBOD FP path for FW which does not support JBOD sequence map
CC: sta...@vger.kernel.org Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> Reviewed-by: Hannes Reinecke <h...@suse.com> Reviewed-by: Tomas Henzl <the...@redhat.com> --- drivers/scsi/megaraid/megaraid_sas_fusion.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c b/drivers/scsi/megaraid/megaraid_sas_fusion.c index 2e61306..24778ba 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c @@ -2005,6 +2005,8 @@ static void megasas_build_ld_nonrw_fusion(struct megasas_instance *instance, io_request->DevHandle = pd_sync->seq[pd_index].devHandle; pRAID_Context->regLockFlags |= (MR_RL_FLAGS_SEQ_NUM_ENABLE|MR_RL_FLAGS_GRANT_DESTINATION_CUDA); + pRAID_Context->Type = MPI2_TYPE_CUDA; + pRAID_Context->nseg = 0x1; } else if (fusion->fast_path_io) { pRAID_Context->VirtualDiskTgtId = cpu_to_le16(device_id); pRAID_Context->configSeqNum = 0; @@ -2040,12 +2042,10 @@ static void megasas_build_ld_nonrw_fusion(struct megasas_instance *instance, pRAID_Context->timeoutValue = cpu_to_le16((os_timeout_value > timeout_limit) ? timeout_limit : os_timeout_value); - if (fusion->adapter_type == INVADER_SERIES) { - pRAID_Context->Type = MPI2_TYPE_CUDA; - pRAID_Context->nseg = 0x1; + if (fusion->adapter_type == INVADER_SERIES) io_request->IoFlags |= cpu_to_le16(MPI25_SAS_DEVICE0_FLAGS_ENABLED_FAST_PATH); - } + cmd->request_desc->SCSIIO.RequestFlags = (MPI2_REQ_DESCRIPT_FLAGS_FP_IO << MEGASAS_REQ_DESCRIPT_FLAGS_TYPE_SHIFT); -- 1.8.3.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 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware
>-Original Message- >From: James Bottomley [mailto:j...@linux.vnet.ibm.com] >Sent: Monday, October 17, 2016 11:22 PM >To: Kashyap Desai; Ric Wheeler; Hannes Reinecke; Sumit Saxena; linux- >s...@vger.kernel.org >Cc: martin.peter...@oracle.com; the...@redhat.com; Christoph Hellwig; >Martin >K. Petersen; Jeff Moyer; Gris Ge; Ewan Milne; Jens Axboe >Subject: Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to >firmware > >On Mon, 2016-10-17 at 23:06 +0530, Kashyap Desai wrote: >> > -Original Message- >> > From: James Bottomley [mailto:j...@linux.vnet.ibm.com] >> > Sent: Monday, October 17, 2016 10:50 PM >> > To: Ric Wheeler; Hannes Reinecke; Sumit Saxena; >> > linux-scsi@vger.kernel.org >> > Cc: martin.peter...@oracle.com; the...@redhat.com; >> > kashyap.de...@broadcom.com; Christoph Hellwig; Martin K. Petersen; >> > Jeff Moyer; Gris Ge; Ewan Milne; Jens Axboe >> > Subject: Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE >> > command to firmware >> > >> > On Mon, 2016-10-17 at 12:27 -0400, Ric Wheeler wrote: >> > > On 10/17/2016 12:20 PM, James Bottomley wrote: >> > > > On Mon, 2016-10-17 at 09:01 -0400, Ric Wheeler wrote: >> > > > > On 10/17/2016 07:34 AM, Hannes Reinecke wrote: >> > > > > > On 10/17/2016 12:24 PM, Sumit Saxena wrote: >> > > > > > > megaraid_sas driver returns SYNCHRONIZE_CACHE command back >> > > > > > > to SCSI layer without sending it to firmware as firmware >> > > > > > > takes care of flushing cache. This patch will change the >> > > > > > > driver behavior wrt SYNCHRONIZE_CACHE handling. If >> > > > > > > underlying firmware has support to handle the >> > > > > > > SYNCHORNIZE_CACHE, driver will send it for firmware >> > > > > > > otherwise complete it back to SCSI layer with SUCCESS >> > > > > > > immediately. If Firmware handle SYNCHORNIZE_CACHE for >> > > > > > > both VD and JBOD "canHandleSyncCache" >> > > > > > > bit in scratch pad register(offset >> > > > > > > 0x00B4) will be set. >> > > > > > > >> > > > > > > This behavior can be controlled via module parameter and >> > > > > > > user can fallback to old behavior of returning >> > > > > > > SYNCHRONIZE_CACHE by driver only without sending it to >> > > > > > > firmware. >> > > > > > > >> > > > > > > Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> >> > > > > > > Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com> >> > > > > > > --- >> > > > > > >drivers/scsi/megaraid/megaraid_sas.h| 3 +++ >> > > > > > >drivers/scsi/megaraid/megaraid_sas_base.c | 14 >> > > > > > > ++--- >> > > > > > > - >> > > > > > >drivers/scsi/megaraid/megaraid_sas_fusion.c | 3 +++ >> > > > > > >drivers/scsi/megaraid/megaraid_sas_fusion.h | 2 ++ >> > > > > > >4 files changed, 14 insertions(+), 8 deletions(-) >> > > > > > > >> > > > > > > diff --git a/drivers/scsi/megaraid/megaraid_sas.h >> > > > > > > b/drivers/scsi/megaraid/megaraid_sas.h >> > > > > > > index ca86c88..43fd14f 100644 >> > > > > > > --- a/drivers/scsi/megaraid/megaraid_sas.h >> > > > > > > +++ b/drivers/scsi/megaraid/megaraid_sas.h >> > > > > > > @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT { >> > > > > > >#define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14 >> > > > > > >#define MR_MAX_MSIX_REG_ARRAY 16 >> > > > > > >#define MR_RDPQ_MODE_OFFSET 0X0 >> > > > > > > 0800 >> > > > > > > 000 >> > > > > > > +#define MR_CAN_HANDLE_SYNC_CACHE_OFFSET 0 >> > > > > > > X010 >> > > > > > > >> > > > > > > 0 >> > > > > > > + >> > > > > > >/* >> > > > > > >* register set for both 1068 and 1078 controllers >> > > > > &g
RE: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware
>-Original Message- >From: Ric Wheeler [mailto:ricwhee...@gmail.com] >Sent: Tuesday, October 18, 2016 6:38 PM >To: Tomas Henzl; Sumit Saxena; linux-scsi@vger.kernel.org >Cc: martin.peter...@oracle.com; j...@linux.vnet.ibm.com; Kashyap Desai >Subject: Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to >firmware > >On 10/17/2016 09:57 AM, Tomas Henzl wrote: >> On 17.10.2016 15:28, Sumit Saxena wrote: >>>> -Original Message- >>>> From: Tomas Henzl [mailto:the...@redhat.com] >>>> Sent: Monday, October 17, 2016 6:44 PM >>>> To: Sumit Saxena; linux-scsi@vger.kernel.org >>>> Cc: martin.peter...@oracle.com; j...@linux.vnet.ibm.com; >>>> kashyap.de...@broadcom.com >>>> Subject: Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE >>>> command to firmware >>>> >>>> On 17.10.2016 12:24, Sumit Saxena wrote: >>>>> megaraid_sas driver returns SYNCHRONIZE_CACHE command back to SCSI >>>>> layer without sending it to firmware as firmware takes care of >>>>> flushing >>> cache. >>>>> This patch will change the driver behavior wrt SYNCHRONIZE_CACHE >>> handling. >>>>> If underlying firmware has support to handle the SYNCHORNIZE_CACHE, >>>>> driver will send it for firmware otherwise complete it back to SCSI >>>>> layer with SUCCESS immediately. >>>>> If Firmware handle SYNCHORNIZE_CACHE for both VD and JBOD >>>>> "canHandleSyncCache" bit in scratch pad register(offset 0x00B4) >>>>> will be set. >>>>> >>>>> This behavior can be controlled via module parameter and user can >>>>> fallback to old behavior of returning SYNCHRONIZE_CACHE by driver >>>>> only without sending it to firmware. >>>>> >>>>> Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> >>>>> Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com> >>>>> --- >>>>> drivers/scsi/megaraid/megaraid_sas.h| 3 +++ >>>>> drivers/scsi/megaraid/megaraid_sas_base.c | 14 ++ >>>>> drivers/scsi/megaraid/megaraid_sas_fusion.c | 3 +++ >>>>> drivers/scsi/megaraid/megaraid_sas_fusion.h | 2 ++ >>>>> 4 files changed, 14 insertions(+), 8 deletions(-) >>>>> >>>>> diff --git a/drivers/scsi/megaraid/megaraid_sas.h >>>>> b/drivers/scsi/megaraid/megaraid_sas.h >>>>> index ca86c88..43fd14f 100644 >>>>> --- a/drivers/scsi/megaraid/megaraid_sas.h >>>>> +++ b/drivers/scsi/megaraid/megaraid_sas.h >>>>> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT { >>>>> #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14 >>>>> #define MR_MAX_MSIX_REG_ARRAY 16 >>>>> #define MR_RDPQ_MODE_OFFSET 0X0080 >>>>> +#define MR_CAN_HANDLE_SYNC_CACHE_OFFSET 0X0100 >>>>> + >>>>> /* >>>>> * register set for both 1068 and 1078 controllers >>>>> * structure extended for 1078 registers @@ -2140,6 +2142,7 @@ >>>>> struct megasas_instance { >>>>> u8 is_imr; >>>>> u8 is_rdpq; >>>>> bool dev_handle; >>>>> + bool fw_sync_cache_support; >>>>> }; >>>>> struct MR_LD_VF_MAP { >>>>> u32 size; >>>>> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c >>>>> b/drivers/scsi/megaraid/megaraid_sas_base.c >>>>> index 092387f..a4a8e2f 100644 >>>>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c >>>>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c >>>>> @@ -104,6 +104,10 @@ unsigned int scmd_timeout = >>>>> MEGASAS_DEFAULT_CMD_TIMEOUT; module_param(scmd_timeout, int, >>>>> S_IRUGO); MODULE_PARM_DESC(scmd_timeout, "scsi command timeout >>>>> (10-90s), default 90s. See megasas_reset_timer."); >>>>> >>>>> +bool block_sync_cache; >>>>> +module_param(block_sync_cache, bool, S_IRUGO); >>>>> +MODULE_PARM_DESC(block_sync_cache, "Block SYNC CACHE by driver >>>>> +Default: 0(Send it to firmware)"); >>>>> + >>>>> MODULE_LICENSE("GPL"); >>>>> MODULE_VERSION(MEGASAS_VERSION); >>>>> MODULE_AUTHOR(&quo
RE: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware
>-Original Message- >From: Tomas Henzl [mailto:the...@redhat.com] >Sent: Monday, October 17, 2016 7:27 PM >To: Sumit Saxena; linux-scsi@vger.kernel.org >Cc: martin.peter...@oracle.com; j...@linux.vnet.ibm.com; Kashyap Desai >Subject: Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to >firmware > >On 17.10.2016 15:28, Sumit Saxena wrote: >>> -Original Message- >>> From: Tomas Henzl [mailto:the...@redhat.com] >>> Sent: Monday, October 17, 2016 6:44 PM >>> To: Sumit Saxena; linux-scsi@vger.kernel.org >>> Cc: martin.peter...@oracle.com; j...@linux.vnet.ibm.com; >>> kashyap.de...@broadcom.com >>> Subject: Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE >command >>> to firmware >>> >>> On 17.10.2016 12:24, Sumit Saxena wrote: >>>> megaraid_sas driver returns SYNCHRONIZE_CACHE command back to SCSI >>>> layer without sending it to firmware as firmware takes care of >>>> flushing >> cache. >>>> This patch will change the driver behavior wrt SYNCHRONIZE_CACHE >> handling. >>>> If underlying firmware has support to handle the SYNCHORNIZE_CACHE, >>>> driver will send it for firmware otherwise complete it back to SCSI >>>> layer with SUCCESS immediately. >>>> If Firmware handle SYNCHORNIZE_CACHE for both VD and JBOD >>>> "canHandleSyncCache" bit in scratch pad register(offset 0x00B4) will >>>> be set. >>>> >>>> This behavior can be controlled via module parameter and user can >>>> fallback to old behavior of returning SYNCHRONIZE_CACHE by driver >>>> only without sending it to firmware. >>>> >>>> Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> >>>> Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com> >>>> --- >>>> drivers/scsi/megaraid/megaraid_sas.h| 3 +++ >>>> drivers/scsi/megaraid/megaraid_sas_base.c | 14 ++ >>>> drivers/scsi/megaraid/megaraid_sas_fusion.c | 3 +++ >>>> drivers/scsi/megaraid/megaraid_sas_fusion.h | 2 ++ >>>> 4 files changed, 14 insertions(+), 8 deletions(-) >>>> >>>> diff --git a/drivers/scsi/megaraid/megaraid_sas.h >>>> b/drivers/scsi/megaraid/megaraid_sas.h >>>> index ca86c88..43fd14f 100644 >>>> --- a/drivers/scsi/megaraid/megaraid_sas.h >>>> +++ b/drivers/scsi/megaraid/megaraid_sas.h >>>> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT { >>>> #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14 >>>> #define MR_MAX_MSIX_REG_ARRAY 16 >>>> #define MR_RDPQ_MODE_OFFSET 0X0080 >>>> +#define MR_CAN_HANDLE_SYNC_CACHE_OFFSET 0X0100 >>>> + >>>> /* >>>> * register set for both 1068 and 1078 controllers >>>> * structure extended for 1078 registers @@ -2140,6 +2142,7 @@ >>>> struct megasas_instance { >>>>u8 is_imr; >>>>u8 is_rdpq; >>>>bool dev_handle; >>>> + bool fw_sync_cache_support; >>>> }; >>>> struct MR_LD_VF_MAP { >>>>u32 size; >>>> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c >>>> b/drivers/scsi/megaraid/megaraid_sas_base.c >>>> index 092387f..a4a8e2f 100644 >>>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c >>>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c >>>> @@ -104,6 +104,10 @@ unsigned int scmd_timeout = >>>> MEGASAS_DEFAULT_CMD_TIMEOUT; module_param(scmd_timeout, int, >>>> S_IRUGO); MODULE_PARM_DESC(scmd_timeout, "scsi command timeout >>>> (10-90s), default 90s. See megasas_reset_timer."); >>>> >>>> +bool block_sync_cache; >>>> +module_param(block_sync_cache, bool, S_IRUGO); >>>> +MODULE_PARM_DESC(block_sync_cache, "Block SYNC CACHE by driver >>>> +Default: 0(Send it to firmware)"); >>>> + >>>> MODULE_LICENSE("GPL"); >>>> MODULE_VERSION(MEGASAS_VERSION); >>>> MODULE_AUTHOR("megaraidlinux@avagotech.com"); >>>> @@ -1700,16 +1704,10 @@ megasas_queue_command(struct Scsi_Host >>> *shost, struct scsi_cmnd *scmd) >>>>goto out_done; >>>>} >>>> >>>> - switch (scmd->cmnd[0]) { >>>> - case SYNCHRONIZE_CACHE: >>>> - /* >>>> - * FW takes ca
RE: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware
>-Original Message- >From: Ric Wheeler [mailto:rwhee...@redhat.com] >Sent: Monday, October 17, 2016 6:31 PM >To: Hannes Reinecke; Sumit Saxena; linux-scsi@vger.kernel.org >Cc: martin.peter...@oracle.com; the...@redhat.com; j...@linux.vnet.ibm.com; >kashyap.de...@broadcom.com; Christoph Hellwig; Martin K. Petersen; Jeff >Moyer; Gris Ge; Ewan Milne; Jens Axboe >Subject: Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to >firmware > >On 10/17/2016 07:34 AM, Hannes Reinecke wrote: >> On 10/17/2016 12:24 PM, Sumit Saxena wrote: >>> megaraid_sas driver returns SYNCHRONIZE_CACHE command back to SCSI >>> layer without sending it to firmware as firmware takes care of flushing cache. >>> This patch will change the driver behavior wrt SYNCHRONIZE_CACHE handling. >>> If underlying firmware has support to handle the SYNCHORNIZE_CACHE, >>> driver will send it for firmware otherwise complete it back to SCSI >>> layer with SUCCESS immediately. >>> If Firmware handle SYNCHORNIZE_CACHE for both VD and JBOD >>> "canHandleSyncCache" bit in scratch pad register(offset 0x00B4) will >>> be set. >>> >>> This behavior can be controlled via module parameter and user can >>> fallback to old behavior of returning SYNCHRONIZE_CACHE by driver >>> only without sending it to firmware. >>> >>> Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> >>> Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com> >>> --- >>> drivers/scsi/megaraid/megaraid_sas.h| 3 +++ >>> drivers/scsi/megaraid/megaraid_sas_base.c | 14 ++ >>> drivers/scsi/megaraid/megaraid_sas_fusion.c | 3 +++ >>> drivers/scsi/megaraid/megaraid_sas_fusion.h | 2 ++ >>> 4 files changed, 14 insertions(+), 8 deletions(-) >>> >>> diff --git a/drivers/scsi/megaraid/megaraid_sas.h >>> b/drivers/scsi/megaraid/megaraid_sas.h >>> index ca86c88..43fd14f 100644 >>> --- a/drivers/scsi/megaraid/megaraid_sas.h >>> +++ b/drivers/scsi/megaraid/megaraid_sas.h >>> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT { >>> #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14 >>> #define MR_MAX_MSIX_REG_ARRAY 16 >>> #define MR_RDPQ_MODE_OFFSET 0X0080 >>> +#define MR_CAN_HANDLE_SYNC_CACHE_OFFSET0X0100 >>> + >>> /* >>> * register set for both 1068 and 1078 controllers >>> * structure extended for 1078 registers @@ -2140,6 +2142,7 @@ >>> struct megasas_instance { >>> u8 is_imr; >>> u8 is_rdpq; >>> bool dev_handle; >>> + bool fw_sync_cache_support; >>> }; >>> struct MR_LD_VF_MAP { >>> u32 size; >>> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c >>> b/drivers/scsi/megaraid/megaraid_sas_base.c >>> index 092387f..a4a8e2f 100644 >>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c >>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c >>> @@ -104,6 +104,10 @@ unsigned int scmd_timeout = >MEGASAS_DEFAULT_CMD_TIMEOUT; >>> module_param(scmd_timeout, int, S_IRUGO); >>> MODULE_PARM_DESC(scmd_timeout, "scsi command timeout (10-90s), >>> default 90s. See megasas_reset_timer."); >>> >>> +bool block_sync_cache; >>> +module_param(block_sync_cache, bool, S_IRUGO); >>> +MODULE_PARM_DESC(block_sync_cache, "Block SYNC CACHE by driver >>> +Default: 0(Send it to firmware)"); >>> + >>> MODULE_LICENSE("GPL"); >>> MODULE_VERSION(MEGASAS_VERSION); >>> MODULE_AUTHOR("megaraidlinux@avagotech.com"); >>> @@ -1700,16 +1704,10 @@ megasas_queue_command(struct Scsi_Host >*shost, struct scsi_cmnd *scmd) >>> goto out_done; >>> } >>> >>> - switch (scmd->cmnd[0]) { >>> - case SYNCHRONIZE_CACHE: >>> - /* >>> -* FW takes care of flush cache on its own >>> -* No need to send it down >>> -*/ >>> + if ((scmd->cmnd[0] == SYNCHRONIZE_CACHE) && >>> + (!instance->fw_sync_cache_support)) { >>> scmd->result = DID_OK << 16; >>> goto out_done; >>> - default: >>> - break; >>> } >>> >>> return instance->instancet->build_and_issue_cmd(instance, scmd); >>> diff --git a/drivers/scsi/megaraid/mega
RE: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware
>-Original Message- >From: Tomas Henzl [mailto:the...@redhat.com] >Sent: Monday, October 17, 2016 6:44 PM >To: Sumit Saxena; linux-scsi@vger.kernel.org >Cc: martin.peter...@oracle.com; j...@linux.vnet.ibm.com; >kashyap.de...@broadcom.com >Subject: Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to >firmware > >On 17.10.2016 12:24, Sumit Saxena wrote: >> megaraid_sas driver returns SYNCHRONIZE_CACHE command back to SCSI >> layer without sending it to firmware as firmware takes care of flushing cache. >> This patch will change the driver behavior wrt SYNCHRONIZE_CACHE handling. >> If underlying firmware has support to handle the SYNCHORNIZE_CACHE, >> driver will send it for firmware otherwise complete it back to SCSI >> layer with SUCCESS immediately. >> If Firmware handle SYNCHORNIZE_CACHE for both VD and JBOD >> "canHandleSyncCache" bit in scratch pad register(offset 0x00B4) will >> be set. >> >> This behavior can be controlled via module parameter and user can >> fallback to old behavior of returning SYNCHRONIZE_CACHE by driver only >> without sending it to firmware. >> >> Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> >> Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com> >> --- >> drivers/scsi/megaraid/megaraid_sas.h| 3 +++ >> drivers/scsi/megaraid/megaraid_sas_base.c | 14 ++ >> drivers/scsi/megaraid/megaraid_sas_fusion.c | 3 +++ >> drivers/scsi/megaraid/megaraid_sas_fusion.h | 2 ++ >> 4 files changed, 14 insertions(+), 8 deletions(-) >> >> diff --git a/drivers/scsi/megaraid/megaraid_sas.h >> b/drivers/scsi/megaraid/megaraid_sas.h >> index ca86c88..43fd14f 100644 >> --- a/drivers/scsi/megaraid/megaraid_sas.h >> +++ b/drivers/scsi/megaraid/megaraid_sas.h >> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT { >> #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14 >> #define MR_MAX_MSIX_REG_ARRAY 16 >> #define MR_RDPQ_MODE_OFFSET 0X0080 >> +#define MR_CAN_HANDLE_SYNC_CACHE_OFFSET 0X0100 >> + >> /* >> * register set for both 1068 and 1078 controllers >> * structure extended for 1078 registers @@ -2140,6 +2142,7 @@ struct >> megasas_instance { >> u8 is_imr; >> u8 is_rdpq; >> bool dev_handle; >> +bool fw_sync_cache_support; >> }; >> struct MR_LD_VF_MAP { >> u32 size; >> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c >> b/drivers/scsi/megaraid/megaraid_sas_base.c >> index 092387f..a4a8e2f 100644 >> --- a/drivers/scsi/megaraid/megaraid_sas_base.c >> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c >> @@ -104,6 +104,10 @@ unsigned int scmd_timeout = >> MEGASAS_DEFAULT_CMD_TIMEOUT; module_param(scmd_timeout, int, >> S_IRUGO); MODULE_PARM_DESC(scmd_timeout, "scsi command timeout >> (10-90s), default 90s. See megasas_reset_timer."); >> >> +bool block_sync_cache; >> +module_param(block_sync_cache, bool, S_IRUGO); >> +MODULE_PARM_DESC(block_sync_cache, "Block SYNC CACHE by driver >> +Default: 0(Send it to firmware)"); >> + >> MODULE_LICENSE("GPL"); >> MODULE_VERSION(MEGASAS_VERSION); >> MODULE_AUTHOR("megaraidlinux@avagotech.com"); >> @@ -1700,16 +1704,10 @@ megasas_queue_command(struct Scsi_Host >*shost, struct scsi_cmnd *scmd) >> goto out_done; >> } >> >> -switch (scmd->cmnd[0]) { >> -case SYNCHRONIZE_CACHE: >> -/* >> - * FW takes care of flush cache on its own >> - * No need to send it down >> - */ >> +if ((scmd->cmnd[0] == SYNCHRONIZE_CACHE) && >> +(!instance->fw_sync_cache_support)) { > >Maybe I'm wrong, but isn't the logic inverted? >when fw_sync_cache_support is true it means that there is a flash cache or a >battery and we don't have to send the command down ? > If "instance->fw_sync_cache_support" is set to true, it means driver can send SYNCHRONIZE_CACHE to firmware(firmware has infrastructure to support SYNCHRONIZE_CACHE). If "instance->fw_sync_cache_support" is set to false, it means FW does not support to handle SYNCHRONIZE_CACHE and FW will flush cache during shutdown. >tomash > >> scmd->result = DID_OK << 16; >> goto out_done; >> -default: >> -break; >> } >> >> return instance->instancet->build_and_issue_cmd(instance, scmd); >&
RE: [PATCH 5/7] megaraid_sas: driver version upgrade
>-Original Message- >From: Hannes Reinecke [mailto:h...@suse.de] >Sent: Monday, October 17, 2016 5:05 PM >To: Sumit Saxena; linux-scsi@vger.kernel.org >Cc: martin.peter...@oracle.com; the...@redhat.com; j...@linux.vnet.ibm.com; >kashyap.de...@broadcom.com >Subject: Re: [PATCH 5/7] megaraid_sas: driver version upgrade > >On 10/17/2016 12:24 PM, Sumit Saxena wrote: >> Upgrade driver version. >> >> Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> >> --- >> drivers/scsi/megaraid/megaraid_sas.h | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/scsi/megaraid/megaraid_sas.h >> b/drivers/scsi/megaraid/megaraid_sas.h >> index 43fd14f..1d4de90 100644 >> --- a/drivers/scsi/megaraid/megaraid_sas.h >> +++ b/drivers/scsi/megaraid/megaraid_sas.h >> @@ -35,8 +35,8 @@ >> /* >> * MegaRAID SAS Driver meta data >> */ >> -#define MEGASAS_VERSION "06.811.02.00-rc1" >> -#define MEGASAS_RELDATE "April 12, 2016" >> +#define MEGASAS_VERSION "06.812.06.00-rc1" >> +#define MEGASAS_RELDATE "August 22, 2016" >> >> /* >> * Device IDs >> >Please move this patch to the end of the series. >Otherwise it's impossible to tell if the following patches should be part of the new >version or not. Sure..I will rectify and resend the patches. > >Cheers, > >Hannes >-- >Dr. Hannes Reinecke Teamlead Storage & Networking >h...@suse.de +49 911 74053 688 >SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg >GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (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 3/7] megaraid_sas: Do not fire DCMDs during PCI shutdown/detach
>-Original Message- >From: Hannes Reinecke [mailto:h...@suse.de] >Sent: Monday, October 17, 2016 5:01 PM >To: Sumit Saxena; linux-scsi@vger.kernel.org >Cc: martin.peter...@oracle.com; the...@redhat.com; j...@linux.vnet.ibm.com; >kashyap.de...@broadcom.com >Subject: Re: [PATCH 3/7] megaraid_sas: Do not fire DCMDs during PCI >shutdown/detach > >On 10/17/2016 12:24 PM, Sumit Saxena wrote: >> This patch addresses the issue of driver firing DCMDs in PCI >> shutdown/detach path irrespective of firmware state. >> Driver will check for whether firmware is operational state or not >> before firing DCMDs. If firmware is in unrecoverbale state or does not >> become operational within specfied time, driver will skip firing >> DCMDs. >> >> Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> >> --- >> drivers/scsi/megaraid/megaraid_sas_base.c | 46 >+ >> drivers/scsi/megaraid/megaraid_sas_fusion.c | 9 -- >> 2 files changed, 52 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c >> b/drivers/scsi/megaraid/megaraid_sas_base.c >> index 9ff57de..092387f 100644 >> --- a/drivers/scsi/megaraid/megaraid_sas_base.c >> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c >> @@ -6248,6 +6248,32 @@ fail_reenable_msix: >> #define megasas_resume NULL >> #endif >> >> +static inline int >> +megasas_wait_for_adapter_operational(struct megasas_instance >> +*instance) { >> +int wait_time = MEGASAS_RESET_WAIT_TIME * 2; >> +int i; >> + >> +for (i = 0; i < wait_time; i++) { >> +if (atomic_read(>adprecovery) >> +== MEGASAS_HBA_OPERATIONAL) >> +break; >> + >> +if (!(i % MEGASAS_RESET_NOTICE_INTERVAL)) >> +dev_notice(>pdev->dev, "waiting for >controller reset to >> +finish\n"); >> + >> +msleep(1000); >> +} >> + >> +if (atomic_read(>adprecovery) != >MEGASAS_HBA_OPERATIONAL) { >> +dev_info(>pdev->dev, "%s timed out while waiting for >HBA to recover.\n", >> +__func__); >> +return 1; >> +} >> + >> +return 0; >> +} >> + >> /** >> * megasas_detach_one - PCI hot"un"plug entry point >> * @pdev: PCI device structure >> @@ -6272,9 +6298,18 @@ static void megasas_detach_one(struct pci_dev >*pdev) >> if (instance->fw_crash_state != UNAVAILABLE) >> megasas_free_host_crash_buffer(instance); >> scsi_remove_host(instance->host); >> + >> +msleep(1000); >> +if ((atomic_read(>adprecovery) == >MEGASAS_HW_CRITICAL_ERROR) >> +|| ((atomic_read(>adprecovery) >> +!= MEGASAS_HBA_OPERATIONAL) && >> +megasas_wait_for_adapter_operational(instance))) >> +goto skip_firing_dcmds; >> + >> megasas_flush_cache(instance); >> megasas_shutdown_controller(instance, >MR_DCMD_CTRL_SHUTDOWN); >> >> +skip_firing_dcmds: >> /* cancel the delayed work if this work still in queue*/ >> if (instance->ev != NULL) { >> struct megasas_aen_event *ev = instance->ev; >Why not move the 'msleep' and 'atomic_read' into the call to >megasas_wait_for_adapter_operational? I will rectify this in next version of this patch. >Plus I'm not sure if the unconditional 'msleep' is a good idea here; maybe one >should read 'adprecovery' first and _then_ call msleep if required? Agreed.. I will cleanup this and resend the patch. Thanks, Sumit > >Cheers, > >Hannes >-- >Dr. Hannes Reinecke Teamlead Storage & Networking >h...@suse.de +49 911 74053 688 >SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg >GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (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 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware
>-Original Message- >From: Hannes Reinecke [mailto:h...@suse.de] >Sent: Monday, October 17, 2016 5:04 PM >To: Sumit Saxena; linux-scsi@vger.kernel.org >Cc: martin.peter...@oracle.com; the...@redhat.com; j...@linux.vnet.ibm.com; >kashyap.de...@broadcom.com >Subject: Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to >firmware > >On 10/17/2016 12:24 PM, Sumit Saxena wrote: >> megaraid_sas driver returns SYNCHRONIZE_CACHE command back to SCSI >> layer without sending it to firmware as firmware takes care of flushing cache. >> This patch will change the driver behavior wrt SYNCHRONIZE_CACHE handling. >> If underlying firmware has support to handle the SYNCHORNIZE_CACHE, >> driver will send it for firmware otherwise complete it back to SCSI >> layer with SUCCESS immediately. >> If Firmware handle SYNCHORNIZE_CACHE for both VD and JBOD >> "canHandleSyncCache" bit in scratch pad register(offset 0x00B4) will >> be set. >> >> This behavior can be controlled via module parameter and user can >> fallback to old behavior of returning SYNCHRONIZE_CACHE by driver only >> without sending it to firmware. >> >> Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> >> Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com> >> --- >> drivers/scsi/megaraid/megaraid_sas.h| 3 +++ >> drivers/scsi/megaraid/megaraid_sas_base.c | 14 ++ >> drivers/scsi/megaraid/megaraid_sas_fusion.c | 3 +++ >> drivers/scsi/megaraid/megaraid_sas_fusion.h | 2 ++ >> 4 files changed, 14 insertions(+), 8 deletions(-) >> >> diff --git a/drivers/scsi/megaraid/megaraid_sas.h >> b/drivers/scsi/megaraid/megaraid_sas.h >> index ca86c88..43fd14f 100644 >> --- a/drivers/scsi/megaraid/megaraid_sas.h >> +++ b/drivers/scsi/megaraid/megaraid_sas.h >> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT { >> #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14 >> #define MR_MAX_MSIX_REG_ARRAY 16 >> #define MR_RDPQ_MODE_OFFSET 0X0080 >> +#define MR_CAN_HANDLE_SYNC_CACHE_OFFSET 0X0100 >> + >> /* >> * register set for both 1068 and 1078 controllers >> * structure extended for 1078 registers @@ -2140,6 +2142,7 @@ struct >> megasas_instance { >> u8 is_imr; >> u8 is_rdpq; >> bool dev_handle; >> +bool fw_sync_cache_support; >> }; >> struct MR_LD_VF_MAP { >> u32 size; >> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c >> b/drivers/scsi/megaraid/megaraid_sas_base.c >> index 092387f..a4a8e2f 100644 >> --- a/drivers/scsi/megaraid/megaraid_sas_base.c >> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c >> @@ -104,6 +104,10 @@ unsigned int scmd_timeout = >> MEGASAS_DEFAULT_CMD_TIMEOUT; module_param(scmd_timeout, int, >> S_IRUGO); MODULE_PARM_DESC(scmd_timeout, "scsi command timeout >> (10-90s), default 90s. See megasas_reset_timer."); >> >> +bool block_sync_cache; >> +module_param(block_sync_cache, bool, S_IRUGO); >> +MODULE_PARM_DESC(block_sync_cache, "Block SYNC CACHE by driver >> +Default: 0(Send it to firmware)"); >> + >> MODULE_LICENSE("GPL"); >> MODULE_VERSION(MEGASAS_VERSION); >> MODULE_AUTHOR("megaraidlinux@avagotech.com"); >> @@ -1700,16 +1704,10 @@ megasas_queue_command(struct Scsi_Host >*shost, struct scsi_cmnd *scmd) >> goto out_done; >> } >> >> -switch (scmd->cmnd[0]) { >> -case SYNCHRONIZE_CACHE: >> -/* >> - * FW takes care of flush cache on its own >> - * No need to send it down >> - */ >> +if ((scmd->cmnd[0] == SYNCHRONIZE_CACHE) && >> +(!instance->fw_sync_cache_support)) { >> scmd->result = DID_OK << 16; >> goto out_done; >> -default: >> -break; >> } >> >> return instance->instancet->build_and_issue_cmd(instance, scmd); >> diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c >> b/drivers/scsi/megaraid/megaraid_sas_fusion.c >> index 2159f6a..8237580 100644 >> --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c >> +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c >> @@ -747,6 +747,9 @@ megasas_ioc_init_fusion(struct megasas_instance >*instance) >> ret = 1; >> goto fail_fw_init; >> } >> +if (!block_sync_cache) >> +instance->fw_sync_cache_support = (scratch
[PATCH 5/7] megaraid_sas: driver version upgrade
Upgrade driver version. Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> --- drivers/scsi/megaraid/megaraid_sas.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas.h b/drivers/scsi/megaraid/megaraid_sas.h index 43fd14f..1d4de90 100644 --- a/drivers/scsi/megaraid/megaraid_sas.h +++ b/drivers/scsi/megaraid/megaraid_sas.h @@ -35,8 +35,8 @@ /* * MegaRAID SAS Driver meta data */ -#define MEGASAS_VERSION"06.811.02.00-rc1" -#define MEGASAS_RELDATE"April 12, 2016" +#define MEGASAS_VERSION"06.812.06.00-rc1" +#define MEGASAS_RELDATE"August 22, 2016" /* * Device IDs -- 1.8.3.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 7/7] megaraid_sas: Do not set MPI2_TYPE_CUDA for JBOD FP path for FW which does not support JBOD sequence map
Do not set MPI2_TYPE_CUDA for JBOD fastpath IOs for firmware which does not support JBOD sequence map. CC: sta...@vger.kernel.org Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com> --- drivers/scsi/megaraid/megaraid_sas_fusion.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c b/drivers/scsi/megaraid/megaraid_sas_fusion.c index 8237580..25b7720 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c @@ -2003,6 +2003,8 @@ megasas_build_syspd_fusion(struct megasas_instance *instance, io_request->DevHandle = pd_sync->seq[pd_index].devHandle; pRAID_Context->regLockFlags |= (MR_RL_FLAGS_SEQ_NUM_ENABLE|MR_RL_FLAGS_GRANT_DESTINATION_CUDA); + pRAID_Context->Type = MPI2_TYPE_CUDA; + pRAID_Context->nseg = 0x1; } else if (fusion->fast_path_io) { pRAID_Context->VirtualDiskTgtId = cpu_to_le16(device_id); pRAID_Context->configSeqNum = 0; @@ -2038,12 +2040,10 @@ megasas_build_syspd_fusion(struct megasas_instance *instance, pRAID_Context->timeoutValue = cpu_to_le16((os_timeout_value > timeout_limit) ? timeout_limit : os_timeout_value); - if (fusion->adapter_type == INVADER_SERIES) { - pRAID_Context->Type = MPI2_TYPE_CUDA; - pRAID_Context->nseg = 0x1; + if (fusion->adapter_type == INVADER_SERIES) io_request->IoFlags |= cpu_to_le16(MPI25_SAS_DEVICE0_FLAGS_ENABLED_FAST_PATH); - } + cmd->request_desc->SCSIIO.RequestFlags = (MPI2_REQ_DESCRIPT_FLAGS_FP_IO << MEGASAS_REQ_DESCRIPT_FLAGS_TYPE_SHIFT); -- 1.8.3.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 6/7] MAINTAINERS: Update megaraid maintainers list
Update MEGARAID drivers maintainers list. Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> --- MAINTAINERS | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index f0ee7a6..8b9117f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7612,12 +7612,12 @@ S: Maintained F: drivers/net/wireless/mediatek/mt7601u/ MEGARAID SCSI/SAS DRIVERS -M: Kashyap Desai <kashyap.de...@avagotech.com> -M: Sumit Saxena <sumit.sax...@avagotech.com> -M: Uday Lingala <uday.ling...@avagotech.com> -L: megaraidlinux@avagotech.com +M: Kashyap Desai <kashyap.de...@broadcom.com> +M: Sumit Saxena <sumit.sax...@broadcom.com> +M: Shivasharan S <shivasharan.srikanteshw...@broadcom.com> +L: megaraidlinux@broadcom.com L: linux-scsi@vger.kernel.org -W: http://www.lsi.com +W: http://www.avagotech.com/support/ S: Maintained F: Documentation/scsi/megaraid.txt F: drivers/scsi/megaraid.* -- 1.8.3.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 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware
megaraid_sas driver returns SYNCHRONIZE_CACHE command back to SCSI layer without sending it to firmware as firmware takes care of flushing cache. This patch will change the driver behavior wrt SYNCHRONIZE_CACHE handling. If underlying firmware has support to handle the SYNCHORNIZE_CACHE, driver will send it for firmware otherwise complete it back to SCSI layer with SUCCESS immediately. If Firmware handle SYNCHORNIZE_CACHE for both VD and JBOD "canHandleSyncCache" bit in scratch pad register(offset 0x00B4) will be set. This behavior can be controlled via module parameter and user can fallback to old behavior of returning SYNCHRONIZE_CACHE by driver only without sending it to firmware. Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com> --- drivers/scsi/megaraid/megaraid_sas.h| 3 +++ drivers/scsi/megaraid/megaraid_sas_base.c | 14 ++ drivers/scsi/megaraid/megaraid_sas_fusion.c | 3 +++ drivers/scsi/megaraid/megaraid_sas_fusion.h | 2 ++ 4 files changed, 14 insertions(+), 8 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas.h b/drivers/scsi/megaraid/megaraid_sas.h index ca86c88..43fd14f 100644 --- a/drivers/scsi/megaraid/megaraid_sas.h +++ b/drivers/scsi/megaraid/megaraid_sas.h @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT { #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14 #define MR_MAX_MSIX_REG_ARRAY 16 #define MR_RDPQ_MODE_OFFSET0X0080 +#define MR_CAN_HANDLE_SYNC_CACHE_OFFSET0X0100 + /* * register set for both 1068 and 1078 controllers * structure extended for 1078 registers @@ -2140,6 +2142,7 @@ struct megasas_instance { u8 is_imr; u8 is_rdpq; bool dev_handle; + bool fw_sync_cache_support; }; struct MR_LD_VF_MAP { u32 size; diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index 092387f..a4a8e2f 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -104,6 +104,10 @@ unsigned int scmd_timeout = MEGASAS_DEFAULT_CMD_TIMEOUT; module_param(scmd_timeout, int, S_IRUGO); MODULE_PARM_DESC(scmd_timeout, "scsi command timeout (10-90s), default 90s. See megasas_reset_timer."); +bool block_sync_cache; +module_param(block_sync_cache, bool, S_IRUGO); +MODULE_PARM_DESC(block_sync_cache, "Block SYNC CACHE by driver Default: 0(Send it to firmware)"); + MODULE_LICENSE("GPL"); MODULE_VERSION(MEGASAS_VERSION); MODULE_AUTHOR("megaraidlinux@avagotech.com"); @@ -1700,16 +1704,10 @@ megasas_queue_command(struct Scsi_Host *shost, struct scsi_cmnd *scmd) goto out_done; } - switch (scmd->cmnd[0]) { - case SYNCHRONIZE_CACHE: - /* -* FW takes care of flush cache on its own -* No need to send it down -*/ + if ((scmd->cmnd[0] == SYNCHRONIZE_CACHE) && + (!instance->fw_sync_cache_support)) { scmd->result = DID_OK << 16; goto out_done; - default: - break; } return instance->instancet->build_and_issue_cmd(instance, scmd); diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c b/drivers/scsi/megaraid/megaraid_sas_fusion.c index 2159f6a..8237580 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c @@ -747,6 +747,9 @@ megasas_ioc_init_fusion(struct megasas_instance *instance) ret = 1; goto fail_fw_init; } + if (!block_sync_cache) + instance->fw_sync_cache_support = (scratch_pad_2 & + MR_CAN_HANDLE_SYNC_CACHE_OFFSET) ? 1 : 0; IOCInitMessage = dma_alloc_coherent(>pdev->dev, diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.h b/drivers/scsi/megaraid/megaraid_sas_fusion.h index e3bee04..2857154 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fusion.h +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.h @@ -72,6 +72,8 @@ #define MPI2_SUP_REPLY_POST_HOST_INDEX_OFFSET (0x030C) #define MPI2_REPLY_POST_HOST_INDEX_OFFSET (0x006C) +extern bool block_sync_cache; + /* * Raid context flags */ -- 1.8.3.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 2/7] megaraid_sas: Send correct PhysArm to FW for R1 VD downgrade
This patch fixes the issue of wrong PhysArm was sent to firmware for R1 VD downgrade. Signed-off-by: Kiran Kumar Kasturi <kiran-kumar.kast...@broadcom.com> Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> --- drivers/scsi/megaraid/megaraid_sas_fp.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_fp.c b/drivers/scsi/megaraid/megaraid_sas_fp.c index e413113..f237d00 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fp.c +++ b/drivers/scsi/megaraid/megaraid_sas_fp.c @@ -782,7 +782,8 @@ static u8 mr_spanset_get_phy_params(struct megasas_instance *instance, u32 ld, (raid->regTypeReqOnRead != REGION_TYPE_UNUSED pRAID_Context->regLockFlags = REGION_TYPE_EXCLUSIVE; else if (raid->level == 1) { - pd = MR_ArPdGet(arRef, physArm + 1, map); + physArm = physArm + 1; + pd = MR_ArPdGet(arRef, physArm, map); if (pd != MR_PD_INVALID) *pDevHandle = MR_PdDevHandleGet(pd, map); } @@ -879,7 +880,8 @@ u8 MR_GetPhyParams(struct megasas_instance *instance, u32 ld, u64 stripRow, pRAID_Context->regLockFlags = REGION_TYPE_EXCLUSIVE; else if (raid->level == 1) { /* Get alternate Pd. */ - pd = MR_ArPdGet(arRef, physArm + 1, map); + physArm = physArm + 1; + pd = MR_ArPdGet(arRef, physArm, map); if (pd != MR_PD_INVALID) /* Get dev handle from Pd */ *pDevHandle = MR_PdDevHandleGet(pd, map); -- 1.8.3.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 3/7] megaraid_sas: Do not fire DCMDs during PCI shutdown/detach
This patch addresses the issue of driver firing DCMDs in PCI shutdown/detach path irrespective of firmware state. Driver will check for whether firmware is operational state or not before firing DCMDs. If firmware is in unrecoverbale state or does not become operational within specfied time, driver will skip firing DCMDs. Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> --- drivers/scsi/megaraid/megaraid_sas_base.c | 46 + drivers/scsi/megaraid/megaraid_sas_fusion.c | 9 -- 2 files changed, 52 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index 9ff57de..092387f 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -6248,6 +6248,32 @@ fail_reenable_msix: #define megasas_resume NULL #endif +static inline int +megasas_wait_for_adapter_operational(struct megasas_instance *instance) +{ + int wait_time = MEGASAS_RESET_WAIT_TIME * 2; + int i; + + for (i = 0; i < wait_time; i++) { + if (atomic_read(>adprecovery) + == MEGASAS_HBA_OPERATIONAL) + break; + + if (!(i % MEGASAS_RESET_NOTICE_INTERVAL)) + dev_notice(>pdev->dev, "waiting for controller reset to finish\n"); + + msleep(1000); + } + + if (atomic_read(>adprecovery) != MEGASAS_HBA_OPERATIONAL) { + dev_info(>pdev->dev, "%s timed out while waiting for HBA to recover.\n", + __func__); + return 1; + } + + return 0; +} + /** * megasas_detach_one -PCI hot"un"plug entry point * @pdev: PCI device structure @@ -6272,9 +6298,18 @@ static void megasas_detach_one(struct pci_dev *pdev) if (instance->fw_crash_state != UNAVAILABLE) megasas_free_host_crash_buffer(instance); scsi_remove_host(instance->host); + + msleep(1000); + if ((atomic_read(>adprecovery) == MEGASAS_HW_CRITICAL_ERROR) + || ((atomic_read(>adprecovery) + != MEGASAS_HBA_OPERATIONAL) && + megasas_wait_for_adapter_operational(instance))) + goto skip_firing_dcmds; + megasas_flush_cache(instance); megasas_shutdown_controller(instance, MR_DCMD_CTRL_SHUTDOWN); +skip_firing_dcmds: /* cancel the delayed work if this work still in queue*/ if (instance->ev != NULL) { struct megasas_aen_event *ev = instance->ev; @@ -6388,8 +6423,19 @@ static void megasas_shutdown(struct pci_dev *pdev) struct megasas_instance *instance = pci_get_drvdata(pdev); instance->unload = 1; + + msleep(1000); + + if ((atomic_read(>adprecovery) == MEGASAS_HW_CRITICAL_ERROR) + || ((atomic_read(>adprecovery) + != MEGASAS_HBA_OPERATIONAL) + && megasas_wait_for_adapter_operational(instance))) + goto skip_firing_dcmds; + megasas_flush_cache(instance); megasas_shutdown_controller(instance, MR_DCMD_CTRL_SHUTDOWN); + +skip_firing_dcmds: instance->instancet->disable_intr(instance); megasas_destroy_irqs(instance); diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c b/drivers/scsi/megaraid/megaraid_sas_fusion.c index 61be7ed..2159f6a 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c @@ -2463,12 +2463,15 @@ irqreturn_t megasas_isr_fusion(int irq, void *devp) /* Start collecting crash, if DMA bit is done */ if ((fw_state == MFI_STATE_FAULT) && dma_state) schedule_work(>crash_init); - else if (fw_state == MFI_STATE_FAULT) - schedule_work(>work_init); + else if (fw_state == MFI_STATE_FAULT) { + if (instance->unload == 0) + schedule_work(>work_init); + } } else if (fw_state == MFI_STATE_FAULT) { dev_warn(>pdev->dev, "Iop2SysDoorbellInt" "for scsi%d\n", instance->host->host_no); - schedule_work(>work_init); + if (instance->unload == 0) + schedule_work(>work_init); } } -- 1.8.3.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 1/7] megaraid_sas: For SRIOV enabled firmware, ensure VF driver waits for 30secs before reset
For SRIOV enabled firmware, if there is a OCR(online controller reset) possibility driver set the convert flag to 1, which is not happening if there are outstanding commands even after 180 seconds. As driver does not set convert flag to 1 and still making the OCR to run, VF(Virtual function) driver is directly writing on to the register instead of waiting for 30 seconds. Setting convert flag to 1 will cause VF driver will wait for 30 secs before going for reset. CC: sta...@vger.kernel.org Signed-off-by: Kiran Kumar Kasturi <kiran-kumar.kast...@broadcom.com> Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> --- drivers/scsi/megaraid/megaraid_sas_fusion.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c b/drivers/scsi/megaraid/megaraid_sas_fusion.c index 52d8bbf..61be7ed 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c @@ -2823,6 +2823,7 @@ int megasas_wait_for_outstanding_fusion(struct megasas_instance *instance, dev_err(>pdev->dev, "pending commands remain after waiting, " "will reset adapter scsi%d.\n", instance->host->host_no); + *convert = 1; retval = 1; } out: -- 1.8.3.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 0/7] megaraid_sas: Updates for scsi-next
Sumit Saxena (7): megaraid_sas: For SRIOV enabled firmware, ensure VF driver waits for 30secs before reset megaraid_sas: Send correct PhysArm to FW for R1 VD downgrade megaraid_sas: Do not fire DCMDs during PCI shutdown/detach megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware megaraid_sas: driver version upgrade MAINTAINERS: Update megaraid maintainers list megaraid_sas: Do not set MPI2_TYPE_CUDA for JBOD FP path for FW which does not support JBOD sequence map MAINTAINERS | 10 ++--- drivers/scsi/megaraid/megaraid_sas.h| 7 +++- drivers/scsi/megaraid/megaraid_sas_base.c | 60 + drivers/scsi/megaraid/megaraid_sas_fp.c | 6 ++- drivers/scsi/megaraid/megaraid_sas_fusion.c | 21 ++ drivers/scsi/megaraid/megaraid_sas_fusion.h | 2 + 6 files changed, 82 insertions(+), 24 deletions(-) -- 1.8.3.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 1/3] megaraid_sas: mark symbols static where possible
@@ build_mpt_cmd(struct megasas_instance *instance, struct >megasas_cmd *cmd) > * @cmd: mfi cmd pointer > * > */ >-int >+static int > megasas_issue_dcmd_fusion(struct megasas_instance *instance, > struct megasas_cmd *cmd) > { >@@ -2748,8 +2748,9 @@ megasas_check_reset_fusion(struct megasas_instance >*instance, } > > /* This function waits for outstanding commands on fusion to complete */ -int >megasas_wait_for_outstanding_fusion(struct megasas_instance *instance, >- int reason, int *convert) >+static int >+megasas_wait_for_outstanding_fusion(struct megasas_instance *instance, >+ int reason, int *convert) > { > int i, outstanding, retval = 0, hb_seconds_missed = 0; > u32 fw_state; >@@ -2849,7 +2850,7 @@ void megasas_reset_reply_desc(struct >megasas_instance *instance) > * megasas_refire_mgmt_cmd : Re-fire management commands > * @instance: Controller's soft instance > */ >-void megasas_refire_mgmt_cmd(struct megasas_instance *instance) >+static void megasas_refire_mgmt_cmd(struct megasas_instance *instance) > { > int j; > struct megasas_cmd_fusion *cmd_fusion; @@ -3332,7 +,8 @@ int >megasas_reset_target_fusion(struct scsi_cmnd *scmd) } > > /*SRIOV get other instance in cluster if any*/ -struct megasas_instance >*megasas_get_peer_instance(struct megasas_instance *instance) >+static struct megasas_instance * >+megasas_get_peer_instance(struct megasas_instance *instance) > { > int i; Acked-by: Sumit Saxena <sumit.sax...@broadcom.com> > >-- >2.7.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] megaraid_sas: clean function declarations in megaraid_sas_base.c up
>-Original Message- >From: Baoyou Xie [mailto:baoyou@linaro.org] >Sent: Sunday, September 18, 2016 5:38 PM >To: kashyap.de...@avagotech.com; sumit.sax...@avagotech.com; >uday.ling...@avagotech.com; j...@linux.vnet.ibm.com; >martin.peter...@oracle.com >Cc: megaraidlinux@avagotech.com; linux-scsi@vger.kernel.org; linux- >ker...@vger.kernel.org; a...@arndb.de; baoyou@linaro.org; >xie.bao...@zte.com.cn >Subject: [PATCH] megaraid_sas: clean function declarations in >megaraid_sas_base.c up > >We get a few warnings when building kernel with W=1: >drivers/scsi/megaraid/megaraid_sas_fusion.c:281:1: warning: no previous >prototype for 'megasas_free_cmds_fusion' [-Wmissing-prototypes] >drivers/scsi/megaraid/megaraid_sas_fusion.c:714:1: warning: no previous >prototype for 'megasas_ioc_init_fusion' [-Wmissing-prototypes] > >In fact, these functions are declared in >drivers/scsi/megaraid/megaraid_sas_base.c, but should be declared in a header >file, thus can be recognized in other file. > >So this patch adds the declarations into >drivers/scsi/megaraid/megaraid_sas_fusion.h. > >Signed-off-by: Baoyou Xie <baoyou@linaro.org> >--- > drivers/scsi/megaraid/megaraid_sas_base.c | 13 - > drivers/scsi/megaraid/megaraid_sas_fusion.h | 9 + > 2 files changed, 9 insertions(+), 13 deletions(-) > >diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c >b/drivers/scsi/megaraid/megaraid_sas_base.c >index 2d62d71..b73b6f3 100644 >--- a/drivers/scsi/megaraid/megaraid_sas_base.c >+++ b/drivers/scsi/megaraid/megaraid_sas_base.c >@@ -189,25 +189,12 @@ u32 > megasas_build_and_issue_cmd(struct megasas_instance *instance, > struct scsi_cmnd *scmd); > static void megasas_complete_cmd_dpc(unsigned long instance_addr); -void - >megasas_release_fusion(struct megasas_instance *instance); -int - >megasas_ioc_init_fusion(struct megasas_instance *instance); -void - >megasas_free_cmds_fusion(struct megasas_instance *instance); >-u8 >-megasas_get_map_info(struct megasas_instance *instance); -int - >megasas_sync_map_info(struct megasas_instance *instance); int >wait_and_poll(struct megasas_instance *instance, struct megasas_cmd *cmd, > int seconds); >-void megasas_reset_reply_desc(struct megasas_instance *instance); void >megasas_fusion_ocr_wq(struct work_struct *work); static int >megasas_get_ld_vf_affiliation(struct megasas_instance *instance, >int initial); >-int megasas_check_mpio_paths(struct megasas_instance *instance, >- struct scsi_cmnd *scmd); > > int > megasas_issue_dcmd(struct megasas_instance *instance, struct megasas_cmd >*cmd) diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.h >b/drivers/scsi/megaraid/megaraid_sas_fusion.h >index 80eaee2..3fe730a 100644 >--- a/drivers/scsi/megaraid/megaraid_sas_fusion.h >+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.h >@@ -991,5 +991,14 @@ union desc_value { > } u; > }; > >+void megasas_free_cmds_fusion(struct megasas_instance *instance); int >+megasas_ioc_init_fusion(struct megasas_instance *instance); >+u8 megasas_get_map_info(struct megasas_instance *instance); int >+megasas_sync_map_info(struct megasas_instance *instance); void >+megasas_release_fusion(struct megasas_instance *instance); void >+megasas_reset_reply_desc(struct megasas_instance *instance); int >+megasas_check_mpio_paths(struct megasas_instance *instance, >+struct scsi_cmnd *scmd); >+void megasas_fusion_ocr_wq(struct work_struct *work); > > #endif /* _MEGARAID_SAS_FUSION_H_ */ Acked-by: Sumit Saxena <sumit.sax...@broadcom.com> >-- >2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] scsi: megaraid_sas: add in missing white space in error message text
>-Original Message- >From: Colin King [mailto:colin.k...@canonical.com] >Sent: Monday, September 12, 2016 6:12 PM >To: Kashyap Desai; Sumit Saxena; Uday Lingala; James E . J . Bottomley; >Martin K >. Petersen; megaraidlinux@avagotech.com; linux-scsi@vger.kernel.org >Cc: linux-ker...@vger.kernel.org >Subject: [PATCH] scsi: megaraid_sas: add in missing white space in error >message >text > >From: Colin Ian King <colin.k...@canonical.com> > >A dev_printk message spans two lines and the literal string is missing a >white >space between words. Add the white space. > >Signed-off-by: Colin Ian King <colin.k...@canonical.com> >--- > drivers/scsi/megaraid/megaraid_sas_base.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c >b/drivers/scsi/megaraid/megaraid_sas_base.c >index 2d62d71..c236c4d 100644 >--- a/drivers/scsi/megaraid/megaraid_sas_base.c >+++ b/drivers/scsi/megaraid/megaraid_sas_base.c >@@ -5782,7 +5782,7 @@ static int megasas_probe_one(struct pci_dev *pdev, >>consumer_h); > > if (!instance->producer || !instance->consumer) { >- dev_printk(KERN_DEBUG, >dev, "Failed to >allocate" >+ dev_printk(KERN_DEBUG, >dev, "Failed to >allocate " > "memory for producer, consumer\n"); > goto fail_alloc_dma_buf; > } Acked-by: Sumit Saxena <sumit.sax...@broadcom.com> >-- >2.9.3 -- 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] megaraid_sas: Fix the search of first memory bar
>-Original Message- >From: Christophe JAILLET [mailto:christophe.jail...@wanadoo.fr] >Sent: Sunday, August 21, 2016 1:58 PM >To: kashyap.de...@avagotech.com; sumit.sax...@avagotech.com; >uday.ling...@avagotech.com; j...@linux.vnet.ibm.com; >martin.peter...@oracle.com >Cc: megaraidlinux@avagotech.com; linux-scsi@vger.kernel.org; linux- >ker...@vger.kernel.org; kernel-janit...@vger.kernel.org; Christophe JAILLET >Subject: [PATCH] megaraid_sas: Fix the search of first memory bar > >The 2nd parameter of 'find_first_bit' is the number of bits to search. >In this case, we are passing 'sizeof(unsigned long)' which is likely to be >4. > >It is likely that the number of bits in a long was expected here, so use >BITS_PER_LONG instead. > >Signed-off-by: Christophe JAILLET <christophe.jail...@wanadoo.fr> >--- >Other options are possible: > - 'bar_list' being a 'unsigned long', use __ffs to reduce code verbosity > - PCI_NUM_RESOURCES, which is the maximum number of bits that can be set >by 'pci_select_bars()' >--- > drivers/scsi/megaraid/megaraid_sas_base.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c >b/drivers/scsi/megaraid/megaraid_sas_base.c >index c1ed25adb17e..7d3de811d33c 100644 >--- a/drivers/scsi/megaraid/megaraid_sas_base.c >+++ b/drivers/scsi/megaraid/megaraid_sas_base.c >@@ -5036,7 +5036,7 @@ static int megasas_init_fw(struct megasas_instance >*instance) > > /* Find first memory bar */ > bar_list = pci_select_bars(instance->pdev, IORESOURCE_MEM); >- instance->bar = find_first_bit(_list, sizeof(unsigned long)); >+ instance->bar = find_first_bit(_list, BITS_PER_LONG); > if (pci_request_selected_regions(instance->pdev, 1<bar, > "megasas: LSI")) { > dev_printk(KERN_DEBUG, >pdev->dev, "IO memory >region busy!\n"); Acked by: Sumit Saxena <sumit.sax...@broadcom.com> >-- >2.7.4 > > >--- >L'absence de virus dans ce courrier électronique a été vérifiée par le >logiciel >antivirus Avast. >https://www.avast.com/antivirus -- 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] megaraid_sas: Use memdup_user() rather than duplicating its implementation
>-Original Message- >From: SF Markus Elfring [mailto:elfr...@users.sourceforge.net] >Sent: Sunday, August 21, 2016 2:19 PM >To: linux-scsi@vger.kernel.org; megaraidlinux@avagotech.com; James E. >J. >Bottomley; Kashyap Desai; Martin K. Petersen; Sumit Saxena; Uday Lingala >Cc: LKML; kernel-janit...@vger.kernel.org; Julia Lawall >Subject: [PATCH] megaraid_sas: Use memdup_user() rather than duplicating >its >implementation > >From: Markus Elfring <elfr...@users.sourceforge.net> >Date: Sun, 21 Aug 2016 10:39:04 +0200 > >Reuse existing functionality from memdup_user() instead of keeping >duplicate >source code. > >This issue was detected by using the Coccinelle software. > >Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net> >--- > drivers/scsi/megaraid/megaraid_sas_base.c | 11 +++ > 1 file changed, 3 insertions(+), 8 deletions(-) > >diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c >b/drivers/scsi/megaraid/megaraid_sas_base.c >index c1ed25a..9a2fe4e 100644 >--- a/drivers/scsi/megaraid/megaraid_sas_base.c >+++ b/drivers/scsi/megaraid/megaraid_sas_base.c >@@ -6711,14 +6711,9 @@ static int megasas_mgmt_ioctl_fw(struct file *file, >unsigned long arg) > unsigned long flags; > u32 wait_time = MEGASAS_RESET_WAIT_TIME; > >- ioc = kmalloc(sizeof(*ioc), GFP_KERNEL); >- if (!ioc) >- return -ENOMEM; >- >- if (copy_from_user(ioc, user_ioc, sizeof(*ioc))) { >- error = -EFAULT; >- goto out_kfree_ioc; >- } >+ ioc = memdup_user(user_ioc, sizeof(*ioc)); >+ if (IS_ERR(ioc)) >+ return PTR_ERR(ioc); > > instance = megasas_lookup_instance(ioc->host_no); > if (!instance) { Acked by: Sumit Saxena <sumit.sax...@broadcom.com> >-- >2.9.3 -- 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] megaraid_sas: Do not fire MR_DCMD_PD_LIST_QUERY to controllers which do not support it
There was an issue reported by Lucz Geza on Dell Perc 6i. As per issue reported, megaraid_sas driver goes into an infinite error reporting loop as soon as there is a change in the status of one of the arrays (degrade, resync online etc …). Below are the error logs reported continuously- Jun 25 08:49:30 ns8 kernel: [ 757.757017] megaraid_sas :02:00.0: DCMD failed/not supported by firmware: megasas_get_pd_list 4115 Jun 25 08:49:30 ns8 kernel: [ 757.778017] megaraid_sas :02:00.0: DCMD failed/not supported by firmware: megasas_get_pd_list 4115 Jun 25 08:49:30 ns8 kernel: [ 757.799017] megaraid_sas :02:00.0: DCMD failed/not supported by firmware: megasas_get_pd_list 4115 Jun 25 08:49:30 ns8 kernel: [ 757.820018] megaraid_sas :02:00.0: DCMD failed/not supported by firmware: megasas_get_pd_list 4115 Jun 25 08:49:30 ns8 kernel: [ 757.841018] megaraid_sas :02:00.0: DCMD failed/not supported by firmware: megasas_get_pd_list 4115 This issue is very much specific to controllers which do not support DCMD- MR_DCMD_PD_LIST_QUERY. In case of any hotplugging/rescanning of drives, AEN thread will be scheduled by driver and fire DCMD- MR_DCMD_PD_LIST_QUERY and if this DCMD is failed then driver will fail this event processing and will not go ahead for further events. This will cause infinite loop of same event getting retried infinitely and causing above mentioned logs. Fix for this problem is: not to fire DCMD MR_DCMD_PD_LIST_QUERY for controllers which do not support it and send DCMD SUCCESS status to AEN function so that it can go ahead with other event processing. Reported-by: Lucz Geza <g...@lucz.com> Cc: <sta...@vger.kernel.org> Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> --- drivers/scsi/megaraid/megaraid_sas_base.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index f4b0690..2dab3dc 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -4079,6 +4079,12 @@ megasas_get_pd_list(struct megasas_instance *instance) struct MR_PD_ADDRESS *pd_addr; dma_addr_t ci_h = 0; + if (instance->pd_list_not_supported) { + dev_info(>pdev->dev, "MR_DCMD_PD_LIST_QUERY " + "not supported by firmware\n"); + return ret; + } + cmd = megasas_get_cmd(instance); if (!cmd) { -- 2.4.11 -- 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] Do not fire MR_DCMD_PD_LIST_QUERY to controllers which do not support it
Please ignore this patch. I missed to add megaraid_sas in subject line. I realized after sending. Will be resending with proper subject. Sorry for spamming. > -Original Message- > From: Sumit Saxena [mailto:sumit.sax...@broadcom.com] > Sent: Friday, July 08, 2016 3:51 PM > To: james.bottom...@hansenpartnership.com; martin.peter...@oracle.com > Cc: linux-scsi@vger.kernel.org; kashyap.de...@broadcom.com; > l...@geza.com; sta...@vger.kernel.org; Sumit Saxena > Subject: [PATCH] Do not fire MR_DCMD_PD_LIST_QUERY to controllers which > do not support it > > There was an issue reported by Lucz Geza on Dell Perc 6i. As per issue > reported, > driver goes into an infinite error reporting loop as soon as there is a > change in > the status of one of the arrays (degrade, resync online etc …). > Below are the error logs reported continuously- > > Jun 25 08:49:30 ns8 kernel: [ 757.757017] megaraid_sas :02:00.0: DCMD > failed/not supported by firmware: megasas_get_pd_list 4115 Jun 25 08:49:30 > ns8 kernel: [ 757.778017] megaraid_sas :02:00.0: DCMD failed/not > supported by firmware: megasas_get_pd_list 4115 Jun 25 08:49:30 ns8 > kernel: [ > 757.799017] megaraid_sas :02:00.0: DCMD failed/not supported by > firmware: megasas_get_pd_list 4115 Jun 25 08:49:30 ns8 kernel: [ > 757.820018] > megaraid_sas :02:00.0: DCMD failed/not supported by firmware: > megasas_get_pd_list 4115 Jun 25 08:49:30 ns8 kernel: [ 757.841018] > megaraid_sas :02:00.0: DCMD failed/not supported by firmware: > megasas_get_pd_list 4115 > > This issue is very much specific to controllers which do not support DCMD- > MR_DCMD_PD_LIST_QUERY. > In case of any hotplugging/rescanning of drives, AEN thread will be > scheduled by > driver and fire > DCMD- MR_DCMD_PD_LIST_QUERY and if this DCMD is failed then driver will > fail this event processing and will not go ahead for further events. This > will cause > infinite loop of same event getting retried infinitely and causing above > mentioned logs. > > Fix for this problem is: not to fire DCMD MR_DCMD_PD_LIST_QUERY for > controllers which do not support it and send DCMD SUCCESS status to AEN > function so that it can go ahead with other event processing. > > Reported-by: Lucz Geza <g...@lucz.com> > Cc: <sta...@vger.kernel.org> > Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> > > --- > drivers/scsi/megaraid/megaraid_sas_base.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c > b/drivers/scsi/megaraid/megaraid_sas_base.c > index f4b0690..2dab3dc 100644 > --- a/drivers/scsi/megaraid/megaraid_sas_base.c > +++ b/drivers/scsi/megaraid/megaraid_sas_base.c > @@ -4079,6 +4079,12 @@ megasas_get_pd_list(struct megasas_instance > *instance) > struct MR_PD_ADDRESS *pd_addr; > dma_addr_t ci_h = 0; > > + if (instance->pd_list_not_supported) { > + dev_info(>pdev->dev, "MR_DCMD_PD_LIST_QUERY > " > + "not supported by firmware\n"); > + return ret; > + } > + > cmd = megasas_get_cmd(instance); > > if (!cmd) { > -- > 2.4.11 -- 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] Do not fire MR_DCMD_PD_LIST_QUERY to controllers which do not support it
There was an issue reported by Lucz Geza on Dell Perc 6i. As per issue reported, driver goes into an infinite error reporting loop as soon as there is a change in the status of one of the arrays (degrade, resync online etc …). Below are the error logs reported continuously- Jun 25 08:49:30 ns8 kernel: [ 757.757017] megaraid_sas :02:00.0: DCMD failed/not supported by firmware: megasas_get_pd_list 4115 Jun 25 08:49:30 ns8 kernel: [ 757.778017] megaraid_sas :02:00.0: DCMD failed/not supported by firmware: megasas_get_pd_list 4115 Jun 25 08:49:30 ns8 kernel: [ 757.799017] megaraid_sas :02:00.0: DCMD failed/not supported by firmware: megasas_get_pd_list 4115 Jun 25 08:49:30 ns8 kernel: [ 757.820018] megaraid_sas :02:00.0: DCMD failed/not supported by firmware: megasas_get_pd_list 4115 Jun 25 08:49:30 ns8 kernel: [ 757.841018] megaraid_sas :02:00.0: DCMD failed/not supported by firmware: megasas_get_pd_list 4115 This issue is very much specific to controllers which do not support DCMD- MR_DCMD_PD_LIST_QUERY. In case of any hotplugging/rescanning of drives, AEN thread will be scheduled by driver and fire DCMD- MR_DCMD_PD_LIST_QUERY and if this DCMD is failed then driver will fail this event processing and will not go ahead for further events. This will cause infinite loop of same event getting retried infinitely and causing above mentioned logs. Fix for this problem is: not to fire DCMD MR_DCMD_PD_LIST_QUERY for controllers which do not support it and send DCMD SUCCESS status to AEN function so that it can go ahead with other event processing. Reported-by: Lucz Geza <g...@lucz.com> Cc: <sta...@vger.kernel.org> Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> --- drivers/scsi/megaraid/megaraid_sas_base.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index f4b0690..2dab3dc 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -4079,6 +4079,12 @@ megasas_get_pd_list(struct megasas_instance *instance) struct MR_PD_ADDRESS *pd_addr; dma_addr_t ci_h = 0; + if (instance->pd_list_not_supported) { + dev_info(>pdev->dev, "MR_DCMD_PD_LIST_QUERY " + "not supported by firmware\n"); + return ret; + } + cmd = megasas_get_cmd(instance); if (!cmd) { -- 2.4.11 -- 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] megaraid: add scsi_cmnd NULL check before use
> -Original Message- > From: Finn Thain [mailto:fth...@telegraphics.com.au] > Sent: Friday, May 13, 2016 1:14 PM > To: Sumit Saxena > Cc: Dan Carpenter; Petros Koutoupis; kashyap.de...@avagotech.com; > sumit.sax...@avagotech.com; uday.ling...@avagotech.com; > megaraidlinux@avagotech.com; linux-scsi@vger.kernel.org > Subject: RE: [PATCH] megaraid: add scsi_cmnd NULL check before use > > > On Thu, 12 May 2016, Sumit Saxena wrote: > > > > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > > > > > > Also when I'm doing static analysis people always tell me that "that > > > bug is impossible, trust me." and instead of trusting people I > > > really wish they would just show me the relevant code that prevents > > > it from happening. > > > > Inside megasas_build_io_fusion() function, driver sets "cmd->scmd" > > pointer(SCSI command pointer received from SCSI mid layer). Functions > > called inside megasas_build_io_fusion()(which actually builds frame to > > be sent to firmware) are setting Function type- > > MPI2_FUNCTION_SCSI_IO_REQUEST (or) > MEGASAS_MPI2_FUNCTION_LD_IO_REQUEST. > > So in case Function type set to any one these two, there must be valid > > "cmd->scmd". > > That doesn't show what prevents the bug. It merely shows that the bug does not > always manifest. > > For example, you might check whether anything prevents > megasas_build_io_fusion() from returning before assigning cmd->scmd, like > so: > > 2112 if (sge_count > instance->max_num_sge) { > 2113 dev_err(>pdev->dev, "Error. sge_count (0x%x) > exceeds " > 2114 "max (0x%x) allowed\n", sge_count, > 2115 instance->max_num_sge); > 2116 return 1; > 2117 } > > Another possibility: cmd->io_request->Function is valid yet cmd->scmd is NULL > when seen from the interrupt handler if it intervenes between the two > statements in megasas_return_cmd_fusion(): For IOs returned by above error are not actually fired to firmware so there will be no interrupt handler called for the same. Anyways, if anyone has logs pertaining to the failure, please attach.. > > 180 inline void megasas_return_cmd_fusion(struct megasas_instance *instance, > 181 struct megasas_cmd_fusion *cmd) > 182 { > 183 cmd->scmd = NULL; > 184 memset(cmd->io_request, 0, sizeof(struct > MPI2_RAID_SCSI_IO_REQUEST)); > 185 } > > You might want to confirm that locking always prevents that. > > OTOH, without an actual backtrace, I too might be reluctant to pursue this kind > of speculation. > > -- -- 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] megaraid: add scsi_cmnd NULL check before use
> -Original Message- > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > Sent: Thursday, May 12, 2016 12:05 PM > To: Petros Koutoupis > Cc: Sumit Saxena; Finn Thain; kashyap.de...@avagotech.com; > sumit.sax...@avagotech.com; uday.ling...@avagotech.com; > megaraidlinux@avagotech.com; linux-scsi@vger.kernel.org > Subject: Re: [PATCH] megaraid: add scsi_cmnd NULL check before use > > On Wed, May 11, 2016 at 08:49:51PM -0500, Petros Koutoupis wrote: > > Sumit, > > > > I will resubmit the patch with all the recommendations. Thank you. In > > case you are interested, I have a crash file showcasing the error. I > > can always provide this outside of this mailing thread. > > > > Please send it to the thread. > > To be honest, I totally can't understand this thread. Sumit says it is impossible > and you are saying that you have seen it happen in real life. > Are you using out of tree code or something? What are you doing that is > unexpected? > > I don't see the point of adding a WARN_ON(). NULL derefs normally generate a > pretty clear stack trace already (unless they are caused by memory corruption). > Why are we not just fixing the bugs instead of warning and then crashing. Agree, if there scsi_cmnd is coming as NULL, please attach logs. I will look into them. > > Also when I'm doing static analysis people always tell me that "that bug is > impossible, trust me." and instead of trusting people I really wish they would just > show me the relevant code that prevents it from happening. Inside megasas_build_io_fusion() function, driver sets "cmd->scmd" pointer(SCSI command pointer received from SCSI mid layer). Functions called inside megasas_build_io_fusion()(which actually builds frame to be sent to firmware) are setting Function type- MPI2_FUNCTION_SCSI_IO_REQUEST (or) MEGASAS_MPI2_FUNCTION_LD_IO_REQUEST. So in case Function type set to any one these two, there must be valid "cmd->scmd". Thanks, Sumit > > 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
RE: [PATCH] megaraid: add scsi_cmnd NULL check before use
> -Original Message- > From: Petros Koutoupis [mailto:pet...@petroskoutoupis.com] > Sent: Tuesday, May 10, 2016 2:59 AM > To: Sumit Saxena; Dan Carpenter; Finn Thain > Cc: kashyap.de...@avagotech.com; sumit.sax...@avagotech.com; > uday.ling...@avagotech.com; megaraidlinux@avagotech.com; linux- > s...@vger.kernel.org > Subject: Re: [PATCH] megaraid: add scsi_cmnd NULL check before use > > On Mon, 2016-05-09 at 15:18 +0530, Sumit Saxena wrote: > > > > > > -Original Message- > > > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > > > Sent: Monday, May 09, 2016 1:36 PM > > > To: Finn Thain > > > Cc: Petros Koutoupis; kashyap.de...@avagotech.com; > > > sumit.sax...@avagotech.com; uday.ling...@avagotech.com; > > > megaraidlinux@avagotech.com; linux-scsi@vger.kernel.org > > > Subject: Re: [PATCH] megaraid: add scsi_cmnd NULL check before use > > > > > > Smatch doesn't quite catch it because we check "cmd_fusion->scmd" > > > for > > NULL > > > > > > then assign "scmd_local = cmd_fusion->scmd;" and dereference > > > scmd_local unconditionally... > > > > > > It does catch part of the bug if you have cross function analysis: > > > > > > drivers/scsi/megaraid/megaraid_sas_fusion.c:2318 > > > complete_cmd_fusion() > > > error: we previously assumed 'cmd_fusion->scmd' could be null (see > > line 2281) > > > > > > > > > But that code was from 2010 so I never reported it to the original > > author or the > > > > > > list. > > "cmd_fusion->scmd" should not be NULL if scsi_io_req->Function is set > > to MPI2_FUNCTION_SCSI_IO_REQUEST (OR) > > MEGASAS_MPI2_FUNCTION_LD_IO_REQUES > > (inside these two cases only, cmd_fusion->scmd will be dereferenced). > > If cmd_fusion->scmd is NULL for these "scsi_io_req->Function", that > > will a BUG and should not continue with other commands processing in > > that case. > > > > Sumit, > > To clarify, a detection of cmd_fusion->scmd being NULL with scsi_io_req- > >Function set to MPI2_FUNCTION_SCSI_IO_REQUEST or > MEGASAS_MPI2_FUNCTION_LD_IO_REQUEST should instead trigger a > BUG() and not attempt to iterate to the next command in the list. Thank > you. Petros, WARN_ON() can be used in this case. Upstream may have concerns on using BUG_ON() and also BUG_ON() won't help in this case. In production environment we never encountered this. Thanks, Sumit > > -- > Petros -- 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] megaraid: add scsi_cmnd NULL check before use
> -Original Message- > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > Sent: Monday, May 09, 2016 1:36 PM > To: Finn Thain > Cc: Petros Koutoupis; kashyap.de...@avagotech.com; > sumit.sax...@avagotech.com; uday.ling...@avagotech.com; > megaraidlinux@avagotech.com; linux-scsi@vger.kernel.org > Subject: Re: [PATCH] megaraid: add scsi_cmnd NULL check before use > > Smatch doesn't quite catch it because we check "cmd_fusion->scmd" for NULL > then assign "scmd_local = cmd_fusion->scmd;" and dereference scmd_local > unconditionally... > > It does catch part of the bug if you have cross function analysis: > > drivers/scsi/megaraid/megaraid_sas_fusion.c:2318 complete_cmd_fusion() > error: we previously assumed 'cmd_fusion->scmd' could be null (see line 2281) > > But that code was from 2010 so I never reported it to the original author or the > list. "cmd_fusion->scmd" should not be NULL if scsi_io_req->Function is set to MPI2_FUNCTION_SCSI_IO_REQUEST (OR) MEGASAS_MPI2_FUNCTION_LD_IO_REQUES (inside these two cases only, cmd_fusion->scmd will be dereferenced). If cmd_fusion->scmd is NULL for these "scsi_io_req->Function", that will a BUG and should not continue with other commands processing in that case. > > 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
RE: [PATCH v2] megaraid: Downgrade two success messages to info
> -Original Message- > From: Andy Lutomirski [mailto:l...@kernel.org] > Sent: Tuesday, May 03, 2016 10:55 PM > To: Kashyap Desai; Sumit Saxena; Uday Lingala > Cc: megaraidlinux@avagotech.com; linux-scsi@vger.kernel.org; Andy > Lutomirski > Subject: [PATCH v2] megaraid: Downgrade two success messages to info > > I actually read the error messages in my logs, and successful initialization is not > an error. > > Arguably these log lines could be deleted entirely. > > Signed-off-by: Andy Lutomirski <l...@kernel.org> > --- > > Changes from v2: Remove hunk that didn't belong > > drivers/scsi/megaraid/megaraid_sas_base.c | 2 +- > drivers/scsi/megaraid/megaraid_sas_fusion.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c > b/drivers/scsi/megaraid/megaraid_sas_base.c > index e6ebc7ae2df1..d020919e8085 100644 > --- a/drivers/scsi/megaraid/megaraid_sas_base.c > +++ b/drivers/scsi/megaraid/megaraid_sas_base.c > @@ -5152,7 +5152,7 @@ static int megasas_init_fw(struct megasas_instance > *instance) > > instance->instancet->enable_intr(instance); > > - dev_err(>pdev->dev, "INIT adapter done\n"); > + dev_info(>pdev->dev, "INIT adapter done\n"); > > megasas_setup_jbod_map(instance); > > diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c > b/drivers/scsi/megaraid/megaraid_sas_fusion.c > index 98a848bdfdc2..9375805670a9 100644 > --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c > +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c > @@ -851,7 +851,7 @@ megasas_ioc_init_fusion(struct megasas_instance > *instance) > ret = 1; > goto fail_fw_init; > } > - dev_err(>pdev->dev, "Init cmd success\n"); > + dev_info(>pdev->dev, "Init cmd success\n"); > > ret = 0; Acked-by: Sumit Saxena <sumit.sax...@broadcom.com> > > -- > 2.5.5 -- 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] megaraid_sas: driver version upgrade
Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> --- drivers/scsi/megaraid/megaraid_sas.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas.h b/drivers/scsi/megaraid/megaraid_sas.h index 1784b09..ca86c88 100644 --- a/drivers/scsi/megaraid/megaraid_sas.h +++ b/drivers/scsi/megaraid/megaraid_sas.h @@ -35,8 +35,8 @@ /* * MegaRAID SAS Driver meta data */ -#define MEGASAS_VERSION"06.810.09.00-rc1" -#define MEGASAS_RELDATE"Jan. 28, 2016" +#define MEGASAS_VERSION"06.811.02.00-rc1" +#define MEGASAS_RELDATE"April 12, 2016" /* * Device IDs -- 2.4.11 -- 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] megaraid_sas: task management code optimizations
This patch will do code optmization for task management functions. Below are key changes- 1. Remove reset_device hook as it was not being used and driver was setting this to NULL. 2. Create wrapper functions for task abort and target reset and inside these functions adapter specific calls be made. e.g. fusion adapters support task abort and target reset so task abort and target reset should be issued to fusion adapters only and for MFI adapters, print a message saying feature not supported. Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> --- drivers/scsi/megaraid/megaraid_sas_base.c | 67 +-- 1 file changed, 46 insertions(+), 21 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index 8588202..b84756c 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -2670,17 +2670,6 @@ blk_eh_timer_return megasas_reset_timer(struct scsi_cmnd *scmd) } /** - * megasas_reset_device - Device reset handler entry point - */ -static int megasas_reset_device(struct scsi_cmnd *scmd) -{ - /* -* First wait for all commands to complete -*/ - return megasas_generic_reset(scmd); -} - -/** * megasas_reset_bus_host -Bus & host reset handler entry point */ static int megasas_reset_bus_host(struct scsi_cmnd *scmd) @@ -2702,6 +2691,50 @@ static int megasas_reset_bus_host(struct scsi_cmnd *scmd) } /** + * megasas_task_abort - Issues task abort request to firmware + * (supported only for fusion adapters) + * @scmd: SCSI command pointer + */ +static int megasas_task_abort(struct scsi_cmnd *scmd) +{ + int ret; + struct megasas_instance *instance; + + instance = (struct megasas_instance *)scmd->device->host->hostdata; + + if (instance->ctrl_context) + ret = megasas_task_abort_fusion(scmd); + else { + sdev_printk(KERN_NOTICE, scmd->device, "TASK ABORT not supported\n"); + ret = FAILED; + } + + return ret; +} + +/** + * megasas_reset_target: Issues target reset request to firmware + *(supported only for fusion adapters) + * @scmd: SCSI command pointer + */ +static int megasas_reset_target(struct scsi_cmnd *scmd) +{ + int ret; + struct megasas_instance *instance; + + instance = (struct megasas_instance *)scmd->device->host->hostdata; + + if (instance->ctrl_context) + ret = megasas_reset_target_fusion(scmd); + else { + sdev_printk(KERN_NOTICE, scmd->device, "TARGET RESET not supported\n"); + ret = FAILED; + } + + return ret; +} + +/** * megasas_bios_param - Returns disk geometry for a disk * @sdev: device handle * @bdev: block device @@ -2969,8 +3002,8 @@ static struct scsi_host_template megasas_template = { .slave_alloc = megasas_slave_alloc, .slave_destroy = megasas_slave_destroy, .queuecommand = megasas_queue_command, - .eh_device_reset_handler = megasas_reset_device, - .eh_bus_reset_handler = megasas_reset_bus_host, + .eh_target_reset_handler = megasas_reset_target, + .eh_abort_handler = megasas_task_abort, .eh_host_reset_handler = megasas_reset_bus_host, .eh_timed_out = megasas_reset_timer, .shost_attrs = megaraid_host_attrs, @@ -5598,14 +5631,6 @@ static int megasas_io_attach(struct megasas_instance *instance) host->max_lun = MEGASAS_MAX_LUN; host->max_cmd_len = 16; - /* Fusion only supports host reset */ - if (instance->ctrl_context) { - host->hostt->eh_device_reset_handler = NULL; - host->hostt->eh_bus_reset_handler = NULL; - host->hostt->eh_target_reset_handler = megasas_reset_target_fusion; - host->hostt->eh_abort_handler = megasas_task_abort_fusion; - } - /* * Notify the mid-layer about the new controller */ -- 2.4.11 -- 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] megaraid_sas: call ISR function to clean up pending replies in OCR path
In OCR path, before calling chip reset calls function megasas_wait_for_outstanding_fusion to check reason of OCR. In case of firmware FAULT initiated OCR and DCMD timeout initiated timeout, driver will clear any outstanding reply(yet to be processed by driver) in reply queues before going for chip reset. This code is added to handle a scenario when IO timeout initiated adapter reset and management application initiated adapter reset(by sending command to FAULT firmware) happens simultaneously since adapter reset function is safe-guarded by reset_mutex so only thread will be doing controller reset. Consider IO timeout thread gets mutex and proceeds with adapter reset process after disabling interrupts and by the time managementapplication has fired command to firmware to do adapter reset and the same command is completed by firmware but since interrupts are disabled, driver will not get completion and the same command will be in outstanding/pendingcommands list of driver and refires same command from IO timeout thread after chip reset which will again FAULT firmware and evntually causes kill adapter. Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> --- drivers/scsi/megaraid/megaraid_sas_fusion.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c b/drivers/scsi/megaraid/megaraid_sas_fusion.c index 320c1a0..e2dc205 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c @@ -2762,6 +2762,7 @@ int megasas_wait_for_outstanding_fusion(struct megasas_instance *instance, dev_warn(>pdev->dev, "Found FW in FAULT state," " will reset adapter scsi%d.\n", instance->host->host_no); + megasas_complete_cmd_dpc_fusion((unsigned long)instance); retval = 1; goto out; } @@ -2769,6 +2770,7 @@ int megasas_wait_for_outstanding_fusion(struct megasas_instance *instance, if (reason == MFI_IO_TIMEOUT_OCR) { dev_info(>pdev->dev, "MFI IO is timed out, initiating OCR\n"); + megasas_complete_cmd_dpc_fusion((unsigned long)instance); retval = 1; goto out; } -- 2.4.11 -- 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] megaraid_sas: reduce memory footprints in kdump mode
This patch will reduce memory footprints of megaraid_sas driver when booted in kdump mode. Driver will not allocate memory for optional and perfromance oriented features. Below are key changes done in megaraid_sas driver to do this- 1. Limit Controller's queue depth to 100 in kdump mode. 2. Do not allocate memory for system info buffer and PD info buffer. 3. Disable performance oriented features e.g. Disable RDPQ mode, disable dual queue depth, restrict to single MSI-x vector. Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> --- drivers/scsi/megaraid/megaraid_sas.h| 2 ++ drivers/scsi/megaraid/megaraid_sas_base.c | 48 + drivers/scsi/megaraid/megaraid_sas_fusion.c | 3 ++ 3 files changed, 34 insertions(+), 19 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas.h b/drivers/scsi/megaraid/megaraid_sas.h index fce414a..1784b09 100644 --- a/drivers/scsi/megaraid/megaraid_sas.h +++ b/drivers/scsi/megaraid/megaraid_sas.h @@ -1344,6 +1344,8 @@ struct megasas_ctrl_info { #define SCAN_PD_CHANNEL0x1 #define SCAN_VD_CHANNEL0x2 +#define MEGASAS_KDUMP_QUEUE_DEPTH 100 + enum MR_SCSI_CMD_TYPE { READ_WRITE_LDIO = 0, NON_READ_WRITE_LDIO = 1, diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index e6ebc7a..8588202 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -5761,13 +5761,6 @@ static int megasas_probe_one(struct pci_dev *pdev, break; } - instance->system_info_buf = pci_zalloc_consistent(pdev, - sizeof(struct MR_DRV_SYSTEM_INFO), - >system_info_h); - - if (!instance->system_info_buf) - dev_info(>pdev->dev, "Can't allocate system info buffer\n"); - /* Crash dump feature related initialisation*/ instance->drv_buf_index = 0; instance->drv_buf_alloc = 0; @@ -5777,14 +5770,6 @@ static int megasas_probe_one(struct pci_dev *pdev, spin_lock_init(>crashdump_lock); instance->crash_dump_buf = NULL; - if (!reset_devices) - instance->crash_dump_buf = pci_alloc_consistent(pdev, - CRASH_DMA_BUF_SIZE, - >crash_dump_h); - if (!instance->crash_dump_buf) - dev_err(>dev, "Can't allocate Firmware " - "crash dump DMA buffer\n"); - megasas_poll_wait_aen = 0; instance->flag_ieee = 0; instance->ev = NULL; @@ -5803,11 +5788,26 @@ static int megasas_probe_one(struct pci_dev *pdev, goto fail_alloc_dma_buf; } - instance->pd_info = pci_alloc_consistent(pdev, - sizeof(struct MR_PD_INFO), >pd_info_h); + if (!reset_devices) { + instance->system_info_buf = pci_zalloc_consistent(pdev, + sizeof(struct MR_DRV_SYSTEM_INFO), + >system_info_h); + if (!instance->system_info_buf) + dev_info(>pdev->dev, "Can't allocate system info buffer\n"); + + instance->pd_info = pci_alloc_consistent(pdev, + sizeof(struct MR_PD_INFO), >pd_info_h); - if (!instance->pd_info) - dev_err(>pdev->dev, "Failed to alloc mem for pd_info\n"); + if (!instance->pd_info) + dev_err(>pdev->dev, "Failed to alloc mem for pd_info\n"); + + instance->crash_dump_buf = pci_alloc_consistent(pdev, + CRASH_DMA_BUF_SIZE, + >crash_dump_h); + if (!instance->crash_dump_buf) + dev_err(>dev, "Can't allocate Firmware " + "crash dump DMA buffer\n"); + } /* * Initialize locks and queues @@ -7174,6 +7174,16 @@ static int __init megasas_init(void) int rval; /* +* Booted in kdump kernel, minimize memory footprints by +* disabling few features +*/ + if (reset_devices) { + msix_vectors = 1; + rdpq_enable = 0; + dual_qdepth_disable = 1; + } + + /* * Announce driver version and other information */ pr_info("megasas: %s\n", MEGASAS_VERSION); diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c b/drivers/scsi/megaraid/megaraid_sas_fusion.c index 98a848b..320c1a0 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c @
[PATCH 0/4] megaraid_sas: Updates for scsi-next
This patchset has few small fixes/optimizations. Please consider this for next release. Sumit Saxena (4): megaraid_sas: reduce memory footprints in kdump mode megaraid_sas: call ISR function to clean up pending replies in OCR path megaraid_sas: task management code optimizations megaraid_sas: driver version upgrade drivers/scsi/megaraid/megaraid_sas.h| 6 +- drivers/scsi/megaraid/megaraid_sas_base.c | 115 ++-- drivers/scsi/megaraid/megaraid_sas_fusion.c | 5 ++ 3 files changed, 84 insertions(+), 42 deletions(-) -- 2.4.11 -- 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] megaraid_sas: fix missing { }, nullify kbuff_arr[i] only when necessary
> -Original Message- > From: Colin King [mailto:colin.k...@canonical.com] > Sent: Sunday, March 20, 2016 10:34 PM > To: Kashyap Desai; Sumit Saxena; James Bottomley; Martin K . Petersen; > megaraidlinux@avagotech.com; linux-scsi@vger.kernel.org > Cc: linux-ker...@vger.kernel.org > Subject: [PATCH] megaraid_sas: fix missing { }, nullify kbuff_arr[i] only when > necessary > > From: Colin Ian King <colin.k...@canonical.com> > > Fix missing { } on if statement, this change will nullify kbuff_arr[i] only where > necessary as the code intended. > > detected using static analysis with smatch > > Signed-off-by: Colin Ian King <colin.k...@canonical.com> > --- > drivers/scsi/megaraid/megaraid_sas_base.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c > b/drivers/scsi/megaraid/megaraid_sas_base.c > index 69d375b..e6ebc7a 100644 > --- a/drivers/scsi/megaraid/megaraid_sas_base.c > +++ b/drivers/scsi/megaraid/megaraid_sas_base.c > @@ -6656,12 +6656,13 @@ out: > } > > for (i = 0; i < ioc->sge_count; i++) { > - if (kbuff_arr[i]) > + if (kbuff_arr[i]) { > dma_free_coherent(>pdev->dev, > le32_to_cpu(kern_sge32[i].length), > kbuff_arr[i], > > le32_to_cpu(kern_sge32[i].phys_addr)); > kbuff_arr[i] = NULL; > + } > } > > megasas_return_cmd(instance, cmd); Acked-by: Sumit Saxena <sumit.sax...@broadcom.com> > -- > 2.7.3 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] megaraid_sas: add missing curly braces in ioctl handler
> -Original Message- > From: Arnd Bergmann [mailto:a...@arndb.de] > Sent: Monday, March 14, 2016 8:00 PM > To: martin.peter...@oracle.com; james.bottom...@hansenpartnership.com; > Kashyap Desai; Sumit Saxena; Uday Lingala; James E.J. Bottomley > Cc: linux-scsi@vger.kernel.org; linux-ker...@vger.kernel.org; Arnd Bergmann; > Tomas Henzl; Bjorn Helgaas; megaraidlinux@avagotech.com > Subject: [PATCH 3/3] megaraid_sas: add missing curly braces in ioctl handler > > gcc-6 found a dubious indentation in the megasas_mgmt_fw_ioctl > function: > > drivers/scsi/megaraid/megaraid_sas_base.c: In function > 'megasas_mgmt_fw_ioctl': > drivers/scsi/megaraid/megaraid_sas_base.c:6658:4: warning: statement is > indented as if it were guarded by... [-Wmisleading-indentation] > kbuff_arr[i] = NULL; > ^ > drivers/scsi/megaraid/megaraid_sas_base.c:6653:3: note: ...this 'if' clause, but > it is not >if (kbuff_arr[i]) >^~ > > The code is actually correct, as there is no downside in clearing a NULL pointer > again. > > This clarifies the code and avoids the warning by adding extra curly braces. > > Signed-off-by: Arnd Bergmann <a...@arndb.de> > Fixes: 90dc9d98f01b ("megaraid_sas : MFI MPT linked list corruption fix") > --- > drivers/scsi/megaraid/megaraid_sas_base.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c > b/drivers/scsi/megaraid/megaraid_sas_base.c > index 5c08568ccfbf..2627200d4f82 100644 > --- a/drivers/scsi/megaraid/megaraid_sas_base.c > +++ b/drivers/scsi/megaraid/megaraid_sas_base.c > @@ -6650,12 +6650,13 @@ out: > } > > for (i = 0; i < ioc->sge_count; i++) { > - if (kbuff_arr[i]) > + if (kbuff_arr[i]) { > dma_free_coherent(>pdev->dev, > le32_to_cpu(kern_sge32[i].length), > kbuff_arr[i], > > le32_to_cpu(kern_sge32[i].phys_addr)); > kbuff_arr[i] = NULL; > + } > } > > megasas_return_cmd(instance, cmd); Acked-by: Sumit Saxena <sumit.sax...@broadcom.com> > -- > 2.7.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
[PATCH] megaraid_sas: Don't issue kill adapter for MFI controllers in case of PD list DCMD failure
There are few MFI adapters which do not support MR_DCMD_PD_LIST_QUERY so if MFI adapters fail this DCMD, it should not be considered as FATAL and driver should not issue kill adapter and set per controller's instance variable- pd_list_not_supported so that same variable can be used inside functions- slave_alloc and slave_configure to allow firmware scan. Killing adapter because of DCMD failure when this DCMD is not supported causes driver's probe getting failed. This issue got introduced because of below commit when MFI IO timeout handling was introduced- 6d40afb megaraid_sas: MFI IO timeout handling Killing adapter in case of this DCMD failure should be limited to Fusion adapters only. Per controller's instance variable allow_fw_scan is removed as pd_list_not_supported better reflect the purpose. Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> --- drivers/scsi/megaraid/megaraid_sas.h | 2 +- drivers/scsi/megaraid/megaraid_sas_base.c | 14 ++ 2 files changed, 11 insertions(+), 5 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas.h b/drivers/scsi/megaraid/megaraid_sas.h index 4484e63..fce414a 100644 --- a/drivers/scsi/megaraid/megaraid_sas.h +++ b/drivers/scsi/megaraid/megaraid_sas.h @@ -2097,7 +2097,7 @@ struct megasas_instance { u8 UnevenSpanSupport; u8 supportmax256vd; - u8 allow_fw_scan; + u8 pd_list_not_supported; u16 fw_supported_vd_count; u16 fw_supported_pd_count; diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index 5c08568..69d375b 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -1838,7 +1838,7 @@ static int megasas_slave_configure(struct scsi_device *sdev) struct megasas_instance *instance; instance = megasas_lookup_instance(sdev->host->host_no); - if (instance->allow_fw_scan) { + if (instance->pd_list_not_supported) { if (sdev->channel < MEGASAS_MAX_PD_CHANNELS && sdev->type == TYPE_DISK) { pd_index = (sdev->channel * MEGASAS_MAX_DEV_PER_CHANNEL) + @@ -1874,7 +1874,8 @@ static int megasas_slave_alloc(struct scsi_device *sdev) pd_index = (sdev->channel * MEGASAS_MAX_DEV_PER_CHANNEL) + sdev->id; - if ((instance->allow_fw_scan || instance->pd_list[pd_index].driveState == + if ((instance->pd_list_not_supported || + instance->pd_list[pd_index].driveState == MR_PD_STATE_SYSTEM)) { goto scan_target; } @@ -4087,7 +4088,13 @@ megasas_get_pd_list(struct megasas_instance *instance) switch (ret) { case DCMD_FAILED: - megaraid_sas_kill_hba(instance); + dev_info(>pdev->dev, "MR_DCMD_PD_LIST_QUERY " + "failed/not supported by firmware\n"); + + if (instance->ctrl_context) + megaraid_sas_kill_hba(instance); + else + instance->pd_list_not_supported = 1; break; case DCMD_TIMEOUT: @@ -5034,7 +5041,6 @@ static int megasas_init_fw(struct megasas_instance *instance) case PCI_DEVICE_ID_DELL_PERC5: default: instance->instancet = _instance_template_xscale; - instance->allow_fw_scan = 1; break; } -- 2.4.3 -- 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: megaraid_sas: Task management support
> -Original Message- > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > Sent: Monday, February 08, 2016 11:52 PM > To: sumit.sax...@avagotech.com > Cc: megaraidlinux@avagotech.com; linux-scsi@vger.kernel.org > Subject: re: megaraid_sas: Task management support > > Hello Sumit Saxena, > > The patch 31796fa184ee: "megaraid_sas: Task management support" from Jan > 28, 2016, leads to the following static checker warning: > > drivers/scsi/megaraid/megaraid_sas_base.c:1788 > megasas_update_sdev_properties() > warn: if statement not indented > > drivers/scsi/megaraid/megaraid_sas_base.c > 1781 } else { > 1782 device_id = ((sdev->channel % 2) * > MEGASAS_MAX_DEV_PER_CHANNEL) > 1783 + sdev->id; > 1784 local_map_ptr = fusion->ld_drv_map[(instance->map_id & 1)]; > 1785 ld = MR_TargetIdToLdGet(device_id, local_map_ptr); > 1786 raid = MR_LdRaidGet(ld, local_map_ptr); > 1787 > 1788 if (raid->capability.ldPiMode == > MR_PROT_INFO_TYPE_CONTROLLER) > 1789 blk_queue_update_dma_alignment(sdev->request_queue, 0x7); > > It looks like the code is correct but the patch just deleted a tab accidentally. Yes code is correct, tab got deleted accidentally. > > 1790 mr_device_priv_data->is_tm_capable = > 1791 raid->capability.tmCapable; > 1792 } > > 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
RE: [PATCH] megaraid: fix null pointer check in megasas_detach_one().
> -Original Message- > From: Martin K. Petersen [mailto:martin.peter...@oracle.com] > Sent: Tuesday, February 02, 2016 7:24 AM > To: Maurizio Lombardi > Cc: sumit.sax...@avagotech.com; kashyap.de...@avagotech.com; > uday.ling...@avagotech.com; linux-scsi@vger.kernel.org; > jbottom...@parallels.com; the...@redhat.com > Subject: Re: [PATCH] megaraid: fix null pointer check in megasas_detach_one(). > > > "Maurizio" == Maurizio Lombardiwrites: > > Maurizio> The pd_seq_sync pointer can't be NULL, we have to check its > Maurizio> entries instead. > > Sumit? Martin, Patch looks good but it needs to be rebased with latest repo as very recently you have checked in few megaraid_sas patches and there are two critical patches for megaraid_sas are yet pending. Once we get status of those two outstanding patches, I will ask submitter to rebase and send this patch again or I will be resending. Thanks, Sumit > > -- > Martin K. PetersenOracle 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
[PATCH v2 04/15] megaraid_sas: Task management support
This patch will add task management(TM) support for SCSI commands in megaraid_sas driver. Added TM functions are below- 1)Task abort 2)Target reset Below are few key points- 1. Currently, megaraid_sas driver performs Controller reset when any IO times out. With these TM support added in driver, in case of IO timeout task abort and target reset will be tried to recover timed out IO. If both fails to recover IO, then Controller reset will be called. If the TM request times out, fail the TM and escalate to the next level(Controller reset). 2. mr_device_priv_data will be allocated for all generation of controller, but is_tm_capable flag will never be set for older controllers (prior to Invader series) as firmware support is not available for T.M functionality. 3. whichever firmware is capable for TM will set is_tm_capable flag in firmware API, which will be used by Driver to pass TM frame to firmware or return back to OS as Failure to escalate next level of Error handling. Additionally, Tomas Henzl's feedback has been accomodated in this patch- return MFI frame used for task management(TM) in case of TM timeout and error cases. Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com> Signed-off-by: Kashyap Desai <kashyap.de...@avagotech.com> --- drivers/scsi/megaraid/megaraid_sas.h| 13 + drivers/scsi/megaraid/megaraid_sas_base.c | 60 +++- drivers/scsi/megaraid/megaraid_sas_fusion.c | 474 +++- drivers/scsi/megaraid/megaraid_sas_fusion.h | 117 ++- 4 files changed, 646 insertions(+), 18 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas.h b/drivers/scsi/megaraid/megaraid_sas.h index dcc6ff8..0fcb156 100644 --- a/drivers/scsi/megaraid/megaraid_sas.h +++ b/drivers/scsi/megaraid/megaraid_sas.h @@ -1520,6 +1520,15 @@ union megasas_frame { u8 raw_bytes[64]; }; +/** + * struct MR_PRIV_DEVICE - sdev private hostdata + * @is_tm_capable: firmware managed tm_capable flag + * @tm_busy: TM request is in progress + */ +struct MR_PRIV_DEVICE { + bool is_tm_capable; + bool tm_busy; +}; struct megasas_cmd; union megasas_evt_class_locale { @@ -2073,4 +2082,8 @@ void megasas_return_mfi_mpt_pthr(struct megasas_instance *instance, int megasas_cmd_type(struct scsi_cmnd *cmd); void megasas_setup_jbod_map(struct megasas_instance *instance); +void megasas_update_sdev_properties(struct scsi_device *sdev); +int megasas_reset_fusion(struct Scsi_Host *shost, int reason); +int megasas_task_abort_fusion(struct scsi_cmnd *scmd); +int megasas_reset_target_fusion(struct scsi_cmnd *scmd); #endif /*LSI_MEGARAID_SAS_H */ diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index 380c627..57cf4e3 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -189,7 +189,6 @@ int wait_and_poll(struct megasas_instance *instance, struct megasas_cmd *cmd, int seconds); void megasas_reset_reply_desc(struct megasas_instance *instance); -int megasas_reset_fusion(struct Scsi_Host *shost, int iotimeout); void megasas_fusion_ocr_wq(struct work_struct *work); static int megasas_get_ld_vf_affiliation(struct megasas_instance *instance, int initial); @@ -1645,6 +1644,7 @@ megasas_queue_command(struct Scsi_Host *shost, struct scsi_cmnd *scmd) { struct megasas_instance *instance; unsigned long flags; + struct MR_PRIV_DEVICE *mr_device_priv_data; instance = (struct megasas_instance *) scmd->device->host->hostdata; @@ -1681,11 +1681,24 @@ megasas_queue_command(struct Scsi_Host *shost, struct scsi_cmnd *scmd) return 0; } + mr_device_priv_data = scmd->device->hostdata; + if (!mr_device_priv_data) { + spin_unlock_irqrestore(>hba_lock, flags); + scmd->result = DID_NO_CONNECT << 16; + scmd->scsi_done(scmd); + return 0; + } + if (instance->adprecovery != MEGASAS_HBA_OPERATIONAL) { spin_unlock_irqrestore(>hba_lock, flags); return SCSI_MLQUEUE_HOST_BUSY; } + if (mr_device_priv_data->tm_busy) { + spin_unlock_irqrestore(>hba_lock, flags); + return SCSI_MLQUEUE_DEVICE_BUSY; + } + spin_unlock_irqrestore(>hba_lock, flags); scmd->result = 0; @@ -1736,27 +1749,39 @@ static struct megasas_instance *megasas_lookup_instance(u16 host_no) } /* -* megasas_set_dma_alignment - Set DMA alignment for PI enabled VD +* megasas_update_sdev_properties - Update sdev structure based on controller's FW capabilities * * @sdev: OS provided scsi device * * Returns void */ -static void megasas_set_dma_alignment(struct scsi_device *sdev) +void megasas_update_sdev_properties(struct scsi_device *sdev) { +
[PATCH v2 01/15] megaraid_sas: Do not allow PCI access during OCR
This patch will do synhronization between OCR function and AEN function using "reset_mutex" lock. reset_mutex will be acquire only in first half of the AEN function which issue DCMD. Second half of the function calls SCSI API (scsi_add_device/scsi_remove_device) should be out of reset_mutex to avoid deadlock between scsi_eh thread and Driver. During chip reset(inside OCR function), there should not be any PCI access and AEN function (which is called in delayed context) may be firirng DCMDs(doing PCI writes) when chip reset is happening in parallel which will cause FW fault. This patch will solve the problem by making AEN thread and OCR thread mutually exclusive. There are no changes in this patch from last time sent patch. Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com> Signed-off-by: Kashyap Desai <kashyap.de...@avagotech.com> Reviewed-by: Tomas Henzl <the...@redhat.com> --- drivers/scsi/megaraid/megaraid_sas.h | 2 + drivers/scsi/megaraid/megaraid_sas_base.c | 254 ++ 2 files changed, 82 insertions(+), 174 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas.h b/drivers/scsi/megaraid/megaraid_sas.h index c0f7c8c..ef4ff03 100644 --- a/drivers/scsi/megaraid/megaraid_sas.h +++ b/drivers/scsi/megaraid/megaraid_sas.h @@ -1083,6 +1083,8 @@ struct megasas_ctrl_info { #define VD_EXT_DEBUG 0 +#define SCAN_PD_CHANNEL0x1 +#define SCAN_VD_CHANNEL0x2 enum MR_SCSI_CMD_TYPE { READ_WRITE_LDIO = 0, diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index 97a1c1c..9650487 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -5476,7 +5476,6 @@ static int megasas_probe_one(struct pci_dev *pdev, spin_lock_init(>hba_lock); spin_lock_init(>completion_lock); - mutex_init(>aen_mutex); mutex_init(>reset_mutex); /* @@ -6442,10 +6441,10 @@ static int megasas_mgmt_ioctl_aen(struct file *file, unsigned long arg) } spin_unlock_irqrestore(>hba_lock, flags); - mutex_lock(>aen_mutex); + mutex_lock(>reset_mutex); error = megasas_register_aen(instance, aen.seq_num, aen.class_locale_word); - mutex_unlock(>aen_mutex); + mutex_unlock(>reset_mutex); return error; } @@ -6647,6 +6646,7 @@ megasas_aen_polling(struct work_struct *work) int i, j, doscan = 0; u32 seq_num, wait_time = MEGASAS_RESET_WAIT_TIME; int error; + u8 dcmd_ret = 0; if (!instance) { printk(KERN_ERR "invalid instance!\n"); @@ -6659,16 +6659,7 @@ megasas_aen_polling(struct work_struct *work) wait_time = MEGASAS_ROUTINE_WAIT_TIME_VF; /* Don't run the event workqueue thread if OCR is running */ - for (i = 0; i < wait_time; i++) { - if (instance->adprecovery == MEGASAS_HBA_OPERATIONAL) - break; - if (!(i % MEGASAS_RESET_NOTICE_INTERVAL)) { - dev_notice(>pdev->dev, "%s waiting for " - "controller reset to finish for scsi%d\n", - __func__, instance->host->host_no); - } - msleep(1000); - } + mutex_lock(>reset_mutex); instance->ev = NULL; host = instance->host; @@ -6676,212 +6667,127 @@ megasas_aen_polling(struct work_struct *work) megasas_decode_evt(instance); switch (le32_to_cpu(instance->evt_detail->code)) { - case MR_EVT_PD_INSERTED: - if (megasas_get_pd_list(instance) == 0) { - for (i = 0; i < MEGASAS_MAX_PD_CHANNELS; i++) { - for (j = 0; - j < MEGASAS_MAX_DEV_PER_CHANNEL; - j++) { - - pd_index = - (i * MEGASAS_MAX_DEV_PER_CHANNEL) + j; - - sdev1 = scsi_device_lookup(host, i, j, 0); - - if (instance->pd_list[pd_index].driveState - == MR_PD_STATE_SYSTEM) { - if (!sdev1) - scsi_add_device(host, i, j, 0); - - if (sdev1) - scsi_device_put(sdev1); - } - } - } - } - doscan = 0; - break; + case MR_EVT_PD_INSERTED: case MR_EVT_PD_REMOVED: -
[PATCH v2 02/15] megaraid_sas: MFI IO timeout handling
This patch will do proper error handling for DCMD timeout and failed cases for fusion adapters. Below are few key design points- 1. For MFI adapters, in case of DCMD timeout(DCMD which must return SUCCESS) driver will call kill adapter. 2. What action needs to be taken in case of DCMD timeout is decided by function dcmd_timeout_ocr_possible(). DCMD timeout causing OCR is applicable to below DCMDs- MR_DCMD_PD_LIST_QUERY MR_DCMD_LD_GET_LIST MR_DCMD_LD_LIST_QUERY MR_DCMD_CTRL_SET_CRASH_DUMP_PARAMS MR_DCMD_SYSTEM_PD_MAP_GET_INFO(for non pended DCMD) MR_DCMD_LD_MAP_GET_INFO(for non pended DCMD) 3. If DCMD fails from Driver init path, there are certain DCMD which is must to be return SUCCESS. If those DCMD fails, driver bail out load. For optional DCMD like pd_info etc, driver continue without executing certain functionality. There are no changes in this patch from last time sent patch. Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com> Signed-off-by: Kashyap Desai <kashyap.de...@avagotech.com> Reviewed-by: Tomas Henzl <the...@redhat.com> --- drivers/scsi/megaraid/megaraid_sas.h| 22 +- drivers/scsi/megaraid/megaraid_sas_base.c | 372 +--- drivers/scsi/megaraid/megaraid_sas_fusion.c | 54 ++-- 3 files changed, 338 insertions(+), 110 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas.h b/drivers/scsi/megaraid/megaraid_sas.h index ef4ff03..dcc6ff8 100644 --- a/drivers/scsi/megaraid/megaraid_sas.h +++ b/drivers/scsi/megaraid/megaraid_sas.h @@ -170,6 +170,7 @@ /* Driver internal */ #define DRV_DCMD_POLLED_MODE 0x1 +#define DRV_DCMD_SKIP_REFIRE 0x2 /* * Definition for cmd_status @@ -1093,6 +1094,11 @@ enum MR_SCSI_CMD_TYPE { NON_READ_WRITE_SYSPDIO = 3, }; +enum DCMD_TIMEOUT_ACTION { + INITIATE_OCR = 0, + KILL_ADAPTER = 1, + IGNORE_TIMEOUT = 2, +}; /* Frame Type */ #define IO_FRAME 0 #define PTHRU_FRAME1 @@ -1139,6 +1145,7 @@ enum MR_SCSI_CMD_TYPE { #define MFI_OB_INTR_STATUS_MASK0x0002 #define MFI_POLL_TIMEOUT_SECS 60 +#define MFI_IO_TIMEOUT_SECS180 #define MEGASAS_SRIOV_HEARTBEAT_INTERVAL_VF(5 * HZ) #define MEGASAS_OCR_SETTLE_TIME_VF (1000 * 30) #define MEGASAS_ROUTINE_WAIT_TIME_VF 300 @@ -1918,7 +1925,7 @@ struct megasas_instance_template { u32 (*init_adapter)(struct megasas_instance *); u32 (*build_and_issue_cmd) (struct megasas_instance *, struct scsi_cmnd *); - void (*issue_dcmd) (struct megasas_instance *instance, + int (*issue_dcmd)(struct megasas_instance *instance, struct megasas_cmd *cmd); }; @@ -2016,6 +2023,19 @@ struct megasas_mgmt_info { int max_index; }; +enum MEGASAS_OCR_CAUSE { + FW_FAULT_OCR= 0, + SCSIIO_TIMEOUT_OCR = 1, + MFI_IO_TIMEOUT_OCR = 2, +}; + +enum DCMD_RETURN_STATUS { + DCMD_SUCCESS= 0, + DCMD_TIMEOUT= 1, + DCMD_FAILED = 2, + DCMD_NOT_FIRED = 3, +}; + u8 MR_BuildRaidContext(struct megasas_instance *instance, struct IO_REQUEST_INFO *io_info, diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index 9650487..380c627 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -196,11 +196,12 @@ static int megasas_get_ld_vf_affiliation(struct megasas_instance *instance, int megasas_check_mpio_paths(struct megasas_instance *instance, struct scsi_cmnd *scmd); -void +int megasas_issue_dcmd(struct megasas_instance *instance, struct megasas_cmd *cmd) { instance->instancet->fire_cmd(instance, cmd->frame_phys_addr, 0, instance->reg_set); + return 0; } /** @@ -983,25 +984,20 @@ extern struct megasas_instance_template megasas_instance_template_fusion; int megasas_issue_polled(struct megasas_instance *instance, struct megasas_cmd *cmd) { - int seconds; struct megasas_header *frame_hdr = >frame->hdr; - frame_hdr->cmd_status = MFI_CMD_STATUS_POLL_MODE; + frame_hdr->cmd_status = MFI_STAT_INVALID_STATUS; frame_hdr->flags |= cpu_to_le16(MFI_FRAME_DONT_POST_IN_REPLY_QUEUE); - /* -* Issue the frame using inbound queue port -*/ - instance->instancet->issue_dcmd(instance, cmd); + if ((instance->adprecovery == MEGASAS_HW_CRITICAL_ERROR) || + (instance->instancet->issue_dcmd(instance, cmd))) { + dev_err(>pdev->dev, "Failed from %s %d\n", + __func__, __LINE__); + return DCMD_NOT_FIRED; + } -
[PATCH v2 03/15] megaraid_sas: Syncing request flags macro names with firmware
There are no changes in this patch from last time sent patch. Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com> Reviewed-by: Tomas Henzl <the...@redhat.com> --- drivers/scsi/megaraid/megaraid_sas_fusion.c | 6 +++--- drivers/scsi/megaraid/megaraid_sas_fusion.h | 3 ++- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c b/drivers/scsi/megaraid/megaraid_sas_fusion.c index 6e48707..1dc4537 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c @@ -1666,7 +1666,7 @@ megasas_build_ldio_fusion(struct megasas_instance *instance, local_map_ptr, start_lba_lo); io_request->Function = MPI2_FUNCTION_SCSI_IO_REQUEST; cmd->request_desc->SCSIIO.RequestFlags = - (MPI2_REQ_DESCRIPT_FLAGS_HIGH_PRIORITY + (MPI2_REQ_DESCRIPT_FLAGS_FP_IO << MEGASAS_REQ_DESCRIPT_FLAGS_TYPE_SHIFT); if (fusion->adapter_type == INVADER_SERIES) { if (io_request->RaidContext.regLockFlags == @@ -1799,7 +1799,7 @@ static void megasas_build_ld_nonrw_fusion(struct megasas_instance *instance, /* build request descriptor */ cmd->request_desc->SCSIIO.RequestFlags = - (MPI2_REQ_DESCRIPT_FLAGS_HIGH_PRIORITY << + (MPI2_REQ_DESCRIPT_FLAGS_FP_IO << MEGASAS_REQ_DESCRIPT_FLAGS_TYPE_SHIFT); cmd->request_desc->SCSIIO.DevHandle = devHandle; @@ -1905,7 +1905,7 @@ megasas_build_syspd_fusion(struct megasas_instance *instance, cpu_to_le16(MPI25_SAS_DEVICE0_FLAGS_ENABLED_FAST_PATH); } cmd->request_desc->SCSIIO.RequestFlags = - (MPI2_REQ_DESCRIPT_FLAGS_HIGH_PRIORITY << + (MPI2_REQ_DESCRIPT_FLAGS_FP_IO << MEGASAS_REQ_DESCRIPT_FLAGS_TYPE_SHIFT); } } diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.h b/drivers/scsi/megaraid/megaraid_sas_fusion.h index 473005c..a9e10c4 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fusion.h +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.h @@ -176,7 +176,8 @@ enum REGION_TYPE { #define MPI2_SCSIIO_EEDPFLAGS_CHECK_GUARD (0x0100) #define MPI2_SCSIIO_EEDPFLAGS_INSERT_OP (0x0004) #define MPI2_FUNCTION_SCSI_IO_REQUEST (0x00) /* SCSI IO */ -#define MPI2_REQ_DESCRIPT_FLAGS_HIGH_PRIORITY (0x06) +#define MPI2_REQ_DESCRIPT_FLAGS_HIGH_PRIORITY (0x03) +#define MPI2_REQ_DESCRIPT_FLAGS_FP_IO (0x06) #define MPI2_REQ_DESCRIPT_FLAGS_SCSI_IO (0x00) #define MPI2_SGE_FLAGS_64_BIT_ADDRESSING(0x02) #define MPI2_SCSIIO_CONTROL_WRITE (0x0100) -- 1.8.3.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 00/15] megaraid_sas: Updates for scsi-next
Changes between v1 and v2: -Addressed comments provided by Tomas Henzl. -Return MFI frame used for task management(TM) in case of TM timeout and error cases. -Fixed few error handling cases inside functions- megasas_alloc_cmdlist_fusion() and megasas_alloc_cmds_fusion(), fix typo- disable(old- disbale) in rdpq_enable module parameter's description, modify print to reflect RDPQ support statement correctly. -Used atomic_inc_return instead of using atomic_read() and atomic_inc() separately inside function- megasas_build_and_issue_cmd_fusion(). -Removed the un-necessary code of throttling of IOs against can_queue inside function- megasas_build_and_issue_cmd_fusion() as SCSI mid layer will anyways does this. -Removed redundant checks when label- kill_hba_and_failed is being called. -Removed one patch- *[PATCH 15/15] megaraid_sas: SPERC boot driver reorder* from v2 patchset as that was rejected. -Added one new patch for driver version upgrade. Sumit Saxena (15): megaraid_sas: Do not allow PCI access during OCR megaraid_sas: MFI IO timeout handling megaraid_sas: Syncing request flags macro names with firmware megaraid_sas: Task management support megaraid_sas: Update device Queue depth based on interface type megaraid_sas: Fastpath region lock bypass megaraid_sas: Reply Descriptor Post Queue(RDPQ) support megaraid_sas: Code optimization build_and_issue_cmd return-type megaraid_sas: Dual Queue depth support megaraid_sas: IO throttling support megaraid_sas: Make adprecovery variable atomic megaraid_sas: MFI adapter's OCR changes megaraid_sas: Introduce module parameter for SCSI command-timeout megaraid_sas: SPERC OCR changes megaraid_sas: driver version upgrade drivers/scsi/megaraid/megaraid_sas.h| 338 +++- drivers/scsi/megaraid/megaraid_sas_base.c | 1034 ++ drivers/scsi/megaraid/megaraid_sas_fp.c |2 + drivers/scsi/megaraid/megaraid_sas_fusion.c | 1244 --- drivers/scsi/megaraid/megaraid_sas_fusion.h | 136 ++- 5 files changed, 2027 insertions(+), 727 deletions(-) -- 1.8.3.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 06/15] megaraid_sas: Fastpath region lock bypass
Firmware will fill per LD data to tell driver that particular LD supports Region lock bypass or not. If yes, then Driver will send non FP LDIO to region lock bypass FIFO. With this change in driver, firmware will optimize certain code to improve performance. There are no changes in this patch from last time sent patch. Signed-off-by: Kashyap Desai <kashyap.de...@avagotech.com> Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com> Reviewed-by: Tomas Henzl <the...@redhat.com> --- drivers/scsi/megaraid/megaraid_sas.h| 8 ++-- drivers/scsi/megaraid/megaraid_sas_fp.c | 2 ++ drivers/scsi/megaraid/megaraid_sas_fusion.c | 6 -- drivers/scsi/megaraid/megaraid_sas_fusion.h | 8 +--- 4 files changed, 17 insertions(+), 7 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas.h b/drivers/scsi/megaraid/megaraid_sas.h index 773fc54..01135be 100644 --- a/drivers/scsi/megaraid/megaraid_sas.h +++ b/drivers/scsi/megaraid/megaraid_sas.h @@ -1528,7 +1528,9 @@ union megasas_sgl_frame { typedef union _MFI_CAPABILITIES { struct { #if defined(__BIG_ENDIAN_BITFIELD) - u32 reserved:23; + u32 reserved:21; + u32 support_fp_rlbypass:1; + u32 support_vfid_in_ioframe:1; u32 support_ext_io_size:1; u32 support_ext_queue_depth:1; u32 security_protocol_cmds_fw:1; @@ -1548,7 +1550,9 @@ typedef union _MFI_CAPABILITIES { u32 security_protocol_cmds_fw:1; u32 support_ext_queue_depth:1; u32 support_ext_io_size:1; - u32 reserved:23; + u32 support_vfid_in_ioframe:1; + u32 support_fp_rlbypass:1; + u32 reserved:21; #endif } mfi_capabilities; __le32 reg; diff --git a/drivers/scsi/megaraid/megaraid_sas_fp.c b/drivers/scsi/megaraid/megaraid_sas_fp.c index 741509b..e413113 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fp.c +++ b/drivers/scsi/megaraid/megaraid_sas_fp.c @@ -1020,6 +1020,8 @@ MR_BuildRaidContext(struct megasas_instance *instance, /* assume this IO needs the full row - we'll adjust if not true */ regSize = stripSize; + io_info->do_fp_rlbypass = raid->capability.fpBypassRegionLock; + /* Check if we can send this I/O via FastPath */ if (raid->capability.fpCapable) { if (isRead) diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c b/drivers/scsi/megaraid/megaraid_sas_fusion.c index 4b0c86c..518b488 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c @@ -666,6 +666,8 @@ megasas_ioc_init_fusion(struct megasas_instance *instance) if (instance->max_chain_frame_sz > MEGASAS_CHAIN_FRAME_SZ_MIN) drv_ops->mfi_capabilities.support_ext_io_size = 1; + drv_ops->mfi_capabilities.support_fp_rlbypass = 1; + /* Convert capability to LE32 */ cpu_to_le32s((u32 *)_frame->driver_operations.mfi_capabilities); @@ -1710,8 +1712,8 @@ megasas_build_ldio_fusion(struct megasas_instance *instance, (MEGASAS_REQ_DESCRIPT_FLAGS_LD_IO << MEGASAS_REQ_DESCRIPT_FLAGS_TYPE_SHIFT); if (fusion->adapter_type == INVADER_SERIES) { - if (io_request->RaidContext.regLockFlags == - REGION_TYPE_UNUSED) + if (io_info.do_fp_rlbypass || + (io_request->RaidContext.regLockFlags == REGION_TYPE_UNUSED)) cmd->request_desc->SCSIIO.RequestFlags = (MEGASAS_REQ_DESCRIPT_FLAGS_NO_LOCK << MEGASAS_REQ_DESCRIPT_FLAGS_TYPE_SHIFT); diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.h b/drivers/scsi/megaraid/megaraid_sas_fusion.h index a1f1c0b..db0978d 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fusion.h +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.h @@ -643,7 +643,8 @@ struct MR_SPAN_BLOCK_INFO { struct MR_LD_RAID { struct { #if defined(__BIG_ENDIAN_BITFIELD) - u32 reserved4:6; + u32 reserved4:5; + u32 fpBypassRegionLock:1; u32 tmCapable:1; u32 fpNonRWCapable:1; u32 fpReadAcrossStripe:1; @@ -667,7 +668,8 @@ struct MR_LD_RAID { u32 fpReadAcrossStripe:1; u32 fpNonRWCapable:1; u32 tmCapable:1; - u32 reserved4:6; + u32 fpBypassRegionLock:1; + u32 reserved4:5; #endif } capability; __le32 reserved6; @@ -737,7 +739,7 @@ struct IO_REQUEST_INFO { u8 fpOkForIo; u8 Io
[PATCH v2 15/15] megaraid_sas: driver version upgrade
Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com> --- drivers/scsi/megaraid/megaraid_sas.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas.h b/drivers/scsi/megaraid/megaraid_sas.h index 3e92f20..b6fdb48 100644 --- a/drivers/scsi/megaraid/megaraid_sas.h +++ b/drivers/scsi/megaraid/megaraid_sas.h @@ -35,8 +35,8 @@ /* * MegaRAID SAS Driver meta data */ -#define MEGASAS_VERSION"06.808.16.00-rc1" -#define MEGASAS_RELDATE"Oct. 8, 2015" +#define MEGASAS_VERSION"06.810.09.00-rc1" +#define MEGASAS_RELDATE"Jan. 28, 2016" /* * Device IDs -- 1.8.3.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 13/15] megaraid_sas: Introduce module parameter for SCSI command-timeout
This patch will introduce module-parameter for SCSI command timeout value and fix setting of resetwaitime beyond a value. There was some comment from Tomas on last time sent patch regarding why should driver provided scmd_timeout module parameter. This is done for special cases where user wants to tune scmd_timeout value during driver load time. Default value is same as before-90 secs. There are no changes in this patch on top of last time sent patch. Signed-off-by: Kashyap Desai <kashyap.de...@avagotech.com> Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com> Reviewed-by: Tomas Henzl <the...@redhat.com> --- drivers/scsi/megaraid/megaraid_sas_base.c | 15 --- drivers/scsi/megaraid/megaraid_sas_fusion.c | 2 +- 2 files changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index d2ea977..54922e5 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -83,7 +83,7 @@ module_param(throttlequeuedepth, int, S_IRUGO); MODULE_PARM_DESC(throttlequeuedepth, "Adapter queue depth when throttled due to I/O timeout. Default: 16"); -int resetwaittime = MEGASAS_RESET_WAIT_TIME; +unsigned int resetwaittime = MEGASAS_RESET_WAIT_TIME; module_param(resetwaittime, int, S_IRUGO); MODULE_PARM_DESC(resetwaittime, "Wait time in seconds after I/O timeout " "before resetting adapter. Default: 180"); @@ -100,6 +100,10 @@ unsigned int dual_qdepth_disable; module_param(dual_qdepth_disable, int, S_IRUGO); MODULE_PARM_DESC(dual_qdepth_disable, "Disable dual queue depth feature. Default: 0"); +unsigned int scmd_timeout = MEGASAS_DEFAULT_CMD_TIMEOUT; +module_param(scmd_timeout, int, S_IRUGO); +MODULE_PARM_DESC(scmd_timeout, "scsi command timeout (10-90s), default 90s. See megasas_reset_timer."); + MODULE_LICENSE("GPL"); MODULE_VERSION(MEGASAS_VERSION); MODULE_AUTHOR("megaraidlinux@avagotech.com"); @@ -1850,7 +1854,7 @@ static int megasas_slave_configure(struct scsi_device *sdev) * The RAID firmware may require extended timeouts. */ blk_queue_rq_timeout(sdev->request_queue, - MEGASAS_DEFAULT_CMD_TIMEOUT * HZ); + scmd_timeout * HZ); return 0; } @@ -2645,7 +2649,7 @@ blk_eh_timer_return megasas_reset_timer(struct scsi_cmnd *scmd) unsigned long flags; if (time_after(jiffies, scmd->jiffies_at_alloc + - (MEGASAS_DEFAULT_CMD_TIMEOUT * 2) * HZ)) { + (scmd_timeout * 2) * HZ)) { return BLK_EH_NOT_HANDLED; } @@ -5254,6 +5258,11 @@ static int megasas_init_fw(struct megasas_instance *instance) instance->throttlequeuedepth = MEGASAS_THROTTLE_QUEUE_DEPTH; + if (resetwaittime > MEGASAS_RESET_WAIT_TIME) + resetwaittime = MEGASAS_RESET_WAIT_TIME; + + if ((scmd_timeout < 10) || (scmd_timeout > MEGASAS_DEFAULT_CMD_TIMEOUT)) + scmd_timeout = MEGASAS_DEFAULT_CMD_TIMEOUT; /* Launch SR-IOV heartbeat timer */ if (instance->requestorId) { diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c b/drivers/scsi/megaraid/megaraid_sas_fusion.c index 64926f7..e740e26 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c @@ -91,7 +91,7 @@ void megasas_start_timer(struct megasas_instance *instance, struct timer_list *timer, void *fn, unsigned long interval); extern struct megasas_mgmt_info megasas_mgmt_info; -extern int resetwaittime; +extern unsigned int resetwaittime; extern unsigned int dual_qdepth_disable; static void megasas_free_rdpq_fusion(struct megasas_instance *instance); static void megasas_free_reply_fusion(struct megasas_instance *instance); -- 1.8.3.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 05/15] megaraid_sas: Update device Queue depth based on interface type
This patch will update device Queue depth based on interface type(SAS, SATA..) for sysPDs. For Virtual disks(VDs), there will be no change in queue depth(will remain 256). To fetch interface type(SAS or SATA or FC..) of syspD, driver will send DCMD MR_DCMD_PD_GET_INFO per sysPD. There are no changes in this patch from last time sent patch. There was some feedback to use dma_alloc_coherent instead of pci_alloc_consistent which will be handled in follow up along with several other cases where dma_alloc_coherent can be used. Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com> Signed-off-by: Kashyap Desai <kashyap.de...@avagotech.com> --- drivers/scsi/megaraid/megaraid_sas.h | 270 +- drivers/scsi/megaraid/megaraid_sas_base.c | 127 ++ 2 files changed, 396 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/megaraid/megaraid_sas.h b/drivers/scsi/megaraid/megaraid_sas.h index 0fcb156..773fc54 100644 --- a/drivers/scsi/megaraid/megaraid_sas.h +++ b/drivers/scsi/megaraid/megaraid_sas.h @@ -215,6 +215,7 @@ #define MR_DCMD_CTRL_SET_CRASH_DUMP_PARAMS 0x01190100 #define MR_DRIVER_SET_APP_CRASHDUMP_MODE (0xF001 | 0x0600) +#define MR_DCMD_PD_GET_INFO0x0202 /* * Global functions @@ -435,6 +436,257 @@ enum MR_PD_STATE { MR_PD_STATE_SYSTEM = 0x40, }; +union MR_PD_REF { + struct { + u16 deviceId; + u16 seqNum; + } mrPdRef; + u32 ref; +}; + +/* + * define the DDF Type bit structure + */ +union MR_PD_DDF_TYPE { +struct { + union { + struct { +#ifndef __BIG_ENDIAN_BITFIELD +u16 forcedPDGUID:1; +u16 inVD:1; +u16 isGlobalSpare:1; +u16 isSpare:1; +u16 isForeign:1; +u16 reserved:7; +u16 intf:4; +#else +u16 intf:4; +u16 reserved:7; +u16 isForeign:1; +u16 isSpare:1; +u16 isGlobalSpare:1; +u16 inVD:1; +u16 forcedPDGUID:1; +#endif +} pdType; +u16 type; +}; +u16 reserved; +} ddf; +struct { +u32reserved; +} nonDisk; +u32 type; +} __packed; + +/* + * defines the progress structure + */ +union MR_PROGRESS { + struct { + u16 progress; + union { + u16 elapsedSecs; + u16 elapsedSecsForLastPercent; + }; + } mrProgress; + u32 w; +} __packed; + +/* + * defines the physical drive progress structure + */ +struct MR_PD_PROGRESS { + struct { +#ifndef MFI_BIG_ENDIAN + u32 rbld:1; + u32 patrol:1; + u32 clear:1; + u32 copyBack:1; + u32 erase:1; + u32 locate:1; + u32 reserved:26; +#else + u32 reserved:26; + u32 locate:1; + u32 erase:1; + u32 copyBack:1; + u32 clear:1; + u32 patrol:1; + u32 rbld:1; +#endif + } active; + union MR_PROGRESS rbld; + union MR_PROGRESS patrol; + union { + union MR_PROGRESS clear; + union MR_PROGRESS erase; + }; + + struct { +#ifndef MFI_BIG_ENDIAN + u32 rbld:1; + u32 patrol:1; + u32 clear:1; + u32 copyBack:1; + u32 erase:1; + u32 reserved:27; +#else + u32 reserved:27; + u32 erase:1; + u32 copyBack:1; + u32 clear:1; + u32 patrol:1; + u32 rbld:1; +#endif + } pause; + + union MR_PROGRESS reserved[3]; +} __packed; + +struct MR_PD_INFO { + union MR_PD_REF ref; + u8 inquiryData[96]; + u8 vpdPage83[64]; + u8 notSupported; + u8 scsiDevType; + + union { + u8 connectedPortBitmap; + u8 connectedPortNumbers; + }; + + u8 deviceSpeed; + u32 mediaErrCount; + u32 otherErrCount; + u32 predFailCount; + u32 lastPredFailEventSeqNum; + + u16 fwState; + u8 disabledForRemoval; + u8 linkSpeed; + union MR_PD_DDF_TYPE state; + + struct { + u8 cou
[PATCH v2 07/15] megaraid_sas: Reply Descriptor Post Queue(RDPQ) support
This patch will create reply queue pool for each MSI-x index and will provide array of all reply queue base address instead of single base address of legacy mode. Using this new interface Driver can support higher Queue depth allocating more reply queue as scattered DMA pool. If array mode is not supported driver will fall back to legacy method of allocation reply pool. This method fall back controller queue depth to 1K max. To enable more than 1K QD, driver expect FW to support Array mode and scratch_pad3 should provide new queue depth value. Using this method, Firmware should not allow downgrade (OFU) if latest driver and latest FW report 4K QD and Array mode reply queue. This type of FW upgrade may cause firmware fault and it should not be supported. Upgrade of FW will work, but queue depth of the controller will be unchanged until reboot/driver reload. I have accomodated Tomas' comments in this patch- fix few error handling cases inside functions- megasas_alloc_cmdlist_fusion() and megasas_alloc_cmds_fusion(), fix typo- disable(old- disbale) in rdpq_enable module parameter's description, modify print to reflect RDPQ support statement correctly. Signed-off-by: Kashyap Desai <kashyap.de...@avagotech.com> Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com> --- drivers/scsi/megaraid/megaraid_sas.h| 6 +- drivers/scsi/megaraid/megaraid_sas_base.c | 9 + drivers/scsi/megaraid/megaraid_sas_fusion.c | 543 drivers/scsi/megaraid/megaraid_sas_fusion.h | 12 +- 4 files changed, 331 insertions(+), 239 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas.h b/drivers/scsi/megaraid/megaraid_sas.h index 01135be..3b1ed2d 100644 --- a/drivers/scsi/megaraid/megaraid_sas.h +++ b/drivers/scsi/megaraid/megaraid_sas.h @@ -152,6 +152,7 @@ #define MFI_RESET_FLAGSMFI_INIT_READY| \ MFI_INIT_MFIMODE| \ MFI_INIT_ABORT +#define MPI2_IOCINIT_MSGFLAG_RDPQ_ARRAY_MODE(0x01) /* * MFI frame flags @@ -1416,6 +1417,7 @@ enum DCMD_TIMEOUT_ACTION { #define MR_MAX_REPLY_QUEUES_EXT_OFFSET 0X003FC000 #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14 #define MR_MAX_MSIX_REG_ARRAY 16 +#define MR_RDPQ_MODE_OFFSET0X0080 /* * register set for both 1068 and 1078 controllers * structure extended for 1078 registers @@ -1455,8 +1457,9 @@ struct megasas_register_set { u32 outbound_scratch_pad ; /*00B0h*/ u32 outbound_scratch_pad_2; /*00B4h*/ + u32 outbound_scratch_pad_3; /*00B8h*/ - u32 reserved_4[2]; /*00B8h*/ + u32 reserved_4; /*00BCh*/ u32 inbound_low_queue_port ;/*00C0h*/ @@ -2117,6 +2120,7 @@ struct megasas_instance { u8 mask_interrupts; u16 max_chain_frame_sz; u8 is_imr; + u8 is_rdpq; bool dev_handle; }; struct MR_LD_VF_MAP { diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index ea3994b..8df58c2 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -92,6 +92,10 @@ int smp_affinity_enable = 1; module_param(smp_affinity_enable, int, S_IRUGO); MODULE_PARM_DESC(smp_affinity_enable, "SMP affinity feature enable/disbale Default: enable(1)"); +int rdpq_enable = 1; +module_param(rdpq_enable, int, S_IRUGO); +MODULE_PARM_DESC(rdpq_enable, " Allocate reply queue in chunks for large queue depth enable/disable Default: disable(0)"); + MODULE_LICENSE("GPL"); MODULE_VERSION(MEGASAS_VERSION); MODULE_AUTHOR("megaraidlinux@avagotech.com"); @@ -5080,6 +5084,9 @@ static int megasas_init_fw(struct megasas_instance *instance) instance->msix_vectors = ((scratch_pad_2 & MR_MAX_REPLY_QUEUES_EXT_OFFSET) >> MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT) + 1; + if (rdpq_enable) + instance->is_rdpq = (scratch_pad_2 & MR_RDPQ_MODE_OFFSET) ? + 1 : 0; fw_msix_count = instance->msix_vectors; /* Save 1-15 reply post index address to local memory * Index 0 is already saved from reg offset @@ -5116,6 +5123,8 @@ static int megasas_init_fw(struct megasas_instance *instance) dev_info(>pdev->dev, "current msix/online cpus\t: (%d/%d)\n", instance->msix_vectors, (unsigned int)num_online_cpus()); + dev_info(>pdev->dev, + "RDPQ mod
[PATCH v2 12/15] megaraid_sas: MFI adapter's OCR changes
Optimized MFI adapters' OCR path, particularly megasas_wait_for_outstanding() function. Accomodated Tomas' comments provided on last time sent patch- remove redundant checks when label- kill_hba_and_failed is being called. Signed-off-by: Kashyap Desai <kashyap.de...@avagotech.com> Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com> Reviewed-by: Tomas Henzl <the...@redhat.com> --- drivers/scsi/megaraid/megaraid_sas_base.c | 101 +++--- 1 file changed, 50 insertions(+), 51 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index 1bd5da4..d2ea977 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -2455,15 +2455,19 @@ void megasas_sriov_heartbeat_handler(unsigned long instance_addr) */ static int megasas_wait_for_outstanding(struct megasas_instance *instance) { - int i; + int i, sl, outstanding; u32 reset_index; u32 wait_time = MEGASAS_RESET_WAIT_TIME; unsigned long flags; struct list_head clist_local; struct megasas_cmd *reset_cmd; u32 fw_state; - u8 kill_adapter_flag; + if (atomic_read(>adprecovery) == MEGASAS_HW_CRITICAL_ERROR) { + dev_info(>pdev->dev, "%s:%d HBA is killed.\n", + __func__, __LINE__); + return FAILED; + } if (atomic_read(>adprecovery) != MEGASAS_HBA_OPERATIONAL) { @@ -2520,7 +2524,7 @@ static int megasas_wait_for_outstanding(struct megasas_instance *instance) } for (i = 0; i < resetwaittime; i++) { - int outstanding = atomic_read(>fw_outstanding); + outstanding = atomic_read(>fw_outstanding); if (!outstanding) break; @@ -2539,65 +2543,60 @@ static int megasas_wait_for_outstanding(struct megasas_instance *instance) } i = 0; - kill_adapter_flag = 0; + outstanding = atomic_read(>fw_outstanding); + fw_state = instance->instancet->read_fw_status_reg(instance->reg_set) & MFI_STATE_MASK; + + if ((!outstanding && (fw_state == MFI_STATE_OPERATIONAL))) + goto no_outstanding; + + if (instance->disableOnlineCtrlReset) + goto kill_hba_and_failed; do { - fw_state = instance->instancet->read_fw_status_reg( - instance->reg_set) & MFI_STATE_MASK; - if ((fw_state == MFI_STATE_FAULT) && - (instance->disableOnlineCtrlReset == 0)) { - if (i == 3) { - kill_adapter_flag = 2; - break; - } + if ((fw_state == MFI_STATE_FAULT) || atomic_read(>fw_outstanding)) { + dev_info(>pdev->dev, + "%s:%d waiting_for_outstanding: before issue OCR. FW state = 0x%x, oustanding 0x%x\n", + __func__, __LINE__, fw_state, atomic_read(>fw_outstanding)); + if (i == 3) + goto kill_hba_and_failed; megasas_do_ocr(instance); - kill_adapter_flag = 1; - /* wait for 1 secs to let FW finish the pending cmds */ - msleep(1000); + if (atomic_read(>adprecovery) == MEGASAS_HW_CRITICAL_ERROR) { + dev_info(>pdev->dev, "%s:%d OCR failed and HBA is killed.\n", + __func__, __LINE__); + return FAILED; + } + dev_info(>pdev->dev, "%s:%d waiting_for_outstanding: after issue OCR.\n", + __func__, __LINE__); + + for (sl = 0; sl < 10; sl++) + msleep(500); + + outstanding = atomic_read(>fw_outstanding); + + fw_state = instance->instancet->read_fw_status_reg(instance->reg_set) & MFI_STATE_MASK; + if ((!outstanding && (fw_state == MFI_STATE_OPERATIONAL))) + goto no_outstanding; } i++; } while (i <= 3); - if (atomic_read(>fw_outstanding) && !kill_adapter_flag) { - if (instance->disableOnlineCtrlReset == 0) { - megasas_do_ocr(instance); +no_outstanding: - /* wait for 5 secs to let FW finish the pending cmds */ - for (i = 0; i < wait_time; i++) { - int outstanding = -
[PATCH v2 08/15] megaraid_sas: Code optimization build_and_issue_cmd return-type
build_and_issue_cmd should return SCSI_MLQUEUE_HOST_BUSY for few error case instead of returning 1. There are no changes in this patch from last time sent patch. Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com> Reviewed-by: Tomas Henzl <the...@redhat.com> --- drivers/scsi/megaraid/megaraid_sas_base.c | 9 ++--- drivers/scsi/megaraid/megaraid_sas_fusion.c | 4 ++-- 2 files changed, 4 insertions(+), 9 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index 8df58c2..edf8911 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -1636,7 +1636,7 @@ megasas_build_and_issue_cmd(struct megasas_instance *instance, return 0; out_return_cmd: megasas_return_cmd(instance, cmd); - return 1; + return SCSI_MLQUEUE_HOST_BUSY; } @@ -1728,12 +1728,7 @@ megasas_queue_command(struct Scsi_Host *shost, struct scsi_cmnd *scmd) break; } - if (instance->instancet->build_and_issue_cmd(instance, scmd)) { - dev_err(>pdev->dev, "Err returned from build_and_issue_cmd\n"); - return SCSI_MLQUEUE_HOST_BUSY; - } - - return 0; + return instance->instancet->build_and_issue_cmd(instance, scmd); out_done: scmd->scsi_done(scmd); diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c b/drivers/scsi/megaraid/megaraid_sas_fusion.c index 1351cae..f553830 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c @@ -2125,7 +2125,7 @@ megasas_build_and_issue_cmd_fusion(struct megasas_instance *instance, req_desc = megasas_get_request_descriptor(instance, index-1); if (!req_desc) - return 1; + return SCSI_MLQUEUE_HOST_BUSY; req_desc->Words = 0; cmd->request_desc = req_desc; @@ -2134,7 +2134,7 @@ megasas_build_and_issue_cmd_fusion(struct megasas_instance *instance, megasas_return_cmd_fusion(instance, cmd); dev_err(>pdev->dev, "Error building command\n"); cmd->request_desc = NULL; - return 1; + return SCSI_MLQUEUE_HOST_BUSY; } req_desc = cmd->request_desc; -- 1.8.3.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 14/15] megaraid_sas: SPERC OCR changes
This patch will do some fixes in OCR path of SRIOV enabled series of Avago controllers. 1)Removing late detection HB. 2)Change in the behavior if the FW found in READY/OPERAETIONAL state. There are no changes in this patch from last time sent patch. Signed-off-by: Uday Lingala <uday.ling...@avagotech.com> Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com> Reviewed-by: Tomas Henzl <the...@redhat.com> --- drivers/scsi/megaraid/megaraid_sas_fusion.c | 73 +++-- 1 file changed, 16 insertions(+), 57 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c b/drivers/scsi/megaraid/megaraid_sas_fusion.c index e740e26..be9c3f1 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c @@ -3462,52 +3462,7 @@ int megasas_reset_fusion(struct Scsi_Host *shost, int reason) /* Let SR-IOV VF & PF sync up if there was a HB failure */ if (instance->requestorId && !reason) { msleep(MEGASAS_OCR_SETTLE_TIME_VF); - /* Look for a late HB update after VF settle time */ - if (abs_state == MFI_STATE_OPERATIONAL && - (instance->hb_host_mem->HB.fwCounter != -instance->hb_host_mem->HB.driverCounter)) { - instance->hb_host_mem->HB.driverCounter = - instance->hb_host_mem->HB.fwCounter; - dev_warn(>pdev->dev, "SR-IOV:" - "Late FW heartbeat update for " - "scsi%d.\n", - instance->host->host_no); - } else { - /* In VF mode, first poll for FW ready */ - for (i = 0; -i < (MEGASAS_RESET_WAIT_TIME * 1000); -i += 20) { - status_reg = - instance->instancet-> - read_fw_status_reg( - instance->reg_set); - abs_state = status_reg & - MFI_STATE_MASK; - if (abs_state == MFI_STATE_READY) { - dev_warn(>pdev->dev, - "SR-IOV: FW was found" - "to be in ready state " - "for scsi%d.\n", - instance->host->host_no); - break; - } - msleep(20); - } - if (abs_state != MFI_STATE_READY) { - dev_warn(>pdev->dev, "SR-IOV: " - "FW not in ready state after %d" - " seconds for scsi%d, status_reg = " - "0x%x.\n", - MEGASAS_RESET_WAIT_TIME, - instance->host->host_no, - status_reg); - megaraid_sas_kill_hba(instance); - instance->skip_heartbeat_timer_del = 1; - atomic_set(>adprecovery, MEGASAS_HW_CRITICAL_ERROR); - retval = FAILED; - goto out; - } - } + goto transition_to_ready; } /* Now try to reset the chip */ @@ -3516,25 +3471,28 @@ int megasas_reset_fusion(struct Scsi_Host *shost, int reason) if (instance->instancet->adp_reset (instance, instance->reg_set)) continue; - +transition_to_ready: /* Wait for FW to become ready */ if (megasas_transition_to_ready(instance, 1)) { - dev_warn(>pdev->dev, "Failed to " -
[PATCH v2 11/15] megaraid_sas: Make adprecovery variable atomic
Make instance->adprecovery variable atomic and removes hba_lock spinlock while accessing instance->adprecovery. Tomas commented on last time sent patch asking to use u8 instead of atomic for adprecovery. I agree that atomic_t is not required here but this is done for not to touch legacy code of MFI adapters and replace hba_lock with atomic_t so there are no changes in this patch on top of last time sent patch. Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com> Signed-off-by: Kashyap Desai <kashyap.de...@avagotech.com> --- drivers/scsi/megaraid/megaraid_sas.h| 2 +- drivers/scsi/megaraid/megaraid_sas_base.c | 95 +++-- drivers/scsi/megaraid/megaraid_sas_fusion.c | 27 3 files changed, 50 insertions(+), 74 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas.h b/drivers/scsi/megaraid/megaraid_sas.h index c8d25a7..3e92f20 100644 --- a/drivers/scsi/megaraid/megaraid_sas.h +++ b/drivers/scsi/megaraid/megaraid_sas.h @@ -2101,7 +2101,7 @@ struct megasas_instance { u16 drv_supported_vd_count; u16 drv_supported_pd_count; - u8 adprecovery; + atomic_t adprecovery; unsigned long last_time; u32 mfiStatus; u32 last_seq_num; diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index 961c024..1bd5da4 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -483,7 +483,7 @@ static int megasas_check_reset_xscale(struct megasas_instance *instance, struct megasas_register_set __iomem *regs) { - if ((instance->adprecovery != MEGASAS_HBA_OPERATIONAL) && + if ((atomic_read(>adprecovery) != MEGASAS_HBA_OPERATIONAL) && (le32_to_cpu(*instance->consumer) == MEGASAS_ADPRESET_INPROG_SIGN)) return 1; @@ -619,7 +619,7 @@ static int megasas_check_reset_ppc(struct megasas_instance *instance, struct megasas_register_set __iomem *regs) { - if (instance->adprecovery != MEGASAS_HBA_OPERATIONAL) + if (atomic_read(>adprecovery) != MEGASAS_HBA_OPERATIONAL) return 1; return 0; @@ -756,7 +756,7 @@ static int megasas_check_reset_skinny(struct megasas_instance *instance, struct megasas_register_set __iomem *regs) { - if (instance->adprecovery != MEGASAS_HBA_OPERATIONAL) + if (atomic_read(>adprecovery) != MEGASAS_HBA_OPERATIONAL) return 1; return 0; @@ -950,9 +950,8 @@ static int megasas_check_reset_gen2(struct megasas_instance *instance, struct megasas_register_set __iomem *regs) { - if (instance->adprecovery != MEGASAS_HBA_OPERATIONAL) { + if (atomic_read(>adprecovery) != MEGASAS_HBA_OPERATIONAL) return 1; - } return 0; } @@ -998,7 +997,7 @@ megasas_issue_polled(struct megasas_instance *instance, struct megasas_cmd *cmd) frame_hdr->cmd_status = MFI_STAT_INVALID_STATUS; frame_hdr->flags |= cpu_to_le16(MFI_FRAME_DONT_POST_IN_REPLY_QUEUE); - if ((instance->adprecovery == MEGASAS_HW_CRITICAL_ERROR) || + if ((atomic_read(>adprecovery) == MEGASAS_HW_CRITICAL_ERROR) || (instance->instancet->issue_dcmd(instance, cmd))) { dev_err(>pdev->dev, "Failed from %s %d\n", __func__, __LINE__); @@ -1026,7 +1025,7 @@ megasas_issue_blocked_cmd(struct megasas_instance *instance, int ret = 0; cmd->cmd_status_drv = MFI_STAT_INVALID_STATUS; - if ((instance->adprecovery == MEGASAS_HW_CRITICAL_ERROR) || + if ((atomic_read(>adprecovery) == MEGASAS_HW_CRITICAL_ERROR) || (instance->instancet->issue_dcmd(instance, cmd))) { dev_err(>pdev->dev, "Failed from %s %d\n", __func__, __LINE__); @@ -1090,7 +1089,7 @@ megasas_issue_blocked_abort_cmd(struct megasas_instance *instance, cmd->sync_cmd = 1; cmd->cmd_status_drv = MFI_STAT_INVALID_STATUS; - if ((instance->adprecovery == MEGASAS_HW_CRITICAL_ERROR) || + if ((atomic_read(>adprecovery) == MEGASAS_HW_CRITICAL_ERROR) || (instance->instancet->issue_dcmd(instance, cmd))) { dev_err(>pdev->dev, "Failed from %s %d\n", __func__, __LINE__); @@ -1653,7 +1652,6 @@ static int megasas_queue_command(struct Scsi_Host *shost, struct scsi_cmnd *scmd) { struct megasas_instance *instance; - unsigned long flags; struct MR_PRIV_DEVICE *mr_device_priv_data; instance = (struct megasas_instance *) @@ -1668,24 +1666,20 @@ megasas_queue_command(struct Scsi_Host *shost, struct scsi_cmnd *scmd) if (instance->issuepe
[PATCH v2 09/15] megaraid_sas: Dual Queue depth support
This patch will add support for Dual Queue depth reported by firmware. Below are key points- 1. For iMR controllers, firmware will report two queue depths- 1. Controller wide Queue depth 2. LDIO Queue depth(240). Ofcourse, Controller wide Queue depth will be greater among two. Using this new method, iMR can provide larger Queue depth(QD) for JBOD and limited QD for Virtual Disk(VD). This feature gives benefit for iMR product which will be used for deployment with large number of JBOD and limited number of VD on setup. 2. megaraid_sas driver will throttle Read write LDIOs based when RW LDIOs reaches "LDIO Queue Depth". 3. This feature of dual queue depth can enabled/disabled via module parameter. Default behavior is: Dual Queue depth is enabled. 4. Added sysfs parameter "ldio_outstanding" for user to read LDIO outstanding at run time. 5. There are different flavors of firmware using same driver and for specific firmware this will be turned on(by default) where it's really needed. For rest of firmware flavors, this will be switched off(not supported). I have accomodated Tomas' comments provided on last time sent patch- use atomic_inc_return instead of using atomic_read() and atomic_inc() separately inside function- megasas_build_and_issue_cmd_fusion(). Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com> Signed-off-by: Kashyap Desai <kashyap.de...@avagotech.com> --- drivers/scsi/megaraid/megaraid_sas.h| 9 +++ drivers/scsi/megaraid/megaraid_sas_base.c | 20 ++- drivers/scsi/megaraid/megaraid_sas_fusion.c | 88 ++--- 3 files changed, 107 insertions(+), 10 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas.h b/drivers/scsi/megaraid/megaraid_sas.h index 3b1ed2d..2a2f491 100644 --- a/drivers/scsi/megaraid/megaraid_sas.h +++ b/drivers/scsi/megaraid/megaraid_sas.h @@ -1353,6 +1353,12 @@ enum DCMD_TIMEOUT_ACTION { KILL_ADAPTER = 1, IGNORE_TIMEOUT = 2, }; + +enum FW_BOOT_CONTEXT { + PROBE_CONTEXT = 0, + OCR_CONTEXT = 1, +}; + /* Frame Type */ #define IO_FRAME 0 #define PTHRU_FRAME1 @@ -2038,6 +2044,8 @@ struct megasas_instance { u16 max_fw_cmds; u16 max_mfi_cmds; u16 max_scsi_cmds; + u16 ldio_threshold; + u16 cur_can_queue; u32 max_sectors_per_req; struct megasas_aen_event *ev; @@ -2068,6 +2076,7 @@ struct megasas_instance { u32 fw_support_ieee; atomic_t fw_outstanding; + atomic_t ldio_outstanding; atomic_t fw_reset_no_pci_access; struct megasas_instance_template *instancet; diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index edf8911..961c024 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -96,6 +96,10 @@ int rdpq_enable = 1; module_param(rdpq_enable, int, S_IRUGO); MODULE_PARM_DESC(rdpq_enable, " Allocate reply queue in chunks for large queue depth enable/disable Default: disable(0)"); +unsigned int dual_qdepth_disable; +module_param(dual_qdepth_disable, int, S_IRUGO); +MODULE_PARM_DESC(dual_qdepth_disable, "Disable dual queue depth feature. Default: 0"); + MODULE_LICENSE("GPL"); MODULE_VERSION(MEGASAS_VERSION); MODULE_AUTHOR("megaraidlinux@avagotech.com"); @@ -1976,7 +1980,7 @@ megasas_check_and_restore_queue_depth(struct megasas_instance *instance) spin_lock_irqsave(instance->host->host_lock, flags); instance->flag &= ~MEGASAS_FW_BUSY; - instance->host->can_queue = instance->max_scsi_cmds; + instance->host->can_queue = instance->cur_can_queue; spin_unlock_irqrestore(instance->host->host_lock, flags); } } @@ -2941,6 +2945,16 @@ megasas_page_size_show(struct device *cdev, return snprintf(buf, PAGE_SIZE, "%ld\n", (unsigned long)PAGE_SIZE - 1); } +static ssize_t +megasas_ldio_outstanding_show(struct device *cdev, struct device_attribute *attr, + char *buf) +{ + struct Scsi_Host *shost = class_to_shost(cdev); + struct megasas_instance *instance = (struct megasas_instance *)shost->hostdata; + + return snprintf(buf, PAGE_SIZE, "%d\n", atomic_read(>ldio_outstanding)); +} + static DEVICE_ATTR(fw_crash_buffer, S_IRUGO | S_IWUSR, megasas_fw_crash_buffer_show, megasas_fw_crash_buffer_store); static DEVICE_ATTR(fw_crash_buffer_size, S_IRUGO, @@ -2949,12 +2963,15 @@ static DEVICE_ATTR(fw_crash_state, S_IRUGO | S_IWUSR, megasas_fw_crash_state_show, megasas_fw_crash_state_store); static DEVICE_ATTR(page_size, S_IRUGO, megasas_page_size_show, NULL); +static DEVICE_ATTR(ldio_outstanding, S_IRUGO, + megasas_ldio_outstanding_show, NULL); struct devi
[PATCH v2 10/15] megaraid_sas: IO throttling support
This patch will add capability in driver to tell firmware that it can throttle IOs in case Controller's Queue depth is downgraded post OFU (Online firmware upgrade). This feature will ensure firmware can be downgraded from higher queue depth to lower queue depth without needing system reboot. Added throttling code in IO path of driver, in case OS tries to send more IOs than post OFU firmware's queue depth. I have accomodated Tomas' comments provided on last time sent patch- removed the un-necessary code of throttling of IOs against can_queue inside function- megasas_build_and_issue_cmd_fusion() as SCSI mid layer will anyways does this. Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com> Signed-off-by: Kashyap Desai <kashyap.de...@avagotech.com> --- drivers/scsi/megaraid/megaraid_sas.h| 6 -- drivers/scsi/megaraid/megaraid_sas_fusion.c | 1 + 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas.h b/drivers/scsi/megaraid/megaraid_sas.h index 2a2f491..c8d25a7 100644 --- a/drivers/scsi/megaraid/megaraid_sas.h +++ b/drivers/scsi/megaraid/megaraid_sas.h @@ -1537,7 +1537,8 @@ union megasas_sgl_frame { typedef union _MFI_CAPABILITIES { struct { #if defined(__BIG_ENDIAN_BITFIELD) - u32 reserved:21; + u32 reserved:20; + u32 support_qd_throttling:1; u32 support_fp_rlbypass:1; u32 support_vfid_in_ioframe:1; u32 support_ext_io_size:1; @@ -1561,7 +1562,8 @@ typedef union _MFI_CAPABILITIES { u32 support_ext_io_size:1; u32 support_vfid_in_ioframe:1; u32 support_fp_rlbypass:1; - u32 reserved:21; + u32 support_qd_throttling:1; + u32 reserved:20; #endif } mfi_capabilities; __le32 reg; diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c b/drivers/scsi/megaraid/megaraid_sas_fusion.c index 6b8547c..2c4912f 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c @@ -803,6 +803,7 @@ megasas_ioc_init_fusion(struct megasas_instance *instance) if (!dual_qdepth_disable) drv_ops->mfi_capabilities.support_ext_queue_depth = 1; + drv_ops->mfi_capabilities.support_qd_throttling = 1; /* Convert capability to LE32 */ cpu_to_le32s((u32 *)_frame->driver_operations.mfi_capabilities); -- 1.8.3.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