Re: [PATCH] scsi: megaraid_sas: Use struct_size() helper
On Sat, Jun 8, 2019 at 12:10 AM Gustavo A. R. Silva
wrote:
>
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct MR_PD_CFG_SEQ_NUM_SYNC {
> ...
> struct MR_PD_CFG_SEQ seq[1];
> } __packed;
>
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes.
>
> So, replace the following form:
>
> sizeof(struct MR_PD_CFG_SEQ_NUM_SYNC) + (sizeof(struct MR_PD_CFG_SEQ) *
> (MAX_PHYSICAL_DEVICES - 1))
>
> with:
>
> struct_size(pd_sync, seq, MAX_PHYSICAL_DEVICES - 1)
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva
Acked-by: Sumit Saxena
> ---
> drivers/scsi/megaraid/megaraid_sas_fusion.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> index a25b6b4b6548..56bd524dddbf 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> @@ -1191,7 +1191,7 @@ megasas_ioc_init_fusion(struct megasas_instance
> *instance)
> int
> megasas_sync_pd_seq_num(struct megasas_instance *instance, bool pend) {
> int ret = 0;
> - u32 pd_seq_map_sz;
> + size_t pd_seq_map_sz;
> struct megasas_cmd *cmd;
> struct megasas_dcmd_frame *dcmd;
> struct fusion_context *fusion = instance->ctrl_context;
> @@ -1200,9 +1200,7 @@ megasas_sync_pd_seq_num(struct megasas_instance
> *instance, bool pend) {
>
> pd_sync = (void *)fusion->pd_seq_sync[(instance->pd_seq_map_id & 1)];
> pd_seq_h = fusion->pd_seq_phys[(instance->pd_seq_map_id & 1)];
> - pd_seq_map_sz = sizeof(struct MR_PD_CFG_SEQ_NUM_SYNC) +
> - (sizeof(struct MR_PD_CFG_SEQ) *
> - (MAX_PHYSICAL_DEVICES - 1));
> + pd_seq_map_sz = struct_size(pd_sync, seq, MAX_PHYSICAL_DEVICES - 1);
>
> cmd = megasas_get_cmd(instance);
> if (!cmd) {
> --
> 2.21.0
>
Re: [PATCH 3/3] megaraid_sas: use DEVICE_ATTR_{RO, RW}
On Wed, May 29, 2019 at 9:30 PM Tomas Henzl wrote:
>
> Use existing macros.
> No functional change.
>
> Signed-off-by: Tomas Henzl
Acked-by: Sumit Saxena
> ---
> drivers/scsi/megaraid/megaraid_sas_base.c | 44 ++-
> 1 file changed, 18 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index 0522821a5..aa6a5d86d 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -3121,7 +3121,7 @@ megasas_service_aen(struct megasas_instance *instance,
> struct megasas_cmd *cmd)
> }
>
> static ssize_t
> -megasas_fw_crash_buffer_store(struct device *cdev,
> +fw_crash_buffer_store(struct device *cdev,
> struct device_attribute *attr, const char *buf, size_t count)
> {
> struct Scsi_Host *shost = class_to_shost(cdev);
> @@ -3140,7 +3140,7 @@ megasas_fw_crash_buffer_store(struct device *cdev,
> }
>
> static ssize_t
> -megasas_fw_crash_buffer_show(struct device *cdev,
> +fw_crash_buffer_show(struct device *cdev,
> struct device_attribute *attr, char *buf)
> {
> struct Scsi_Host *shost = class_to_shost(cdev);
> @@ -3185,7 +3185,7 @@ megasas_fw_crash_buffer_show(struct device *cdev,
> }
>
> static ssize_t
> -megasas_fw_crash_buffer_size_show(struct device *cdev,
> +fw_crash_buffer_size_show(struct device *cdev,
> struct device_attribute *attr, char *buf)
> {
> struct Scsi_Host *shost = class_to_shost(cdev);
> @@ -3197,7 +3197,7 @@ megasas_fw_crash_buffer_size_show(struct device *cdev,
> }
>
> static ssize_t
> -megasas_fw_crash_state_store(struct device *cdev,
> +fw_crash_state_store(struct device *cdev,
> struct device_attribute *attr, const char *buf, size_t count)
> {
> struct Scsi_Host *shost = class_to_shost(cdev);
> @@ -3232,7 +3232,7 @@ megasas_fw_crash_state_store(struct device *cdev,
> }
>
> static ssize_t
> -megasas_fw_crash_state_show(struct device *cdev,
> +fw_crash_state_show(struct device *cdev,
> struct device_attribute *attr, char *buf)
> {
> struct Scsi_Host *shost = class_to_shost(cdev);
> @@ -3243,14 +3243,14 @@ megasas_fw_crash_state_show(struct device *cdev,
> }
>
> static ssize_t
> -megasas_page_size_show(struct device *cdev,
> +page_size_show(struct device *cdev,
> struct device_attribute *attr, char *buf)
> {
> 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,
> +ldio_outstanding_show(struct device *cdev, struct device_attribute *attr,
> char *buf)
> {
> struct Scsi_Host *shost = class_to_shost(cdev);
> @@ -3260,7 +3260,7 @@ megasas_ldio_outstanding_show(struct device *cdev,
> struct device_attribute *attr
> }
>
> static ssize_t
> -megasas_fw_cmds_outstanding_show(struct device *cdev,
> +fw_cmds_outstanding_show(struct device *cdev,
> struct device_attribute *attr, char *buf)
> {
> struct Scsi_Host *shost = class_to_shost(cdev);
> @@ -3270,7 +3270,7 @@ megasas_fw_cmds_outstanding_show(struct device *cdev,
> }
>
> static ssize_t
> -megasas_dump_system_regs_show(struct device *cdev,
> +dump_system_regs_show(struct device *cdev,
>struct device_attribute *attr, char *buf)
> {
> struct Scsi_Host *shost = class_to_shost(cdev);
> @@ -3281,7 +3281,7 @@ megasas_dump_system_regs_show(struct device *cdev,
> }
>
> static ssize_t
> -megasas_raid_map_id_show(struct device *cdev, struct device_attribute *attr,
> +raid_map_id_show(struct device *cdev, struct device_attribute *attr,
> char *buf)
> {
> struct Scsi_Host *shost = class_to_shost(cdev);
> @@ -3292,22 +3292,14 @@ megasas_raid_map_id_show(struct device *cdev, struct
> device_attribute *attr,
> (unsigned long)instance->map_id);
> }
>
> -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,
> - megasas_fw_crash_buffer_size_show, NULL);
> -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);
> -static DEVICE_ATTR(fw_cmds_outst
Re: [PATCH 2/3] megaraid_sas: use octal permissions instead of constants
On Wed, May 29, 2019 at 9:30 PM Tomas Henzl wrote:
>
> Checkpatch emits a warning when using symbolic permissions. Use octal
> permissions instead.
> No functional change.
>
> Signed-off-by: Tomas Henzl
Acked-by: Sumit Saxena
> ---
> drivers/scsi/megaraid/megaraid_sas_base.c | 20 ++--
> drivers/scsi/megaraid/megaraid_sas_fp.c | 2 +-
> 2 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index 3752daab0..0522821a5 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -64,45 +64,45 @@
> * Will be set in megasas_init_mfi if user does not provide
> */
> static unsigned int max_sectors;
> -module_param_named(max_sectors, max_sectors, int, S_IRUGO);
> +module_param_named(max_sectors, max_sectors, int, 0444);
> MODULE_PARM_DESC(max_sectors,
> "Maximum number of sectors per IO command");
>
> static int msix_disable;
> -module_param(msix_disable, int, S_IRUGO);
> +module_param(msix_disable, int, 0444);
> MODULE_PARM_DESC(msix_disable, "Disable MSI-X interrupt handling. Default:
> 0");
>
> static unsigned int msix_vectors;
> -module_param(msix_vectors, int, S_IRUGO);
> +module_param(msix_vectors, int, 0444);
> MODULE_PARM_DESC(msix_vectors, "MSI-X max vector count. Default: Set by FW");
>
> static int allow_vf_ioctls;
> -module_param(allow_vf_ioctls, int, S_IRUGO);
> +module_param(allow_vf_ioctls, int, 0444);
> MODULE_PARM_DESC(allow_vf_ioctls, "Allow ioctls in SR-IOV VF mode. Default:
> 0");
>
> static unsigned int throttlequeuedepth = MEGASAS_THROTTLE_QUEUE_DEPTH;
> -module_param(throttlequeuedepth, int, S_IRUGO);
> +module_param(throttlequeuedepth, int, 0444);
> MODULE_PARM_DESC(throttlequeuedepth,
> "Adapter queue depth when throttled due to I/O timeout. Default: 16");
>
> unsigned int resetwaittime = MEGASAS_RESET_WAIT_TIME;
> -module_param(resetwaittime, int, S_IRUGO);
> +module_param(resetwaittime, int, 0444);
> MODULE_PARM_DESC(resetwaittime, "Wait time in (1-180s) after I/O timeout
> before resetting adapter. Default: 180s");
>
> int smp_affinity_enable = 1;
> -module_param(smp_affinity_enable, int, S_IRUGO);
> +module_param(smp_affinity_enable, int, 0444);
> MODULE_PARM_DESC(smp_affinity_enable, "SMP affinity feature enable/disable
> Default: enable(1)");
>
> int rdpq_enable = 1;
> -module_param(rdpq_enable, int, S_IRUGO);
> +module_param(rdpq_enable, int, 0444);
> MODULE_PARM_DESC(rdpq_enable, "Allocate reply queue in chunks for large
> queue depth enable/disable Default: enable(1)");
>
> unsigned int dual_qdepth_disable;
> -module_param(dual_qdepth_disable, int, S_IRUGO);
> +module_param(dual_qdepth_disable, int, 0444);
> 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_param(scmd_timeout, int, 0444);
> MODULE_PARM_DESC(scmd_timeout, "scsi command timeout (10-90s), default 90s.
> See megasas_reset_timer.");
>
> MODULE_LICENSE("GPL");
> diff --git a/drivers/scsi/megaraid/megaraid_sas_fp.c
> b/drivers/scsi/megaraid/megaraid_sas_fp.c
> index 9ac357619..d296255a4 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_fp.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_fp.c
> @@ -58,7 +58,7 @@
>
> #define LB_PENDING_CMDS_DEFAULT 4
> static unsigned int lb_pending_cmds = LB_PENDING_CMDS_DEFAULT;
> -module_param(lb_pending_cmds, int, S_IRUGO);
> +module_param(lb_pending_cmds, int, 0444);
> MODULE_PARM_DESC(lb_pending_cmds, "Change raid-1 load balancing outstanding "
> "threshold. Valid Values are 1-128. Default: 4");
>
> --
> 2.20.1
>
Re: [PATCH 1/3] megaraid_sas: make max_sectors visible in sys
On Wed, May 29, 2019 at 9:30 PM Tomas Henzl wrote: > > Support is easier with all driver parameters visible in sysfs. > > Signed-off-by: Tomas Henzl Acked-by: Sumit Saxena > --- > 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 3a9128ed3..3752daab0 100644 > --- a/drivers/scsi/megaraid/megaraid_sas_base.c > +++ b/drivers/scsi/megaraid/megaraid_sas_base.c > @@ -64,7 +64,7 @@ > * Will be set in megasas_init_mfi if user does not provide > */ > static unsigned int max_sectors; > -module_param_named(max_sectors, max_sectors, int, 0); > +module_param_named(max_sectors, max_sectors, int, S_IRUGO); > MODULE_PARM_DESC(max_sectors, > "Maximum number of sectors per IO command"); > > -- > 2.20.1 >
Re: [PATCH -next] scsi: megaraid_sas: Remove unused including
On Sat, Jun 1, 2019 at 8:40 AM YueHaibing wrote: > > Remove including that don't need it. > > Signed-off-by: YueHaibing Acked-by: Sumit Saxena > --- > drivers/scsi/megaraid/megaraid_sas_debugfs.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/scsi/megaraid/megaraid_sas_debugfs.c > b/drivers/scsi/megaraid/megaraid_sas_debugfs.c > index e52837bb6807..c69760775efa 100644 > --- a/drivers/scsi/megaraid/megaraid_sas_debugfs.c > +++ b/drivers/scsi/megaraid/megaraid_sas_debugfs.c > @@ -25,7 +25,6 @@ > * > * Send feedback to: megaraidlinux@broadcom.com > */ > -#include > #include > #include > #include > > > > >
Re: [PATCH V1] scsi: megaraid_sas: reduce module load time
On Fri, Mar 1, 2019 at 8:27 PM Steve Sistare wrote:
>
> megaraid_sas takes 1+ seconds to load while waiting for firmware:
>
> [2.822603] megaraid_sas :03:00.0: Waiting for FW to come to ready state
> [3.871003] megaraid_sas :03:00.0: FW now in Ready state
>
> This is due to the following loop in megasas_transition_to_ready(), which
> waits a minimum of 1 second, even though the FW becomes ready in tens of
> millisecs:
>
> /*
> * The cur_state should not last for more than max_wait secs
> */
> for (i = 0; i < max_wait; i++) {
> ...
> msleep(1000);
> ...
> dev_info(&instance->pdev->dev, "FW now in Ready state\n");
>
> This is a regression, caused by a change of the msleep granularity from 1 to
> 1000 due to concern about waiting too long on systems with coarse jiffies.
>
> To fix, increase iterations and use msleep(20), which results in:
>
> [2.670627] megaraid_sas :03:00.0: Waiting for FW to come to ready state
> [2.739386] megaraid_sas :03:00.0: FW now in Ready state
>
> Fixes: fb2f3e96d80f ("scsi: megaraid_sas: Fix msleep granularity")
> Signed-off-by: Steve Sistare
Acked-by: Sumit Saxena
> ---
> drivers/scsi/megaraid/megaraid_sas_base.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index a30c1b3..a707af5 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -3932,12 +3932,12 @@ static irqreturn_t megasas_isr(int irq, void *devp)
> /*
> * The cur_state should not last for more than max_wait secs
> */
> - for (i = 0; i < max_wait; i++) {
> + for (i = 0; i < max_wait * 50; i++) {
> curr_abs_state = instance->instancet->
> read_fw_status_reg(instance);
>
> if (abs_state == curr_abs_state) {
> - msleep(1000);
> + msleep(20);
> } else
> break;
> }
> --
> 1.8.3.1
>
Re: [PATCH -next] scsi: megaraid_sas: Remove a bunch of set but not used variables
On Fri, Feb 22, 2019 at 7:30 AM Yue Haibing wrote:
>
> From: YueHaibing
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/scsi/megaraid/megaraid_sas_fusion.c: In function 'wait_and_poll':
> drivers/scsi/megaraid/megaraid_sas_fusion.c:936:25: warning:
> variable 'fusion' set but not used [-Wunused-but-set-variable]
>
> drivers/scsi/megaraid/megaraid_sas_fusion.c: In function
> 'megasas_sync_map_info':
> drivers/scsi/megaraid/megaraid_sas_fusion.c:1329:6: warning:
> variable 'size_sync_info' set but not used [-Wunused-but-set-variable]
>
> drivers/scsi/megaraid/megaraid_sas_fusion.c: In function
> 'megasas_init_adapter_fusion':
> drivers/scsi/megaraid/megaraid_sas_fusion.c:1639:39: warning:
> variable 'reg_set' set but not used [-Wunused-but-set-variable]
>
> drivers/scsi/megaraid/megaraid_sas_fusion.c: In function
> 'megasas_is_prp_possible':
> drivers/scsi/megaraid/megaraid_sas_fusion.c:1925:25: warning:
> variable 'fusion' set but not used [-Wunused-but-set-variable]
>
> drivers/scsi/megaraid/megaraid_sas_fusion.c: In function
> 'megasas_make_prp_nvme':
> drivers/scsi/megaraid/megaraid_sas_fusion.c:2047:25: warning:
> variable 'fusion' set but not used [-Wunused-but-set-variable]
>
> drivers/scsi/megaraid/megaraid_sas_fusion.c: In function
> 'megasas_build_ldio_fusion':
> drivers/scsi/megaraid/megaraid_sas_fusion.c:2620:42: warning:
> variable 'req_desc' set but not used [-Wunused-but-set-variable]
>
> drivers/scsi/megaraid/megaraid_sas_fusion.c: In function
> 'megasas_build_and_issue_cmd_fusion':
> drivers/scsi/megaraid/megaraid_sas_fusion.c:3245:25: warning:
> variable 'fusion' set but not used [-Wunused-but-set-variable]
>
> drivers/scsi/megaraid/megaraid_sas_fusion.c: In function
> 'megasas_task_abort_fusion':
> drivers/scsi/megaraid/megaraid_sas_fusion.c:4398:25: warning:
> variable 'fusion' set but not used [-Wunused-but-set-variable]
>
> drivers/scsi/megaraid/megaraid_sas_fusion.c: In function
> 'megasas_reset_target_fusion':
> drivers/scsi/megaraid/megaraid_sas_fusion.c:4484:25: warning:
> variable 'fusion' set but not used [-Wunused-but-set-variable]
>
> They're not used anymore and can be removed.
>
> Signed-off-by: YueHaibing
Acked-by: Sumit Saxena
> ---
> drivers/scsi/megaraid/megaraid_sas_fusion.c | 26 --
> 1 file changed, 26 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> index fd44e00..1d17128 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> @@ -937,11 +937,9 @@ wait_and_poll(struct megasas_instance *instance, struct
> megasas_cmd *cmd,
> {
> int i;
> struct megasas_header *frame_hdr = &cmd->frame->hdr;
> - struct fusion_context *fusion;
>
> u32 msecs = seconds * 1000;
>
> - fusion = instance->ctrl_context;
> /*
> * Wait for cmd_status to change
> */
> @@ -1331,7 +1329,6 @@ megasas_sync_map_info(struct megasas_instance *instance)
> struct megasas_cmd *cmd;
> struct megasas_dcmd_frame *dcmd;
> u16 num_lds;
> - u32 size_sync_info;
> struct fusion_context *fusion;
> struct MR_LD_TARGET_SYNC *ci = NULL;
> struct MR_DRV_RAID_MAP_ALL *map;
> @@ -1360,8 +1357,6 @@ megasas_sync_map_info(struct megasas_instance *instance)
>
> dcmd = &cmd->frame->dcmd;
>
> - size_sync_info = sizeof(struct MR_LD_TARGET_SYNC) *num_lds;
> -
> memset(dcmd->mbox.b, 0, MFI_MBOX_SIZE);
>
> ci = (struct MR_LD_TARGET_SYNC *)
> @@ -1640,15 +1635,12 @@ static inline void megasas_free_ioc_init_cmd(struct
> megasas_instance *instance)
> u32
> megasas_init_adapter_fusion(struct megasas_instance *instance)
> {
> - struct megasas_register_set __iomem *reg_set;
> struct fusion_context *fusion;
> u32 scratch_pad_1;
> int i = 0, count;
>
> fusion = instance->ctrl_context;
>
> - reg_set = instance->reg_set;
> -
> megasas_fusion_update_can_queue(instance, PROBE_CONTEXT);
>
> /*
> @@ -1927,7 +1919,6 @@ static bool
> megasas_is_prp_possible(struct megasas_instance *instance,
> struct scsi_cmnd *scmd, int sge_count)
> {
> - struct fusion_context *fusion;
> int i;
> u32 data_length = 0;
> struct scat
Re: [PATCH] scsi: megaraid_sas: return error when create DMA pool failed in megasas_alloc_cmds()
On Fri, Feb 15, 2019 at 5:22 PM Jason Yan wrote:
>
> when create DMA pool for cmd frames failed, we should return -ENOMEM,
> instead of 0.
> In some case in:
>
> megasas_init_adapter_fusion()
>
> -->megasas_alloc_cmds()
>-->megasas_create_frame_pool
> create DMA pool failed,
> --> megasas_free_cmds() [1]
>
> -->megasas_alloc_cmds_fusion()
>failed, then goto fail_alloc_cmds.
> -->megasas_free_cmds() [2]
>
> we will call megasas_free_cmds twice, [1] will kfree cmd_list,
> [2] will use cmd_list.it will cause a problem:
>
> Unable to handle kernel NULL pointer dereference at virtual address
>
> pgd = ffc000f7
> [] *pgd=001fbf893003, *pud=001fbf893003,
> *pmd=001fbf894003, *pte=00606d000707
> Internal error: Oops: 9605 [#1] SMP
> Modules linked in:
> CPU: 18 PID: 1 Comm: swapper/0 Not tainted
> task: ffdfb929 ti: ffdfb923c000 task.ti: ffdfb923c000
> PC is at megasas_free_cmds+0x30/0x70
> LR is at megasas_free_cmds+0x24/0x70
> ...
> Call trace:
> [] megasas_free_cmds+0x30/0x70
> [] megasas_init_adapter_fusion+0x2f4/0x4d8
> [] megasas_init_fw+0x2dc/0x760
> [] megasas_probe_one+0x3c0/0xcd8
> [] local_pci_probe+0x4c/0xb4
> [] pci_device_probe+0x11c/0x14c
> [] driver_probe_device+0x1ec/0x430
> [] __driver_attach+0xa8/0xb0
> [] bus_for_each_dev+0x74/0xc8
> [] driver_attach+0x28/0x34
> [] bus_add_driver+0x16c/0x248
> [] driver_register+0x6c/0x138
> [] __pci_register_driver+0x5c/0x6c
> [] megasas_init+0xc0/0x1a8
> [] do_one_initcall+0xe8/0x1ec
> [] kernel_init_freeable+0x1c8/0x284
> [] kernel_init+0x1c/0xe4
>
> Signed-off-by: Jason Yan
Thanks for fixing this.
Acked-by: Sumit Saxena
> ---
> drivers/scsi/megaraid/megaraid_sas_base.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index fcbff83c0097..c9811d1aa007 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -4188,6 +4188,7 @@ int megasas_alloc_cmds(struct megasas_instance
> *instance)
> if (megasas_create_frame_pool(instance)) {
> dev_printk(KERN_DEBUG, &instance->pdev->dev, "Error creating
> frame DMA pool\n");
> megasas_free_cmds(instance);
> + return -ENOMEM;
> }
>
> return 0;
> --
> 2.14.4
>
Re: [RESEND PATCH v2] megaraid: fix out-of-bound array accesses
On Thu, Dec 13, 2018 at 6:57 PM Qian Cai wrote:
>
> UBSAN reported those with MegaRAID SAS-3 3108,
>
> [ 77.467308] UBSAN: Undefined behaviour in
> drivers/scsi/megaraid/megaraid_sas_fp.c:117:32
> [ 77.475402] index 255 is out of range for type 'MR_LD_SPAN_MAP [1]'
> [ 77.481677] CPU: 16 PID: 333 Comm: kworker/16:1 Not tainted 4.20.0-rc5+ #1
> [ 77.488556] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.50
> 06/01/2018
> [ 77.495791] Workqueue: events work_for_cpu_fn
> [ 77.500154] Call trace:
> [ 77.502610] dump_backtrace+0x0/0x2c8
> [ 77.506279] show_stack+0x24/0x30
> [ 77.509604] dump_stack+0x118/0x19c
> [ 77.513098] ubsan_epilogue+0x14/0x60
> [ 77.516765] __ubsan_handle_out_of_bounds+0xfc/0x13c
> [ 77.521767] mr_update_load_balance_params+0x150/0x158 [megaraid_sas]
> [ 77.528230] MR_ValidateMapInfo+0x2cc/0x10d0 [megaraid_sas]
> [ 77.533825] megasas_get_map_info+0x244/0x2f0 [megaraid_sas]
> [ 77.539505] megasas_init_adapter_fusion+0x9b0/0xf48 [megaraid_sas]
> [ 77.545794] megasas_init_fw+0x1ab4/0x3518 [megaraid_sas]
> [ 77.551212] megasas_probe_one+0x2c4/0xbe0 [megaraid_sas]
> [ 77.556614] local_pci_probe+0x7c/0xf0
> [ 77.560365] work_for_cpu_fn+0x34/0x50
> [ 77.564118] process_one_work+0x61c/0xf08
> [ 77.568129] worker_thread+0x534/0xa70
> [ 77.571882] kthread+0x1c8/0x1d0
> [ 77.575114] ret_from_fork+0x10/0x1c
>
> [ 89.240332] UBSAN: Undefined behaviour in
> drivers/scsi/megaraid/megaraid_sas_fp.c:117:32
> [ 89.248426] index 255 is out of range for type 'MR_LD_SPAN_MAP [1]'
> [ 89.254700] CPU: 16 PID: 95 Comm: kworker/u130:0 Not tainted 4.20.0-rc5+ #1
> [ 89.261665] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.50
> 06/01/2018
> [ 89.268903] Workqueue: events_unbound async_run_entry_fn
> [ 89.274222] Call trace:
> [ 89.276680] dump_backtrace+0x0/0x2c8
> [ 89.280348] show_stack+0x24/0x30
> [ 89.283671] dump_stack+0x118/0x19c
> [ 89.287167] ubsan_epilogue+0x14/0x60
> [ 89.290835] __ubsan_handle_out_of_bounds+0xfc/0x13c
> [ 89.295828] MR_LdRaidGet+0x50/0x58 [megaraid_sas]
> [ 89.300638] megasas_build_io_fusion+0xbb8/0xd90 [megaraid_sas]
> [ 89.306576] megasas_build_and_issue_cmd_fusion+0x138/0x460 [megaraid_sas]
> [ 89.313468] megasas_queue_command+0x398/0x3d0 [megaraid_sas]
> [ 89.319222] scsi_dispatch_cmd+0x1dc/0x8a8
> [ 89.323321] scsi_request_fn+0x8e8/0xdd0
> [ 89.327249] __blk_run_queue+0xc4/0x158
> [ 89.331090] blk_execute_rq_nowait+0xf4/0x158
> [ 89.335449] blk_execute_rq+0xdc/0x158
> [ 89.339202] __scsi_execute+0x130/0x258
> [ 89.343041] scsi_probe_and_add_lun+0x2fc/0x1488
> [ 89.347661] __scsi_scan_target+0x1cc/0x8c8
> [ 89.351848] scsi_scan_channel.part.3+0x8c/0xc0
> [ 89.356382] scsi_scan_host_selected+0x130/0x1f0
> [ 89.361002] do_scsi_scan_host+0xd8/0xf0
> [ 89.364927] do_scan_async+0x9c/0x320
> [ 89.368594] async_run_entry_fn+0x138/0x420
> [ 89.372780] process_one_work+0x61c/0xf08
> [ 89.376793] worker_thread+0x13c/0xa70
> [ 89.380546] kthread+0x1c8/0x1d0
> [ 89.383778] ret_from_fork+0x10/0x1c
>
> This is because when populating Driver Map using firmware raid map, all
> non-existing VDs set their ldTgtIdToLd to 0xff, so it can be skipped
> later.
>
> From drivers/scsi/megaraid/megaraid_sas_base.c ,
> memset(instance->ld_ids, 0xff, MEGASAS_MAX_LD_IDS);
>
> From drivers/scsi/megaraid/megaraid_sas_fp.c ,
> /* For non existing VDs, iterate to next VD*/
> if (ld >= (MAX_LOGICAL_DRIVES_EXT - 1))
> continue;
>
> However, there are a few places that failed to skip those non-existing
> VDs due to off-by-one errors. Then, those 0xff leaked into
> MR_LdRaidGet(0xff, map) and triggered the out-of-bound accesses.
>
> Fixes: 51087a8617fe (megaraid_sas : Extended VD support)
> Signed-off-by: Qian Cai
Acked-by: Sumit Saxena
> ---
> drivers/scsi/megaraid/megaraid_sas_fp.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_fp.c
> b/drivers/scsi/megaraid/megaraid_sas_fp.c
> index 59ecbb3b53b5..a33628550425 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_fp.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_fp.c
> @@ -1266,7 +1266,7 @@ void mr_update_load_balance_params(struct
> MR_DRV_RAID_MAP_ALL *drv_map,
>
> for (ldCount = 0; ldCount < MAX_LOGICAL_DRIVES_EXT; ldCount++) {
> ld = MR_TargetIdToLdGet(ldCount, drv_map);
> - if (ld >= MAX_LOGICAL_DRIVES_EXT) {
> + if (ld >= MAX_LOGICAL_DRIVES_EXT - 1) {
>
Re: [PATCH] scsi: megaraid_sas: NULL check before some freeing functions is not needed.
On Mon, Dec 3, 2018 at 2:25 AM Thomas Meyer wrote: > > NULL check before some freeing functions is not needed. > > Signed-off-by: Thomas Meyer Acked-by: Sumit Saxena > --- > > diff -u -p a/drivers/scsi/megaraid/megaraid_mbox.c > b/drivers/scsi/megaraid/megaraid_mbox.c > --- a/drivers/scsi/megaraid/megaraid_mbox.c > +++ b/drivers/scsi/megaraid/megaraid_mbox.c > @@ -1243,8 +1243,7 @@ megaraid_mbox_teardown_dma_pools(adapter > dma_pool_free(raid_dev->sg_pool_handle, sg_pci_blk[i].vaddr, > sg_pci_blk[i].dma_addr); > } > - if (raid_dev->sg_pool_handle) > - dma_pool_destroy(raid_dev->sg_pool_handle); > + dma_pool_destroy(raid_dev->sg_pool_handle); > > > epthru_pci_blk = raid_dev->epthru_pool; > @@ -1252,8 +1251,7 @@ megaraid_mbox_teardown_dma_pools(adapter > dma_pool_free(raid_dev->epthru_pool_handle, > epthru_pci_blk[i].vaddr, epthru_pci_blk[i].dma_addr); > } > - if (raid_dev->epthru_pool_handle) > - dma_pool_destroy(raid_dev->epthru_pool_handle); > + dma_pool_destroy(raid_dev->epthru_pool_handle); > > > mbox_pci_blk = raid_dev->mbox_pool; > @@ -1261,8 +1259,7 @@ megaraid_mbox_teardown_dma_pools(adapter > dma_pool_free(raid_dev->mbox_pool_handle, > mbox_pci_blk[i].vaddr, mbox_pci_blk[i].dma_addr); > } > - if (raid_dev->mbox_pool_handle) > - dma_pool_destroy(raid_dev->mbox_pool_handle); > + dma_pool_destroy(raid_dev->mbox_pool_handle); > > return; > } > diff -u -p a/drivers/scsi/megaraid/megaraid_mm.c > b/drivers/scsi/megaraid/megaraid_mm.c > --- a/drivers/scsi/megaraid/megaraid_mm.c > +++ b/drivers/scsi/megaraid/megaraid_mm.c > @@ -1017,8 +1017,7 @@ memalloc_error: > kfree(adapter->kioc_list); > kfree(adapter->mbox_list); > > - if (adapter->pthru_dma_pool) > - dma_pool_destroy(adapter->pthru_dma_pool); > + dma_pool_destroy(adapter->pthru_dma_pool); > > kfree(adapter); > > diff -u -p a/drivers/scsi/megaraid/megaraid_sas_fusion.c > b/drivers/scsi/megaraid/megaraid_sas_fusion.c > --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c > +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c > @@ -807,10 +807,8 @@ megasas_free_rdpq_fusion(struct megasas_ > > } > > - if (fusion->reply_frames_desc_pool) > - dma_pool_destroy(fusion->reply_frames_desc_pool); > - if (fusion->reply_frames_desc_pool_align) > - dma_pool_destroy(fusion->reply_frames_desc_pool_align); > + dma_pool_destroy(fusion->reply_frames_desc_pool); > + dma_pool_destroy(fusion->reply_frames_desc_pool_align); > > if (fusion->rdpq_virt) > dma_free_coherent(&instance->pdev->dev, > @@ -830,8 +828,7 @@ megasas_free_reply_fusion(struct megasas > fusion->reply_frames_desc[0], > fusion->reply_frames_desc_phys[0]); > > - if (fusion->reply_frames_desc_pool) > - dma_pool_destroy(fusion->reply_frames_desc_pool); > + dma_pool_destroy(fusion->reply_frames_desc_pool); > > } > > @@ -1627,8 +1624,7 @@ static inline void megasas_free_ioc_init > fusion->ioc_init_cmd->frame, > fusion->ioc_init_cmd->frame_phys_addr); > > - if (fusion->ioc_init_cmd) > - kfree(fusion->ioc_init_cmd); > + kfree(fusion->ioc_init_cmd); > } > > /** > >
Re: [PATCH 30/41] scsi: megaraid_sas_fusion: Mark expected switch fall-through
On Wed, Nov 28, 2018 at 10:02 AM Gustavo A. R. Silva
wrote:
>
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Notice that, in this particular case, I replaced "Fall thru" with a
> "Fall through" annotation and added a dash as a token in order to
> separate the "Fall through" annotation from the rest of the comment
> on the same line, which is what GCC is expecting to find.
>
> Signed-off-by: Gustavo A. R. Silva
Acked-by: Sumit Saxena
> ---
> 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 c5e6bccb0895..8f37ad83be9a 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> @@ -3453,7 +3453,7 @@ complete_cmd_fusion(struct megasas_instance *instance,
> u32 MSIxIndex)
>
> atomic_dec(&lbinfo->scsi_pending_cmds[cmd_fusion->pd_r1_lb]);
> cmd_fusion->scmd->SCp.Status &=
> ~MEGASAS_LOAD_BALANCE_FLAG;
> }
> - //Fall thru and complete IO
> + /* Fall through - and complete IO */
> case MEGASAS_MPI2_FUNCTION_LD_IO_REQUEST: /* LD-IO Path */
> atomic_dec(&instance->fw_outstanding);
> if (cmd_fusion->r1_alt_dev_handle ==
> MR_DEVHANDLE_INVALID) {
> --
> 2.17.1
>
Re: [PATCH 29/41] scsi: megaraid: megaraid_sas_base: Mark expected switch fall-through
On Wed, Nov 28, 2018 at 10:02 AM Gustavo A. R. Silva wrote: > > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > Signed-off-by: Gustavo A. R. Silva Acked-by: Sumit Saxena > --- > drivers/scsi/megaraid/megaraid_sas_base.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c > b/drivers/scsi/megaraid/megaraid_sas_base.c > index b7d3fc6fb118..9db7aebc3564 100644 > --- a/drivers/scsi/megaraid/megaraid_sas_base.c > +++ b/drivers/scsi/megaraid/megaraid_sas_base.c > @@ -3281,6 +3281,7 @@ megasas_complete_cmd(struct megasas_instance *instance, > struct megasas_cmd *cmd, > megasas_complete_int_cmd(instance, cmd); > break; > } > + /* fall through */ > > case MFI_CMD_LD_READ: > case MFI_CMD_LD_WRITE: > -- > 2.17.1 >
Re: [PATCH 13/28] megaraid_sas: switch to generic DMA API
gt; *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,
> - &fusion->rdpq_phys);
> + fusion->rdpq_virt = dma_zalloc_coherent(&instance->pdev->dev,
> + array_size, &fusion->rdpq_phys, GFP_KERNEL);
> if (!fusion->rdpq_virt) {
> dev_err(&instance->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(&instance->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_sas: fix a missing-check bug
On Sun, Oct 7, 2018 at 12:04 AM Wenwen Wang wrote:
>
> In megasas_mgmt_compat_ioctl_fw(), to handle the structure
> compat_megasas_iocpacket 'cioc', a user-space structure megasas_iocpacket
> 'ioc' is allocated before megasas_mgmt_ioctl_fw() is invoked to handle the
> packet. Since the two data structures have different fields, the data is
> copied from 'cioc' to 'ioc' field by field. In the copy process,
> 'sense_ptr' is prepared if the field 'sense_len' is not null, because it
> will be used in megasas_mgmt_ioctl_fw(). To prepare 'sense_ptr', the
> user-space data 'ioc->sense_off' and 'cioc->sense_off' are copied and saved
> to kernel-space variables 'local_sense_off' and 'user_sense_off'
> respectively. Given that 'ioc->sense_off' is also copied from
> 'cioc->sense_off', 'local_sense_off' and 'user_sense_off' should have the
> same value. However, 'cioc' is in the user space and a malicious user can
> race to change the value of 'cioc->sense_off' after it is copied to
> 'ioc->sense_off' but before it is copied to 'user_sense_off'. By doing so,
> the attacker can inject different values into 'local_sense_off' and
> 'user_sense_off'. This can cause undefined behavior in the following
> execution, because the two variables are supposed to be same.
>
> This patch enforces a check on the two kernel variables 'local_sense_off'
> and 'user_sense_off' to make sure they are the same after the copy. In case
> they are not, an error code EINVAL will be returned.
>
> Signed-off-by: Wenwen Wang
> ---
> drivers/scsi/megaraid/megaraid_sas_base.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index 9aa9590..f6de752 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -7523,6 +7523,9 @@ static int megasas_mgmt_compat_ioctl_fw(struct file
> *file, unsigned long arg)
> get_user(user_sense_off, &cioc->sense_off))
> return -EFAULT;
>
> + if (local_sense_off != user_sense_off)
> + return -EINVAL;
> +
> if (local_sense_len) {
> void __user **sense_ioc_ptr =
> (void __user **)((u8 *)((unsigned
> long)&ioc->frame.raw) + local_sense_off);
Acked-by: Sumit Saxena
> --
> 2.7.4
>
RE: [PATCH] scsi: megaraid: fix spelling mistake "maibox" -> "mailbox"
> -Original Message-
> From: Colin King [mailto:colin.k...@canonical.com]
> Sent: Monday, September 24, 2018 3:56 AM
> To: Kashyap Desai ; Sumit Saxena
> ; Shivasharan S
> ; James E . J . Bottomley
> ; Martin K . Petersen
> ; megaraidlinux@broadcom.com; linux-
> s...@vger.kernel.org
> Cc: kernel-janit...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: [PATCH] scsi: megaraid: fix spelling mistake "maibox" ->
> "mailbox"
>
> From: Colin Ian King
>
> Trivial fix to spelling mistake in warning message and comments
>
> Signed-off-by: Colin Ian King
> ---
> drivers/scsi/megaraid/megaraid_mbox.c | 4 ++--
> drivers/scsi/megaraid/megaraid_mbox.h | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_mbox.c
> b/drivers/scsi/megaraid/megaraid_mbox.c
> index 530358cdcb39..2013523605c5 100644
> --- a/drivers/scsi/megaraid/megaraid_mbox.c
> +++ b/drivers/scsi/megaraid/megaraid_mbox.c
> @@ -484,7 +484,7 @@ megaraid_probe_one(struct pci_dev *pdev, const
> struct pci_device_id *id)
> // Start the mailbox based controller
> if (megaraid_init_mbox(adapter) != 0) {
> con_log(CL_ANN, (KERN_WARNING
> - "megaraid: maibox adapter did not initialize\n"));
> + "megaraid: mailbox adapter did not initialize\n"));
>
> goto out_free_adapter;
> }
> @@ -950,7 +950,7 @@ megaraid_fini_mbox(adapter_t *adapter)
> * megaraid_alloc_cmd_packets - allocate shared mailbox
> * @adapter : soft state of the raid controller
> *
> - * Allocate and align the shared mailbox. This maibox is used to issue
> + * Allocate and align the shared mailbox. This mailbox is used to issue
> * all the commands. For IO based controllers, the mailbox is also
> registered
> * with the FW. Allocate memory for all commands as well.
> * This is our big allocator.
> diff --git a/drivers/scsi/megaraid/megaraid_mbox.h
> b/drivers/scsi/megaraid/megaraid_mbox.h
> index c1d86d961a92..e075aeb4012f 100644
> --- a/drivers/scsi/megaraid/megaraid_mbox.h
> +++ b/drivers/scsi/megaraid/megaraid_mbox.h
> @@ -117,7 +117,7 @@
> * @raw_mbox : raw mailbox pointer
> * @mbox : mailbox
> * @mbox64 : extended mailbox
> - * @mbox_dma_h : maibox dma address
> + * @mbox_dma_h : mailbox dma address
> * @sgl64: 64-bit scatter-gather list
> * @sgl32: 32-bit scatter-gather list
> * @sgl_dma_h: dma handle for the scatter-gather list
Acked-by: Sumit Saxena
> --
> 2.17.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 --- 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, &cmd->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 -- 1.9.1
RE: [PATCH] [RESEND] megaraid: use ktime_get_real for firmware time
-Original Message- From: Arnd Bergmann [mailto:a...@arndb.de] Sent: Wednesday, January 17, 2018 8:19 PM To: Kashyap Desai; Sumit Saxena; Shivasharan S; James E.J. Bottomley; Martin K. Petersen Cc: Arnd Bergmann; Tomas Henzl; Hannes Reinecke; megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org; linux-ker...@vger.kernel.org Subject: [PATCH] [RESEND] megaraid: use ktime_get_real for firmware time do_gettimeofday() overflows in 2038 on 32-bit architectures and is deprecated, so convert this driver to call ktime_get_real() directly. This also simplifies the calculation. Signed-off-by: Arnd Bergmann --- Sent originally in Nov 2017, no comments. Please apply --- drivers/scsi/megaraid/megaraid_sas_fusion.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c b/drivers/scsi/megaraid/megaraid_sas_fusion.c index 0a85f3c48ef6..97fae28c8374 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c @@ -983,7 +983,7 @@ megasas_ioc_init_fusion(struct megasas_instance *instance) MFI_CAPABILITIES *drv_ops; u32 scratch_pad_2; unsigned long flags; - struct timeval tv; + ktime_t time; bool cur_fw_64bit_dma_capable; fusion = instance->ctrl_context; @@ -1042,10 +1042,9 @@ megasas_ioc_init_fusion(struct megasas_instance *instance) IOCInitMessage->HostMSIxVectors = instance->msix_vectors; IOCInitMessage->HostPageSize = MR_DEFAULT_NVME_PAGE_SHIFT; - do_gettimeofday(&tv); + time = ktime_get_real(); /* Convert to milliseconds as per FW requirement */ - IOCInitMessage->TimeStamp = cpu_to_le64((tv.tv_sec * 1000) + - (tv.tv_usec / 1000)); + IOCInitMessage->TimeStamp = cpu_to_le64(ktime_to_ms(time)); init_frame = (struct megasas_init_frame *)cmd->frame; memset(init_frame, 0, IOC_INIT_FRAME_SIZE); Looks good to me. Acked-by: Sumit Saxena -- 2.9.0
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
Cc: Sumit Saxena
Cc: Shivasharan S
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: megaraidlinux@broadcom.com
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook
---
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(&raid_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 = &sysfs_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(&timeout.timer,
+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(&timeout.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(&timeout.timer);
+ destroy_timer_on_stack(&timeout.timer);
mutex_unlock(&raid_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 *, uint8_t, int *); static int
lld_ioctl(mraid_mmadp_t *, uioc_t *); static void ioctl_done(uioc_t *);
-st
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 --- 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 -- 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
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
---
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(&instance->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
--
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
>---
> 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
>---
> 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(&instance->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_dev
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 >--- > 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), &instance->pd_info_h); > >- instance->pd_info = pci_alloc_consistent(pdev, >- sizeof(struct MR_PD_INFO), &instance->pd_info_h); >- instance->tgt_prop = pci_alloc_consistent(pdev, >- sizeof(struct MR_TARGET_PROPERTIES), &instance- >>tgt_prop_h); >- > if (!instance->pd_info) > dev_err(&instance->pdev->dev, "Failed to alloc mem >for pd_info\n"); > >+ instance->tgt_prop = pci_alloc_consistent(pdev, >+ sizeof(struct MR_TARGET_PROPERTIES), &instance- >>tgt_prop_h); >+ > if (!instance->tgt_prop) > dev_err(&instance->pdev->dev, "Failed to alloc mem >for tgt_prop\n"); Acked-by: Sumit Saxena > >-- >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(&instance->fw_outstanding) >
instance->host->can_queue) {
atomic_dec(&instance->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 >--- > 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 >-- >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
>---
> 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(&instance->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(&instance->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
>--
>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
>
>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
>---
> 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(&instance->pdev->dev,
> "Failed from %s %d\n", __func__,
__LINE__);
> return -ENOMEM;
> }
> }
>+
> return 0;
> }
> int
Acked-by: Sumit Saxena
>--
>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(&adapter->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(&adapter->dev->dev, "%s cmd=%x \n",
(aor == SCB_ABORT)? "ABORTING":"RESET",
cmd->cmnd[0],
cmd->device->channel,it should crash
here
cmd->device->id, (u32)cmd->device->lun);
Please correct if I am missing something here.
>
> /*
>* This is required here to complete any completed requests @@ -
>1948,7 +1948,7 @@ static DEF_SCSI_QCMD(megaraid_queue)
>
> scb = list_entry(pos, scb_t, list);
>
>- if (scb->cmd == cmd) { /* Found command */
>+ if (!cmd || scb->cmd == cmd) { /* Found command */
>
> scb->state |= aor;
>
>@@ -1967,31 +1967,23 @@ static DEF_SCSI_QCMD(megaraid_queue)
>
> return FAILED;
> }
>- else {
>-
>- /*
>- * Not yet issued! Remove from the pending
>- * list
>- */
>- dev_warn(&adapter->dev->dev,
>- "%s-[%x], driver owner\n",
>- (aor==SCB_ABORT) ?
>"ABORTING":"RESET",
>- scb->idx);
>-
>- mega_free_scb(adapter, scb);
>-
>- if( aor == SCB_ABORT ) {
>- cmd->result = (DID_ABORT << 16);
>- }
>- else {
>- cmd->result = (DID_RESET << 16);
>- }
>+ /*
>+ * Not yet issued! Remove from the pending
>+ * list
>+ */
>+ dev_warn(&adapter->dev->dev,
>+ "%s-[%x], driver owner\n",
>+ (cmd) ? "ABORTING":"RESET",
>+ scb->idx);
>+ mega_free_scb(adapter, scb);
>
>+ if (cmd) {
>+ cmd->result = (DID_ABORT << 16);
> list_add_tail(SCSI_LIST(cmd),
>- &adapter->completed_list);
>-
>- return SUCCESS;
>+&adapter->completed_list);
> }
>+
>+ return SUCCESS;
> }
> }
>
>@@ -4180,8 +4172,6 @@ static inline void mega_create_proc_entry(int
index,
>struct proc_dir_entry *pare
> .cmd_per_lun= DEF_CMD_PER_LUN,
> .use_clustering = ENABLE_CLUSTERING,
> .eh_abort_handler = megaraid_abort,
>- .eh_device_reset_handler= megaraid_reset,
>- .eh_bus_reset_handler = megaraid_reset,
> .eh_host_reset_handler = megaraid_reset,
> .no_write_same = 1,
> };
>--
>1.8.5.6
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 SCS
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 >--- > 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, > &kioc->buf_paddr); > spin_unlock_irqrestore(&pool->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 > >-- >1.7.9.5 >
RE: [PATCH v4 11/19] scsi: megaraid: Replace PCI pool old API
eate("mr_sg", &instance->pdev->dev,
> instance->max_chain_frame_sz,
> MR_DEFAULT_NVME_PAGE_SIZE, 0);
> /* SCSI_SENSE_BUFFERSIZE = 96 bytes */
> fusion->sense_dma_pool =
>- pci_pool_create("mr_sense", instance->pdev,
>+ dma_pool_create("mr_sense", &instance->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, &cmd-
>>sg_frame_phys_addr);
>
>- cmd->sense = pci_pool_alloc(fusion->sense_dma_pool,
>+ cmd->sense = dma_pool_alloc(fusion->sense_dma_pool,
> GFP_KERNEL,
&cmd->sense_phys_addr);
> if (!cmd->sg_frame || !cmd->sense) {
> dev_err(&instance->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, &cmd->sense_phys_addr);
> if (!cmd->sense) {
> dev_err(&instance->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", &instance->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, &fusion-
>>io_request_frames_phys);
> if (!fusion->io_request_frames) {
> dev_err(&instance->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", &instance->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, &fusion->reply_frames_desc_phys[0]);
> if (!fusion->reply_frames_desc[0]) {
> dev_err(&instance->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",
>+
&instance->pdev->dev,
>+
fusion->reply_alloc_sz,
>+ 16, 0);
>
> if (!fusion->reply_frames_desc_pool) {
> dev_err(&instance->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, &fusion-
>>reply_frames_desc_phys[i]);
> if (!fusion->reply_frames_desc[i]) {
> dev_err(&instance->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
>
>--
>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
>
>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
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
>---
> 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
>--
>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.
>
>Fixes: 33203bc4d61b ("scsi: megaraid_sas: NVME fast path io support")
>Signed-off-by: Arnd Bergmann
>---
> 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;
Looks good. Tested and it works as expected.
Acked-by: Sumit Saxena
>--
>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
>---
> 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
>
>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
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
Signed-off-by: Kashyap Desai
---
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(&instance->adprecovery) ==
MEGASAS_ADPRESET_SM_INFAULT) {
if (megasas_check_mpio_paths(instance, scmd) ==
- (DID_RESET << 16)) {
+ (DID
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
Signed-off-by: Kashyap Desai
---
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(&instance->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(&reset_cmd->list);
if (reset_cmd->scmd) {
- reset_cmd->scmd->result = DID_RESET << 16;
+ reset_cmd->scmd->result = DID_REQUEUE <<
16;
dev_notice(&insta
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 >--- > 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 >+M: Adam Radford > 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 >- Modifications By: Tom Couch >+ Written By: Adam Radford >+ 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 >- Modifications By: Tom Couch >+ Written By: Adam Radford >+ 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 >+ Written By: Adam Radford > >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 >+ Written By: Adam Radford > Acked-by: Sumit Saxena >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 >25aba16..26ab5c0 100644 >--- a/drivers/scsi/3w-.c >+++ b/drivers/scsi/3w-.c >@@ -1,7 +1,7 @@ > /* >3w-.c -- 3ware Storage Controller device driver for Linux. > >- Written By: Adam Radford >+ Written By: Adam Radford >Modifications By: Joel Jacobson > Arnaldo Carvalho de Melo >
RE: [PATCH] megaraid_sas: switch to pci_alloc_irq_vectors
megasas_instance *instance;
>+ int irq_flags = PCI_IRQ_LEGACY;
>
> instance = pci_get_drvdata(pdev);
> host = instance->host;
>@@ -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
> /**
>--
>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 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 > >-- >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
>---
> 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(&shost->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_s
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
>---
> 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 = &fusion->load_balance_info[device_id];
>- if (cmd_fusion->scmd->SCp.Status &
>- MEGASAS_LOAD_BALANCE_FLAG) {
>-
>atomic_dec(&lbinfo->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 =
>&fusion->load_balance_info[device_id];
>+ if (cmd_fusion->scmd->SCp.Status &
>+ MEGASAS_LOAD_BALANCE_FLAG) {
>+
>atomic_dec(&lbinfo->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(&instance->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
>---
> 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", &instance->irq_context[0])) {
>+ if (request_irq(pci_irq_vector(pdev, 0),
>+ instance->instancet->service_isr, IRQF_SHARED,
>+ "megasas", &instance->irq_context[0])) {
> dev_err(&instance->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",
> &instance->irq_context[i])) {
> dev_err(&instance->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,
>- &instance->irq_context[j]);
>- }
>+ for (j = 0; j < i; j++)
>+ free_irq(pci_irq_vector(pdev, j),
>+ &instance->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)))
>-
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 Acked-by: Sumit Saxena >--- > 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, &instance->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
Acked-by: Sumit Saxena
>---
> 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 int megasas_slave_alloc(struct scsi_device
*sdev) {
> u1
[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
CC: sta...@vger.kernel.org
Signed-off-by: Kashyap Desai
Signed-off-by: Sumit Saxena
Tested-by: Sumit Saxena
---
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 >--- > 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(&instance->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 >-- >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
Signed-off-by: Sumit Saxena
---
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_fusion.c
b/drivers/scsi/megaraid/megara
[PATCH v2 7/7] megaraid_sas: driver version upgrade
Signed-off-by: Sumit Saxena --- 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 Signed-off-by: Sumit Saxena Reviewed-by: Hannes Reinecke Reviewed-by: Tomas Henzl --- 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(&instance->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
Signed-off-by: Sumit Saxena
Reviewed-by: Hannes Reinecke
Reviewed-by: Tomas Henzl
---
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
Signed-off-by: Shivasharan Srikanteshwara
---
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(&instance->adprecovery) == MEGASAS_HW_CRITICAL_ERROR)
+ return 1;
+
+ for (i = 0; i < wait_time; i++) {
+ if (atomic_read(&instance->adprecovery) ==
MEGASAS_HBA_OPERATIONAL)
+ break;
+
+ if (!(i % MEGASAS_RESET_NOTICE_INTERVAL))
+ dev_notice(&instance->pdev->dev, "waiting for
controller reset to finish\n");
+
+ msleep(1000);
+ }
+
+ if (atomic_read(&instance->adprecovery) != MEGASAS_HBA_OPERATIONAL) {
+ dev_info(&instance->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(&instance->crash_init);
- else if (fw_state == MFI_STATE_FAULT)
- schedule_work(&instance->work_init);
+ else if (fw_state == MFI_STATE_FAULT) {
+ if (instance->unload == 0)
+ schedule_work(&instance->work_init);
+ }
} else if (fw_state == MFI_STATE_FAULT) {
dev_warn(&instance->pdev->dev, "Iop2SysDoorbellInt"
"for scsi%d\n", instance->host->host_no);
- schedule_work(&instance->work_init);
+ if (instance->unload == 0)
+ schedule_work(&instance->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 Reviewed-by: Hannes Reinecke --- 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 -M: Sumit Saxena -M: Uday Lingala -L: megaraidlinux@avagotech.com +M: Kashyap Desai +M: Sumit Saxena +M: Shivasharan S +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
Reviewed-by: Hannes Reinecke
Reviewed-by: Tomas Henzl
---
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
>> > > > > > > Signed-off-by: Kashyap Desai
>> > > > > > > ---
>> > > > > > >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
>> > > > > > >* structure extended for 1078 registers @@ -2140,6
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
>>>>> Signed-off-by: Kashyap Desai
>>>>> ---
>>>>> 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
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
>>>> Signed-off-by: Kashyap Desai
>>>> ---
>>>> 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
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
>>> Signed-off-by: Kashyap Desai
>>> ---
>>> 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/megaraid_sas_fusion.c
>>> b/drivers/scsi/megaraid/megaraid_sas_fusion
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
>> Signed-off-by: Kashyap Desai
>> ---
>> 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);
>> diff --git a/drivers/scsi/megaraid/megaraid_sas_fusi
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 >> --- >> 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
>> ---
>> 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(&instance->adprecovery)
>> +== MEGASAS_HBA_OPERATIONAL)
>> +break;
>> +
>> +if (!(i % MEGASAS_RESET_NOTICE_INTERVAL))
>> +dev_notice(&instance->pdev->dev, "waiting for
>controller reset to
>> +finish\n");
>> +
>> +msleep(1000);
>> +}
>> +
>> +if (atomic_read(&instance->adprecovery) !=
>MEGASAS_HBA_OPERATIONAL) {
>> +dev_info(&instance->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(&instance->adprecovery) ==
>MEGASAS_HW_CRITICAL_ERROR)
>> +|| ((atomic_read(&instance->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
>> Signed-off-by: Kashyap Desai
>> ---
>> 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_pad_2 &
>> +MR_CAN_HANDLE_SYNC_CACHE
[PATCH 5/7] megaraid_sas: driver version upgrade
Upgrade driver version. Signed-off-by: Sumit Saxena --- 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
Signed-off-by: Kashyap Desai
---
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 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
Signed-off-by: Kashyap Desai
---
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(&instance->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 6/7] MAINTAINERS: Update megaraid maintainers list
Update MEGARAID drivers maintainers list. Signed-off-by: Sumit Saxena --- 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 -M: Sumit Saxena -M: Uday Lingala -L: megaraidlinux@avagotech.com +M: Kashyap Desai +M: Sumit Saxena +M: Shivasharan S +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 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
Signed-off-by: Sumit Saxena
---
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 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 Signed-off-by: Sumit Saxena --- 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(&instance->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 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
---
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(&instance->adprecovery)
+ == MEGASAS_HBA_OPERATIONAL)
+ break;
+
+ if (!(i % MEGASAS_RESET_NOTICE_INTERVAL))
+ dev_notice(&instance->pdev->dev, "waiting for
controller reset to finish\n");
+
+ msleep(1000);
+ }
+
+ if (atomic_read(&instance->adprecovery) != MEGASAS_HBA_OPERATIONAL) {
+ dev_info(&instance->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(&instance->adprecovery) == MEGASAS_HW_CRITICAL_ERROR)
+ || ((atomic_read(&instance->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(&instance->adprecovery) == MEGASAS_HW_CRITICAL_ERROR)
+ || ((atomic_read(&instance->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(&instance->crash_init);
- else if (fw_state == MFI_STATE_FAULT)
- schedule_work(&instance->work_init);
+ else if (fw_state == MFI_STATE_FAULT) {
+ if (instance->unload == 0)
+ schedule_work(&instance->work_init);
+ }
} else if (fw_state == MFI_STATE_FAULT) {
dev_warn(&instance->pdev->dev, "Iop2SysDoorbellInt"
"for scsi%d\n", instance->host->host_no);
- schedule_work(&instance->work_init);
+ if (instance->unload == 0)
+ schedule_work(&instance->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 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
union MEGASAS_REQUEST_DESCRIPTOR_UNION *req_desc; @@ -
>2574,7 +2574,7 @@ 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
>
>--
>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
>---
> 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
>--
>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
>
>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
>---
> 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,
>&instance->consumer_h);
>
> if (!instance->producer || !instance->consumer) {
>- dev_printk(KERN_DEBUG, &pdev->dev, "Failed to
>allocate"
>+ dev_printk(KERN_DEBUG, &pdev->dev, "Failed to
>allocate "
> "memory for producer, consumer\n");
> goto fail_alloc_dma_buf;
> }
Acked-by: Sumit Saxena
>--
>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
>---
>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(&bar_list, sizeof(unsigned long));
>+ instance->bar = find_first_bit(&bar_list, BITS_PER_LONG);
> if (pci_request_selected_regions(instance->pdev, 1<bar,
>"megasas: LSI")) {
> dev_printk(KERN_DEBUG, &instance->pdev->dev, "IO memory
>region busy!\n");
Acked by: Sumit Saxena
>--
>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
>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
>---
> 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
>--
>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
Cc:
Signed-off-by: Sumit Saxena
---
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(&instance->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
> Cc:
> Signed-off-by: Sumit Saxena
>
> ---
> 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(&instance->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
Cc:
Signed-off-by: Sumit Saxena
---
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(&instance->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(&instance->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 > --- > > 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(&instance->pdev->dev, "INIT adapter done\n"); > + dev_info(&instance->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(&instance->pdev->dev, "Init cmd success\n"); > + dev_info(&instance->pdev->dev, "Init cmd success\n"); > > ret = 0; Acked-by: Sumit Saxena > > -- > 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 --- 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
---
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
---
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(&instance->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(&instance->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
---
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),
- &instance->system_info_h);
-
- if (!instance->system_info_buf)
- dev_info(&instance->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(&instance->crashdump_lock);
instance->crash_dump_buf = NULL;
- if (!reset_devices)
- instance->crash_dump_buf = pci_alloc_consistent(pdev,
- CRASH_DMA_BUF_SIZE,
- &instance->crash_dump_h);
- if (!instance->crash_dump_buf)
- dev_err(&pdev->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), &instance->pd_info_h);
+ if (!reset_devices) {
+ instance->system_info_buf = pci_zalloc_consistent(pdev,
+ sizeof(struct MR_DRV_SYSTEM_INFO),
+ &instance->system_info_h);
+ if (!instance->system_info_buf)
+ dev_info(&instance->pdev->dev, "Can't allocate system
info buffer\n");
+
+ instance->pd_info = pci_alloc_consistent(pdev,
+ sizeof(struct MR_PD_INFO), &instance->pd_info_h);
- if (!instance->pd_info)
- dev_err(&instance->pdev->dev, "Failed to alloc mem for
pd_info\n");
+ if (!instance->pd_info)
+ dev_err(&instance->pdev->dev, "Failed to alloc mem for
pd_info\n");
+
+ instance->crash_dump_buf = pci_alloc_consistent(pdev,
+ CRASH_DMA_BUF_SIZE,
+ &instance->crash_dump_h);
+ if (!instance->crash_dump_buf)
+ dev_err(&pdev->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/driver
[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
>
> 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
> ---
> 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(&instance->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
> --
> 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
> 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(&instance->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
> --
> 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
---
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(&instance->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 = &megasas_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: Thursday, February 04, 2016 8:07 AM > To: Sumit Saxena > Cc: Martin K. Petersen; Maurizio Lombardi; sumit.sax...@broadcom.com; > kashyap.de...@broadcom.com; uday.ling...@broadcom.com; linux- > s...@vger.kernel.org; James Bottomley; the...@redhat.com > Subject: Re: [PATCH] megaraid: fix null pointer check in megasas_detach_one(). > > >>>>> "Sumit" == Sumit Saxena writes: > > Sumit, > > Sumit> Patch looks good but it needs to be rebased with latest repo as > Sumit> very recently you have checked in few megaraid_sas patches and > Sumit> there are two critical patches for megaraid_sas are yet pending. > > You still need to respond to Tomas' comments to: > > [PATCH 1/2] megaraid_sas: Fix for IO failing post OCR in SRIOV environment Sorry for delay. I responded to Tomas query. > > Sumit> Once we get status of those two outstanding patches, I will ask > Sumit> submitter to rebase and send this patch again or I will be > Sumit> resending. > > Rebase? The patch fixes a bug and it applies cleanly. That's all that matters. Ok, sorry for confusion. I was expecting those two critical patches getting accepted before this patch as adding this patch first may cause those 2 patches getting failed. Anyways, this patch is committed now so if those 2 patches get applied cleanly on top on new repo, that's well otherwise I may need to resend those 2 patches. 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
