* [PATCH v2 1/7] megaraid_sas: For SRIOV enabled firmware, ensure VF driver waits for 30secs before reset
2016-10-20 9:04 [PATCH v2 0/7] megaraid_sas: Updates for scsi-next Sumit Saxena
@ 2016-10-20 9:04 ` Sumit Saxena
2016-10-20 9:05 ` [PATCH v2 2/7] megaraid_sas: Send correct PhysArm to FW for R1 VD downgrade Sumit Saxena
` (5 subsequent siblings)
6 siblings, 0 replies; 13+ messages in thread
From: Sumit Saxena @ 2016-10-20 9:04 UTC (permalink / raw)
To: linux-scsi
Cc: martin.petersen, thenzl, jejb, kashyap.desai, Sumit Saxena,
stable, Kiran Kumar Kasturi
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: stable@vger.kernel.org
Signed-off-by: Kiran Kumar Kasturi <kiran-kumar.kasturi@broadcom.com>
Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
---
drivers/scsi/megaraid/megaraid_sas_fusion.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 52d8bbf..61be7ed 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -2823,6 +2823,7 @@ int megasas_wait_for_outstanding_fusion(struct megasas_instance *instance,
dev_err(&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
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v2 2/7] megaraid_sas: Send correct PhysArm to FW for R1 VD downgrade
2016-10-20 9:04 [PATCH v2 0/7] megaraid_sas: Updates for scsi-next Sumit Saxena
2016-10-20 9:04 ` [PATCH v2 1/7] megaraid_sas: For SRIOV enabled firmware, ensure VF driver waits for 30secs before reset Sumit Saxena
@ 2016-10-20 9:05 ` Sumit Saxena
2016-10-20 9:05 ` [PATCH v2 3/7] megaraid_sas: Do not fire DCMDs during PCI shutdown/detach Sumit Saxena
` (4 subsequent siblings)
6 siblings, 0 replies; 13+ messages in thread
From: Sumit Saxena @ 2016-10-20 9:05 UTC (permalink / raw)
To: linux-scsi
Cc: martin.petersen, thenzl, jejb, kashyap.desai, Sumit Saxena,
Kiran Kumar Kasturi
This patch fixes the issue of wrong PhysArm was sent to firmware for R1
VD downgrade.
Signed-off-by: Kiran Kumar Kasturi <kiran-kumar.kasturi@broadcom.com>
Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
---
drivers/scsi/megaraid/megaraid_sas_fp.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_fp.c b/drivers/scsi/megaraid/megaraid_sas_fp.c
index e413113..f237d00 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fp.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fp.c
@@ -782,7 +782,8 @@ static u8 mr_spanset_get_phy_params(struct megasas_instance *instance, u32 ld,
(raid->regTypeReqOnRead != REGION_TYPE_UNUSED))))
pRAID_Context->regLockFlags = REGION_TYPE_EXCLUSIVE;
else if (raid->level == 1) {
- pd = MR_ArPdGet(arRef, physArm + 1, map);
+ physArm = physArm + 1;
+ pd = MR_ArPdGet(arRef, physArm, map);
if (pd != MR_PD_INVALID)
*pDevHandle = MR_PdDevHandleGet(pd, map);
}
@@ -879,7 +880,8 @@ u8 MR_GetPhyParams(struct megasas_instance *instance, u32 ld, u64 stripRow,
pRAID_Context->regLockFlags = REGION_TYPE_EXCLUSIVE;
else if (raid->level == 1) {
/* Get alternate Pd. */
- pd = MR_ArPdGet(arRef, physArm + 1, map);
+ physArm = physArm + 1;
+ pd = MR_ArPdGet(arRef, physArm, map);
if (pd != MR_PD_INVALID)
/* Get dev handle from Pd */
*pDevHandle = MR_PdDevHandleGet(pd, map);
--
1.8.3.1
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v2 3/7] megaraid_sas: Do not fire DCMDs during PCI shutdown/detach
2016-10-20 9:04 [PATCH v2 0/7] megaraid_sas: Updates for scsi-next Sumit Saxena
2016-10-20 9:04 ` [PATCH v2 1/7] megaraid_sas: For SRIOV enabled firmware, ensure VF driver waits for 30secs before reset Sumit Saxena
2016-10-20 9:05 ` [PATCH v2 2/7] megaraid_sas: Send correct PhysArm to FW for R1 VD downgrade Sumit Saxena
@ 2016-10-20 9:05 ` Sumit Saxena
2016-10-20 9:05 ` [PATCH v2 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware Sumit Saxena
` (3 subsequent siblings)
6 siblings, 0 replies; 13+ messages in thread
From: Sumit Saxena @ 2016-10-20 9:05 UTC (permalink / raw)
To: linux-scsi
Cc: martin.petersen, thenzl, jejb, kashyap.desai, Sumit Saxena,
Shivasharan Srikanteshwara
This patch addresses the issue of driver firing DCMDs in PCI
shutdown/detach path irrespective of firmware state.
Driver will check for whether firmware is operational state or not
before firing DCMDs. If firmware is in unrecoverbale
state or does not become operational within specfied time, driver will
skip firing DCMDs.
Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
Signed-off-by: Shivasharan Srikanteshwara <shivasharan.srikanteshwara@broadcom.com>
---
drivers/scsi/megaraid/megaraid_sas_base.c | 39 +++++++++++++++++++++++++++++
drivers/scsi/megaraid/megaraid_sas_fusion.c | 9 ++++---
2 files changed, 45 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c
index 9ff57de..3236632 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -6248,6 +6248,34 @@ static void megasas_shutdown_controller(struct megasas_instance *instance,
#define megasas_resume NULL
#endif
+static inline int
+megasas_wait_for_adapter_operational(struct megasas_instance *instance)
+{
+ int wait_time = MEGASAS_RESET_WAIT_TIME * 2;
+ int i;
+
+ if (atomic_read(&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
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v2 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware
2016-10-20 9:04 [PATCH v2 0/7] megaraid_sas: Updates for scsi-next Sumit Saxena
` (2 preceding siblings ...)
2016-10-20 9:05 ` [PATCH v2 3/7] megaraid_sas: Do not fire DCMDs during PCI shutdown/detach Sumit Saxena
@ 2016-10-20 9:05 ` Sumit Saxena
2016-10-21 10:01 ` Ric Wheeler
2016-10-21 11:01 ` James Bottomley
2016-10-20 9:05 ` [PATCH v2 5/7] MAINTAINERS: Update megaraid maintainers list Sumit Saxena
` (2 subsequent siblings)
6 siblings, 2 replies; 13+ messages in thread
From: Sumit Saxena @ 2016-10-20 9:05 UTC (permalink / raw)
To: linux-scsi
Cc: martin.petersen, thenzl, jejb, kashyap.desai, Sumit Saxena,
stable
>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: stable@vger.kernel.org
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 | 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_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 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/megaraid_sas_fusion.c
index 2159f6a..2e61306 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -748,6 +748,11 @@ static int megasas_create_sg_sense_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),
--
1.8.3.1
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [PATCH v2 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware
2016-10-20 9:05 ` [PATCH v2 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware Sumit Saxena
@ 2016-10-21 10:01 ` Ric Wheeler
2016-10-21 11:01 ` James Bottomley
1 sibling, 0 replies; 13+ messages in thread
From: Ric Wheeler @ 2016-10-21 10:01 UTC (permalink / raw)
To: Sumit Saxena, linux-scsi
Cc: martin.petersen, thenzl, jejb, kashyap.desai, stable
On 10/20/2016 05:05 AM, Sumit Saxena wrote:
> 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.
Just a note - the user can disable sending the synchronize cache settings by
mount time options with a file system (nobarrier) or for raw devices, overriding
cache_type.
This should never be required unless the target device has some quirk that does
not allow it to handle synchronize_cache correctly.
Regards,
Ric
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware
2016-10-20 9:05 ` [PATCH v2 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware Sumit Saxena
2016-10-21 10:01 ` Ric Wheeler
@ 2016-10-21 11:01 ` James Bottomley
2016-10-21 16:01 ` Tomas Henzl
1 sibling, 1 reply; 13+ messages in thread
From: James Bottomley @ 2016-10-21 11:01 UTC (permalink / raw)
To: Sumit Saxena, linux-scsi; +Cc: martin.petersen, thenzl, kashyap.desai, stable
On Thu, 2016-10-20 at 02:05 -0700, Sumit Saxena wrote:
> 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: stable@vger.kernel.org
Can you please split this into two, so we can backport the bug fix
without any of the feature addition junk?
> 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 | 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_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 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;
This, minus the "&& (!instance->fw_sync_cache_support)" is all we need
for the bug fix, correct?
James
> - 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..2e61306 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> @@ -748,6 +748,11 @@ static int megasas_create_sg_sense_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),
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH v2 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware
2016-10-21 11:01 ` James Bottomley
@ 2016-10-21 16:01 ` Tomas Henzl
0 siblings, 0 replies; 13+ messages in thread
From: Tomas Henzl @ 2016-10-21 16:01 UTC (permalink / raw)
To: James Bottomley, Sumit Saxena, linux-scsi
Cc: martin.petersen, kashyap.desai, stable
On 21.10.2016 13:01, James Bottomley wrote:
> On Thu, 2016-10-20 at 02:05 -0700, Sumit Saxena wrote:
>> 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: stable@vger.kernel.org
> Can you please split this into two, so we can backport the bug fix
> without any of the feature addition junk?
>
>> 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 | 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_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 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;
> This, minus the "&& (!instance->fw_sync_cache_support)" is all we need
> for the bug fix, correct?
Isn't both a) sending SYNC to JBOD and b) sending SYNC to logical luns
a bugfix of the same kind?
>
> James
>
>> - 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..2e61306 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
>> +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
>> @@ -748,6 +748,11 @@ static int megasas_create_sg_sense_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),
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v2 5/7] MAINTAINERS: Update megaraid maintainers list
2016-10-20 9:04 [PATCH v2 0/7] megaraid_sas: Updates for scsi-next Sumit Saxena
` (3 preceding siblings ...)
2016-10-20 9:05 ` [PATCH v2 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware Sumit Saxena
@ 2016-10-20 9:05 ` Sumit Saxena
2016-10-20 9:05 ` [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 Sumit Saxena
2016-10-20 9:05 ` [PATCH v2 7/7] megaraid_sas: driver version upgrade Sumit Saxena
6 siblings, 0 replies; 13+ messages in thread
From: Sumit Saxena @ 2016-10-20 9:05 UTC (permalink / raw)
To: linux-scsi; +Cc: martin.petersen, thenzl, jejb, kashyap.desai, Sumit Saxena
Update MEGARAID drivers maintainers list.
Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
---
MAINTAINERS | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4c1f3f9..05c0624 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7823,12 +7823,12 @@ S: Maintained
F: drivers/net/wireless/mediatek/mt7601u/
MEGARAID SCSI/SAS DRIVERS
-M: Kashyap Desai <kashyap.desai@avagotech.com>
-M: Sumit Saxena <sumit.saxena@avagotech.com>
-M: Uday Lingala <uday.lingala@avagotech.com>
-L: megaraidlinux.pdl@avagotech.com
+M: Kashyap Desai <kashyap.desai@broadcom.com>
+M: Sumit Saxena <sumit.saxena@broadcom.com>
+M: Shivasharan S <shivasharan.srikanteshwara@broadcom.com>
+L: megaraidlinux.pdl@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
^ permalink raw reply related [flat|nested] 13+ messages in thread* [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
2016-10-20 9:04 [PATCH v2 0/7] megaraid_sas: Updates for scsi-next Sumit Saxena
` (4 preceding siblings ...)
2016-10-20 9:05 ` [PATCH v2 5/7] MAINTAINERS: Update megaraid maintainers list Sumit Saxena
@ 2016-10-20 9:05 ` Sumit Saxena
2016-10-20 9:15 ` Greg KH
2016-10-20 9:05 ` [PATCH v2 7/7] megaraid_sas: driver version upgrade Sumit Saxena
6 siblings, 1 reply; 13+ messages in thread
From: Sumit Saxena @ 2016-10-20 9:05 UTC (permalink / raw)
To: linux-scsi
Cc: martin.petersen, thenzl, jejb, kashyap.desai, Sumit Saxena,
stable
CC: stable@vger.kernel.org
Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
---
drivers/scsi/megaraid/megaraid_sas_fusion.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 2e61306..24778ba 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -2005,6 +2005,8 @@ static void megasas_build_ld_nonrw_fusion(struct megasas_instance *instance,
io_request->DevHandle = pd_sync->seq[pd_index].devHandle;
pRAID_Context->regLockFlags |=
(MR_RL_FLAGS_SEQ_NUM_ENABLE|MR_RL_FLAGS_GRANT_DESTINATION_CUDA);
+ pRAID_Context->Type = MPI2_TYPE_CUDA;
+ pRAID_Context->nseg = 0x1;
} else if (fusion->fast_path_io) {
pRAID_Context->VirtualDiskTgtId = cpu_to_le16(device_id);
pRAID_Context->configSeqNum = 0;
@@ -2040,12 +2042,10 @@ static void megasas_build_ld_nonrw_fusion(struct megasas_instance *instance,
pRAID_Context->timeoutValue =
cpu_to_le16((os_timeout_value > timeout_limit) ?
timeout_limit : os_timeout_value);
- if (fusion->adapter_type == INVADER_SERIES) {
- pRAID_Context->Type = MPI2_TYPE_CUDA;
- pRAID_Context->nseg = 0x1;
+ if (fusion->adapter_type == INVADER_SERIES)
io_request->IoFlags |=
cpu_to_le16(MPI25_SAS_DEVICE0_FLAGS_ENABLED_FAST_PATH);
- }
+
cmd->request_desc->SCSIIO.RequestFlags =
(MPI2_REQ_DESCRIPT_FLAGS_FP_IO <<
MEGASAS_REQ_DESCRIPT_FLAGS_TYPE_SHIFT);
--
1.8.3.1
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [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
2016-10-20 9:05 ` [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 Sumit Saxena
@ 2016-10-20 9:15 ` Greg KH
2016-10-20 11:51 ` James Bottomley
0 siblings, 1 reply; 13+ messages in thread
From: Greg KH @ 2016-10-20 9:15 UTC (permalink / raw)
To: Sumit Saxena
Cc: linux-scsi, martin.petersen, thenzl, jejb, kashyap.desai, stable
On Thu, Oct 20, 2016 at 02:05:04AM -0700, Sumit Saxena wrote:
> CC: stable@vger.kernel.org
> Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
> Reviewed-by: Hannes Reinecke <hare@suse.com>
> Reviewed-by: Tomas Henzl <thenzl@redhat.com>
> ---
> drivers/scsi/megaraid/megaraid_sas_fusion.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
I know I reject patches without any changelog text in them, hopefully
the scsi maintainers also do...
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [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
2016-10-20 9:15 ` Greg KH
@ 2016-10-20 11:51 ` James Bottomley
0 siblings, 0 replies; 13+ messages in thread
From: James Bottomley @ 2016-10-20 11:51 UTC (permalink / raw)
To: Greg KH, Sumit Saxena
Cc: linux-scsi, martin.petersen, thenzl, kashyap.desai, stable
On Thu, 2016-10-20 at 11:15 +0200, Greg KH wrote:
> On Thu, Oct 20, 2016 at 02:05:04AM -0700, Sumit Saxena wrote:
> > CC: stable@vger.kernel.org
> > Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
> > Reviewed-by: Hannes Reinecke <hare@suse.com>
> > Reviewed-by: Tomas Henzl <thenzl@redhat.com>
> > ---
> > drivers/scsi/megaraid/megaraid_sas_fusion.c | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
>
> I know I reject patches without any changelog text in them, hopefully
> the scsi maintainers also do...
It depends: for complex patches needing detailed explanations, yes.
However, this is a four line change for which the subject seems
adequately descriptive, so this particular one seems fine.
James
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v2 7/7] megaraid_sas: driver version upgrade
2016-10-20 9:04 [PATCH v2 0/7] megaraid_sas: Updates for scsi-next Sumit Saxena
` (5 preceding siblings ...)
2016-10-20 9:05 ` [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 Sumit Saxena
@ 2016-10-20 9:05 ` Sumit Saxena
6 siblings, 0 replies; 13+ messages in thread
From: Sumit Saxena @ 2016-10-20 9:05 UTC (permalink / raw)
To: linux-scsi; +Cc: martin.petersen, thenzl, jejb, kashyap.desai, Sumit Saxena
Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
---
drivers/scsi/megaraid/megaraid_sas.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas.h b/drivers/scsi/megaraid/megaraid_sas.h
index 43fd14f..1d4de90 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -35,8 +35,8 @@
/*
* MegaRAID SAS Driver meta data
*/
-#define MEGASAS_VERSION "06.811.02.00-rc1"
-#define MEGASAS_RELDATE "April 12, 2016"
+#define MEGASAS_VERSION "06.812.07.00-rc1"
+#define MEGASAS_RELDATE "August 22, 2016"
/*
* Device IDs
--
1.8.3.1
^ permalink raw reply related [flat|nested] 13+ messages in thread