linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ewan D. Milne" <emilne@redhat.com>
To: Kashyap Desai <kashyap.desai@broadcom.com>
Cc: linux-scsi@vger.kernel.org, martin.petersen@oracle.com,
	thenzl@redhat.com, jejb@linux.vnet.ibm.com,
	sumit.saxena@broadcom.com
Subject: Re: [PATCH v3 5/8] megaraid_sas: Send SYNCHRONIZE_CACHE for VD to firmware
Date: Mon, 24 Oct 2016 12:00:33 -0400	[thread overview]
Message-ID: <1477324833.17595.7.camel@localhost.localdomain> (raw)
In-Reply-To: <1477056816-7058-6-git-send-email-kashyap.desai@broadcom.com>

On Fri, 2016-10-21 at 06:33 -0700, Kashyap Desai wrote:
> From previous patch we have below changes in v2 (only for Virtual Disk)-
> 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.
> 
>  - 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
> 
> Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com>
> Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
> ---
>  drivers/scsi/megaraid/megaraid_sas.h        | 3 +++
>  drivers/scsi/megaraid/megaraid_sas_base.c   | 7 ++-----
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 5 +++++
>  3 files changed, 10 insertions(+), 5 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_SHIFT    14
>  #define MR_MAX_MSIX_REG_ARRAY                   16
>  #define MR_RDPQ_MODE_OFFSET			0X00800000
> +#define MR_CAN_HANDLE_SYNC_CACHE_OFFSET		0X01000000
> +
>  /*
>  * 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 c98d4f9..236b8ed 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -1700,11 +1700,8 @@ megasas_queue_command(struct Scsi_Host *shost, struct scsi_cmnd *scmd)
>  		goto out_done;
>  	}
>  
> -	/*
> -	 * FW takes care of flush cache on its own for Virtual Disk.
> -	 * No need to send it down for VD. For JBOD send SYNCHRONIZE_CACHE to FW.
> -	 */
> -	if ((scmd->cmnd[0] == SYNCHRONIZE_CACHE) && MEGASAS_IS_LOGICAL(scmd)) {
> +	if ((scmd->cmnd[0] == SYNCHRONIZE_CACHE) && MEGASAS_IS_LOGICAL(scmd) &&
> +		(!instance->fw_sync_cache_support)) {
>  		scmd->result = DID_OK << 16;
>  		goto out_done;
>  	}
> diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> index ec626fc..0edeeb1 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> @@ -748,6 +748,11 @@ megasas_ioc_init_fusion(struct megasas_instance *instance)
>  		goto fail_fw_init;
>  	}
>  
> +	instance->fw_sync_cache_support = (scratch_pad_2 &
> +		MR_CAN_HANDLE_SYNC_CACHE_OFFSET) ? 1 : 0;
> +	dev_info(&instance->pdev->dev, "FW supports sync cache\t: %s\n",
> +		 instance->fw_sync_cache_support ? "Yes" : "No");
> +
>  	IOCInitMessage =
>  	  dma_alloc_coherent(&instance->pdev->dev,
>  			     sizeof(struct MPI2_IOC_INIT_REQUEST),

Reviewed-by: Ewan D. Milne <emilne@redhat.com>



  parent reply	other threads:[~2016-10-24 16:00 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-21 13:33 [PATCH v3 0/7] megaraid_sas: Updates for scsi-next Kashyap Desai
2016-10-21 13:33 ` [PATCH v3 1/8] megaraid_sas: For SRIOV enabled firmware, ensure VF driver waits for 30secs before reset Kashyap Desai
2016-10-21 13:33 ` [PATCH v3 2/8] megaraid_sas: Send correct PhysArm to FW for R1 VD downgrade Kashyap Desai
2016-10-21 13:33 ` [PATCH v3 3/8] megaraid_sas: Do not fire DCMDs during PCI shutdown/detach Kashyap Desai
2016-10-24 14:34   ` Hannes Reinecke
2016-10-21 13:33 ` [PATCH v3 4/8] megaraid_sas: Send SYNCHRONIZE_CACHE for non-raid to firmware Kashyap Desai
2016-10-21 16:02   ` Tomas Henzl
2016-10-24 14:35   ` Hannes Reinecke
2016-10-24 16:00   ` Ewan D. Milne
2016-10-25  1:33   ` Martin K. Petersen
2016-10-21 13:33 ` [PATCH v3 5/8] megaraid_sas: Send SYNCHRONIZE_CACHE for VD " Kashyap Desai
2016-10-21 15:59   ` Tomas Henzl
2016-10-24 14:36   ` Hannes Reinecke
2016-10-24 16:00   ` Ewan D. Milne [this message]
2016-10-21 13:33 ` [PATCH v3 6/8] MAINTAINERS: Update megaraid maintainers list Kashyap Desai
2016-11-08 14:50   ` Tomas Henzl
2016-10-21 13:33 ` [PATCH v3 7/8] megaraid_sas: Do not set MPI2_TYPE_CUDA for JBOD FP path for FW which does not support JBOD sequence map Kashyap Desai
2016-10-21 13:33 ` [PATCH v3 8/8] megaraid_sas: driver version upgrade Kashyap Desai
2016-10-24 14:36   ` Hannes Reinecke
2016-11-08 23:05   ` Martin K. Petersen
2016-10-25  2:01 ` [PATCH v3 0/7] megaraid_sas: Updates for scsi-next Martin K. Petersen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1477324833.17595.7.camel@localhost.localdomain \
    --to=emilne@redhat.com \
    --cc=jejb@linux.vnet.ibm.com \
    --cc=kashyap.desai@broadcom.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=sumit.saxena@broadcom.com \
    --cc=thenzl@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).