[PATCH 0/8] enable endian checks for all sparse builds

[Michael S. Tsirkin]

This is just a reposting of the patch that enables endian checks, with addition
of trivial patches that drop __bitwise__ and __CHECK_ENDIAN__ everywhere.

I plan to include this in my pull request unless I hear otherwise.

Michael S. Tsirkin (8):
  linux/types.h: enable endian checks for all sparse builds
  tools: enable endian checks for all sparse builds
  Documentation/sparse: drop __bitwise__
  checkpatch: replace __bitwise__ with __bitwise
  linux: drop __bitwise__ everywhere
  Documentation/sparse: drop __CHECK_ENDIAN__
  fs/logfs: drop __CHECK_ENDIAN__
  Makefile: drop -D__CHECK_ENDIAN__ from cflags

 Documentation/translations/zh_CN/sparse.txt   |  7 +--
 arch/arm/plat-samsung/include/plat/gpio-cfg.h |  2 +-
 drivers/md/dm-cache-block-types.h |  6 +++---
 drivers/net/ethernet/sun/sunhme.h |  2 +-
 drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h  |  4 ++--
 fs/logfs/logfs.h  |  4 +---
 include/linux/mmzone.h|  2 +-
 include/linux/serial_core.h   |  4 ++--
 include/linux/types.h |  4 ++--
 include/scsi/iscsi_proto.h|  2 +-
 include/target/target_core_base.h |  2 +-
 include/uapi/linux/types.h|  4 
 include/uapi/linux/virtio_types.h |  6 +++---
 net/ieee802154/6lowpan/6lowpan_i.h|  2 +-
 net/mac80211/ieee80211_i.h|  4 ++--
 tools/include/linux/types.h   |  4 
 Documentation/dev-tools/sparse.rst| 14 +-
 drivers/bluetooth/Makefile|  2 --
 drivers/net/can/Makefile  |  1 -
 drivers/net/ethernet/altera/Makefile  |  1 -
 drivers/net/ethernet/atheros/alx/Makefile |  1 -
 drivers/net/ethernet/freescale/Makefile   |  2 --
 drivers/net/wireless/ath/Makefile |  2 --
 drivers/net/wireless/ath/wil6210/Makefile |  2 --
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile |  2 --
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/Makefile |  1 -
 drivers/net/wireless/intel/iwlegacy/Makefile  |  2 --
 drivers/net/wireless/intel/iwlwifi/Makefile   |  2 +-
 drivers/net/wireless/intel/iwlwifi/dvm/Makefile   |  2 +-
 drivers/net/wireless/intel/iwlwifi/mvm/Makefile   |  2 +-
 drivers/net/wireless/intersil/orinoco/Makefile|  3 ---
 drivers/net/wireless/mediatek/mt7601u/Makefile|  2 --
 drivers/net/wireless/realtek/rtlwifi/Makefile |  2 --
 drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile   |  2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/Makefile   |  2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8192c/Makefile|  2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8192ce/Makefile   |  2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8192cu/Makefile   |  2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8192de/Makefile   |  2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8192ee/Makefile   |  2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8192se/Makefile   |  2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/Makefile   |  2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/Makefile   |  2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8723com/Makefile  |  2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/Makefile   |  2 --
 drivers/net/wireless/ti/wl1251/Makefile   |  2 --
 drivers/net/wireless/ti/wlcore/Makefile   |  2 --
 drivers/staging/rtl8188eu/Makefile|  2 +-
 drivers/staging/rtl8192e/Makefile |  2 --
 drivers/staging/rtl8192e/rtl8192e/Makefile|  2 --
 net/bluetooth/Makefile|  2 --
 net/ieee802154/Makefile   |  2 --
 net/mac80211/Makefile |  2 +-
 net/mac802154/Makefile|  2 --
 net/wireless/Makefile |  2 --
 scripts/checkpatch.pl |  4 ++--
 56 files changed, 30 insertions(+), 120 deletions(-)

-- 
MST

--
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 5/8] linux: drop __bitwise__ everywhere

[Michael S. Tsirkin]

__bitwise__ used to mean "yes, please enable sparse checks
unconditionally", but now that we dropped __CHECK_ENDIAN__
__bitwise is exactly the same.
There aren't many users, replace it by __bitwise everywhere.

Signed-off-by: Michael S. Tsirkin 
---
 arch/arm/plat-samsung/include/plat/gpio-cfg.h| 2 +-
 drivers/md/dm-cache-block-types.h| 6 +++---
 drivers/net/ethernet/sun/sunhme.h| 2 +-
 drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 4 ++--
 include/linux/mmzone.h   | 2 +-
 include/linux/serial_core.h  | 4 ++--
 include/linux/types.h| 4 ++--
 include/scsi/iscsi_proto.h   | 2 +-
 include/target/target_core_base.h| 2 +-
 include/uapi/linux/virtio_types.h| 6 +++---
 net/ieee802154/6lowpan/6lowpan_i.h   | 2 +-
 net/mac80211/ieee80211_i.h   | 4 ++--
 12 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/arm/plat-samsung/include/plat/gpio-cfg.h 
b/arch/arm/plat-samsung/include/plat/gpio-cfg.h
index 21391fa..e55d1f5 100644
--- a/arch/arm/plat-samsung/include/plat/gpio-cfg.h
+++ b/arch/arm/plat-samsung/include/plat/gpio-cfg.h
@@ -26,7 +26,7 @@
 
 #include 
 
-typedef unsigned int __bitwise__ samsung_gpio_pull_t;
+typedef unsigned int __bitwise samsung_gpio_pull_t;
 
 /* forward declaration if gpio-core.h hasn't been included */
 struct samsung_gpio_chip;
diff --git a/drivers/md/dm-cache-block-types.h 
b/drivers/md/dm-cache-block-types.h
index bed4ad4..389c9e8 100644
--- a/drivers/md/dm-cache-block-types.h
+++ b/drivers/md/dm-cache-block-types.h
@@ -17,9 +17,9 @@
  * discard bitset.
  */
 
-typedef dm_block_t __bitwise__ dm_oblock_t;
-typedef uint32_t __bitwise__ dm_cblock_t;
-typedef dm_block_t __bitwise__ dm_dblock_t;
+typedef dm_block_t __bitwise dm_oblock_t;
+typedef uint32_t __bitwise dm_cblock_t;
+typedef dm_block_t __bitwise dm_dblock_t;
 
 static inline dm_oblock_t to_oblock(dm_block_t b)
 {
diff --git a/drivers/net/ethernet/sun/sunhme.h 
b/drivers/net/ethernet/sun/sunhme.h
index f430765..4a8d5b1 100644
--- a/drivers/net/ethernet/sun/sunhme.h
+++ b/drivers/net/ethernet/sun/sunhme.h
@@ -302,7 +302,7 @@
  * Always write the address first before setting the ownership
  * bits to avoid races with the hardware scanning the ring.
  */
-typedef u32 __bitwise__ hme32;
+typedef u32 __bitwise hme32;
 
 struct happy_meal_rxd {
hme32 rx_flags;
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h 
b/drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h
index 1ad0ec1..84813b5 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h
@@ -228,7 +228,7 @@ enum iwl_ucode_tlv_flag {
IWL_UCODE_TLV_FLAGS_BCAST_FILTERING = BIT(29),
 };
 
-typedef unsigned int __bitwise__ iwl_ucode_tlv_api_t;
+typedef unsigned int __bitwise iwl_ucode_tlv_api_t;
 
 /**
  * enum iwl_ucode_tlv_api - ucode api
@@ -258,7 +258,7 @@ enum iwl_ucode_tlv_api {
 #endif
 };
 
-typedef unsigned int __bitwise__ iwl_ucode_tlv_capa_t;
+typedef unsigned int __bitwise iwl_ucode_tlv_capa_t;
 
 /**
  * enum iwl_ucode_tlv_capa - ucode capabilities
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 0f088f3..36d9896 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -246,7 +246,7 @@ struct lruvec {
 #define ISOLATE_UNEVICTABLE((__force isolate_mode_t)0x8)
 
 /* LRU Isolation modes. */
-typedef unsigned __bitwise__ isolate_mode_t;
+typedef unsigned __bitwise isolate_mode_t;
 
 enum zone_watermarks {
WMARK_MIN,
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 5d49488..5def8e8 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -111,8 +111,8 @@ struct uart_icount {
__u32   buf_overrun;
 };
 
-typedef unsigned int __bitwise__ upf_t;
-typedef unsigned int __bitwise__ upstat_t;
+typedef unsigned int __bitwise upf_t;
+typedef unsigned int __bitwise upstat_t;
 
 struct uart_port {
spinlock_t  lock;   /* port lock */
diff --git a/include/linux/types.h b/include/linux/types.h
index baf7183..d501ad3 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -154,8 +154,8 @@ typedef u64 dma_addr_t;
 typedef u32 dma_addr_t;
 #endif
 
-typedef unsigned __bitwise__ gfp_t;
-typedef unsigned __bitwise__ fmode_t;
+typedef unsigned __bitwise gfp_t;
+typedef unsigned __bitwise fmode_t;
 
 #ifdef CONFIG_PHYS_ADDR_T_64BIT
 typedef u64 phys_addr_t;
diff --git a/include/scsi/iscsi_proto.h b/include/scsi/iscsi_proto.h
index c1260d8..df156f1 100644
--- a/include/scsi/iscsi_proto.h
+++ b/include/scsi/iscsi_proto.h
@@ -74,7 +74,7 @@ static inline int iscsi_sna_gte(u32 n1, u32 n2)
 #define zero_data(p) {p[0]=0;p[1]=0;p[2]=0;}
 
 /* initiator tags; opaque for target */
-typedef uint32_t __bitwise__ itt_t;
+typedef uint32_t __bitwise itt_t;
 /* 

Re: [PATCH] scsi: mvsas: Replace pci_pool_alloc by pci_pool_zalloc

[Souptick Joarder]

Martin,

On Wed, Dec 14, 2016 at 7:22 AM, Martin K. Petersen
 wrote:
>> "Souptick" == Souptick Joarder  writes:
>
> Souptick,
>
> Sorry about the delay. Been out for a few days.
>
 Inside mvs_task_prep(), pci_pool_alloc() followed by memset will be
 replaced by pci_pool_zalloc()
>
> Souptick> Any further comment on this ?
>
> I took one of your other patches because the driver maintainer acked it,
> thus assuming responsibility for testing it and fixing any regressions
> it may cause.
>
> The failure rate on these "trivial" patches to old and unmaintained
> drivers is very high. And since you are not fixing any bugs and your
> change is functionally identical what the code already does, why would
> we merge it and risk a regression? (for changes like this, a Tested-by:
> from somebody with actual hardware is worth a thousand Reviewed-by:
> tags).
>
> Also, I'm not really convinced that this constant churn of new and
> "improved" kernel interface helper functions is really solving anything.
> Quite the contrary. Real bug fixes for drivers adopting the
> pci_pool_zalloc() interface will now potentially be harder to backport
> to stable releases predating 4.4 or whenever that call was introduced.
>
> So in summary, I don't see any actual benefits to your proposed
> change. It's probably fine, but why would I risk merging it?

  I understand the importance of testing this patch on old and
unmaintained driver and
  totally agreed with your point of view now.

  I will drop this patch.
  If possible, can you please let me know what are all the basic
stability test cases are covered
  for SCSI drivers?
>
> Hope that all makes sense...
>
> Thanks!
>
> --
> Martin K. Petersen  Oracle Linux Engineering

Thanks -
Souptick
--
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/6] storvsc: use tagged SRB requests if supported by the device

[kys]

From: Long Li 

Properly set SRB flags when hosting device supports tagged queuing.
This patch improves the performance on Fiber Channel disks.

Signed-off-by: Long Li 
Reviewed-by: K. Y. Srinivasan 
Signed-off-by: K. Y. Srinivasan 
Cc: 
---
 drivers/scsi/storvsc_drv.c |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 63f6b1a..3209387 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -136,6 +136,8 @@ struct hv_fc_wwn_packet {
 #define SRB_FLAGS_PORT_DRIVER_RESERVED 0x0F00
 #define SRB_FLAGS_CLASS_DRIVER_RESERVED0xF000
 
+#define SP_UNTAGGED((unsigned char) ~0)
+#define SRB_SIMPLE_TAG_REQUEST 0x20
 
 /*
  * Platform neutral description of a scsi request -
@@ -1549,6 +1551,13 @@ static int storvsc_queuecommand(struct Scsi_Host *host, 
struct scsi_cmnd *scmnd)
vm_srb->win8_extension.srb_flags |=
SRB_FLAGS_DISABLE_SYNCH_TRANSFER;
 
+   if (scmnd->device->tagged_supported) {
+   vm_srb->win8_extension.srb_flags |=
+   (SRB_FLAGS_QUEUE_ACTION_ENABLE | SRB_FLAGS_NO_QUEUE_FREEZE);
+   vm_srb->win8_extension.queue_tag = SP_UNTAGGED;
+   vm_srb->win8_extension.queue_action = SRB_SIMPLE_TAG_REQUEST;
+   }
+
/* Build the SRB */
switch (scmnd->sc_data_direction) {
case DMA_TO_DEVICE:
-- 
1.7.4.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/6] storvsc: Enable multi-queue support

[kys]

From: K. Y. Srinivasan 

Enable multi-q support. We will allocate the outgoing channel using
the following policy:

1. We will make every effort to pick a channel that is in the
   same NUMA node that is initiating the I/O
2. The mapping between the guest CPU and the outgoing channel
   is persistent.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Long Li 
---
 drivers/scsi/storvsc_drv.c |  113 ++-
 1 files changed, 110 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 3b1c2f6..63f6b1a 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -458,6 +458,15 @@ struct storvsc_device {
 * Max I/O, the device can support.
 */
u32   max_transfer_bytes;
+   /*
+* Number of sub-channels we will open.
+*/
+   u16 num_sc;
+   struct vmbus_channel **stor_chns;
+   /*
+* Mask of CPUs bound to subchannels.
+*/
+   struct cpumask alloced_cpus;
/* Used for vsc/vsp channel reset process */
struct storvsc_cmd_request init_request;
struct storvsc_cmd_request reset_request;
@@ -635,6 +644,11 @@ static void handle_sc_creation(struct vmbus_channel 
*new_sc)
   (void *),
   sizeof(struct vmstorage_channel_properties),
   storvsc_on_channel_callback, new_sc);
+
+   if (new_sc->state == CHANNEL_OPENED_STATE) {
+   stor_device->stor_chns[new_sc->target_cpu] = new_sc;
+   cpumask_set_cpu(new_sc->target_cpu, _device->alloced_cpus);
+   }
 }
 
 static void  handle_multichannel_storage(struct hv_device *device, int 
max_chns)
@@ -651,6 +665,7 @@ static void  handle_multichannel_storage(struct hv_device 
*device, int max_chns)
if (!stor_device)
return;
 
+   stor_device->num_sc = num_sc;
request = _device->init_request;
vstor_packet = >vstor_packet;
 
@@ -838,6 +853,25 @@ static int storvsc_channel_init(struct hv_device *device, 
bool is_fc)
 * support multi-channel.
 */
max_chns = vstor_packet->storage_channel_properties.max_channel_cnt;
+
+   /*
+* Allocate state to manage the sub-channels.
+* We allocate an array based on the numbers of possible CPUs
+* (Hyper-V does not support cpu online/offline).
+* This Array will be sparseley populated with unique
+* channels - primary + sub-channels.
+* We will however populate all the slots to evenly distribute
+* the load.
+*/
+   stor_device->stor_chns = kzalloc(sizeof(void *) * num_possible_cpus(),
+GFP_KERNEL);
+   if (stor_device->stor_chns == NULL)
+   return -ENOMEM;
+
+   stor_device->stor_chns[device->channel->target_cpu] = device->channel;
+   cpumask_set_cpu(device->channel->target_cpu,
+   _device->alloced_cpus);
+
if (vmstor_proto_version >= VMSTOR_PROTO_VERSION_WIN8) {
if (vstor_packet->storage_channel_properties.flags &
STORAGE_CHANNEL_SUPPORTS_MULTI_CHANNEL)
@@ -1198,17 +1232,64 @@ static int storvsc_dev_remove(struct hv_device *device)
/* Close the channel */
vmbus_close(device->channel);
 
+   kfree(stor_device->stor_chns);
kfree(stor_device);
return 0;
 }
 
+static struct vmbus_channel *get_og_chn(struct storvsc_device *stor_device,
+   u16 q_num)
+{
+   u16 slot = 0;
+   u16 hash_qnum;
+   struct cpumask alloced_mask;
+   int num_channels, tgt_cpu;
+
+   if (stor_device->num_sc == 0)
+   return stor_device->device->channel;
+
+   /*
+* Our channel array is sparsley populated and we
+* initiated I/O on a processor/hw-q that does not
+* currently have a designated channel. Fix this.
+* The strategy is simple:
+* I. Ensure NUMA locality
+* II. Distribute evenly (best effort)
+* III. Mapping is persistent.
+*/
+
+   cpumask_and(_mask, _device->alloced_cpus,
+   cpumask_of_node(cpu_to_node(q_num)));
+
+   num_channels = cpumask_weight(_mask);
+   if (num_channels == 0)
+   return stor_device->device->channel;
+
+   hash_qnum = q_num;
+   while (hash_qnum >= num_channels)
+   hash_qnum -= num_channels;
+
+   for_each_cpu(tgt_cpu, _mask) {
+   if (slot == hash_qnum)
+   break;
+   slot++;
+   }
+
+   stor_device->stor_chns[q_num] = stor_device->stor_chns[tgt_cpu];
+
+   return stor_device->stor_chns[q_num];
+}
+
+
 static int storvsc_do_io(struct hv_device *device,
-struct storvsc_cmd_request *request)
+ 

[PATCH 2/6] storvsc: Remove the restriction on max segment size

[kys]

From: K. Y. Srinivasan 

Remove the artificially imposed restriction on max segment size.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Long Li 
---
 drivers/scsi/storvsc_drv.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index ccb2101..3b1c2f6 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1267,8 +1267,6 @@ static int storvsc_do_io(struct hv_device *device,
 static int storvsc_device_configure(struct scsi_device *sdevice)
 {
 
-   blk_queue_max_segment_size(sdevice->request_queue, PAGE_SIZE);
-
blk_queue_bounce_limit(sdevice->request_queue, BLK_BOUNCE_ANY);
 
blk_queue_rq_timeout(sdevice->request_queue, (storvsc_timeout * HZ));
-- 
1.7.4.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 5/6] storvsc: properly handle SRB_ERROR when sense message is present

[kys]

From: Long Li 

When sense message is present on error, we should pass along to the upper
layer to decide how to deal with the error.
This patch fixes connectivity issues with Fiber Channel devices.

Signed-off-by: Long Li 
Reviewed-by: K. Y. Srinivasan 
Signed-off-by: K. Y. Srinivasan 
Cc: 
---
 drivers/scsi/storvsc_drv.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 3209387..3c92dc2 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -925,6 +925,13 @@ static void storvsc_handle_error(struct vmscsi_request 
*vm_srb,
switch (SRB_STATUS(vm_srb->srb_status)) {
case SRB_STATUS_ERROR:
/*
+* Let upper layer deal with error when
+* sense message is present.
+*/
+
+   if (vm_srb->srb_status & SRB_STATUS_AUTOSENSE_VALID)
+   break;
+   /*
 * If there is an error; offline the device since all
 * error recovery strategies would have already been
 * deployed on the host side. However, if the command
-- 
1.7.4.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/6] storvsc: Enable tracking of queue depth

[kys]

From: K. Y. Srinivasan 

Enable tracking of queue depth.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Long Li 
---
 drivers/scsi/storvsc_drv.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 05526b7..ccb2101 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1550,6 +1550,7 @@ static int storvsc_queuecommand(struct Scsi_Host *host, 
struct scsi_cmnd *scmnd)
/* Make sure we dont get a sg segment crosses a page boundary */
.dma_boundary = PAGE_SIZE-1,
.no_write_same =1,
+   .track_queue_depth =1,
 };
 
 enum {
-- 
1.7.4.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/6] storvsc: properly set residual data length on errors

[kys]

From: Long Li 

On I/O errors, the Windows driver doesn't set data_transfer_length
on error conditions other than SRB_STATUS_DATA_OVERRUN.
In these cases we need to set data_transfer_length to 0,
indicating there is no data transferred. On SRB_STATUS_DATA_OVERRUN,
data_transfer_length is set by the Windows driver to the actual data 
transferred.

Reported-by: Shiva Krishna 
Signed-off-by: Long Li 
Reviewed-by: K. Y. Srinivasan 
Signed-off-by: K. Y. Srinivasan 
Cc: 
---
 drivers/scsi/storvsc_drv.c |   16 +---
 1 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 3c92dc2..888e16e 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -377,6 +377,7 @@ enum storvsc_request_type {
 #define SRB_STATUS_SUCCESS 0x01
 #define SRB_STATUS_ABORTED 0x02
 #define SRB_STATUS_ERROR   0x04
+#define SRB_STATUS_DATA_OVERRUN0x12
 
 #define SRB_STATUS(status) \
(status & ~(SRB_STATUS_AUTOSENSE_VALID | SRB_STATUS_QUEUE_FROZEN))
@@ -996,6 +997,7 @@ static void storvsc_command_completion(struct 
storvsc_cmd_request *cmd_request,
struct scsi_cmnd *scmnd = cmd_request->cmd;
struct scsi_sense_hdr sense_hdr;
struct vmscsi_request *vm_srb;
+   u32 data_transfer_length;
struct Scsi_Host *host;
u32 payload_sz = cmd_request->payload_sz;
void *payload = cmd_request->payload;
@@ -1003,6 +1005,7 @@ static void storvsc_command_completion(struct 
storvsc_cmd_request *cmd_request,
host = stor_dev->host;
 
vm_srb = _request->vstor_packet.vm_srb;
+   data_transfer_length = vm_srb->data_transfer_length;
 
scmnd->result = vm_srb->scsi_status;
 
@@ -1016,13 +1019,20 @@ static void storvsc_command_completion(struct 
storvsc_cmd_request *cmd_request,
 _hdr);
}
 
-   if (vm_srb->srb_status != SRB_STATUS_SUCCESS)
+   if (vm_srb->srb_status != SRB_STATUS_SUCCESS) {
storvsc_handle_error(vm_srb, scmnd, host, sense_hdr.asc,
 sense_hdr.ascq);
+   /*
+* The Windows driver set data_transfer_length on
+* SRB_STATUS_DATA_OVERRUN. On other errors, this value
+* is untouched.  In these cases we set it to 0.
+*/
+   if (vm_srb->srb_status != SRB_STATUS_DATA_OVERRUN)
+   data_transfer_length = 0;
+   }
 
scsi_set_resid(scmnd,
-   cmd_request->payload->range.len -
-   vm_srb->data_transfer_length);
+   cmd_request->payload->range.len - data_transfer_length);
 
scmnd->scsi_done(scmnd);
 
-- 
1.7.4.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/6] storvsc: Miscellaneous fixes and enhancements

[kys]

From: K. Y. Srinivasan 

Miscellaneous fixes and enhancements.

K. Y. Srinivasan (3):
  storvsc: Enable tracking of queue depth
  storvsc: Remove the restriction on max segment size
  storvsc: Enable multi-queue support

Long Li (3):
  storvsc: use tagged SRB requests if supported by the device
  storvsc: properly handle SRB_ERROR when sense message is present
  storvsc: properly set residual data length on errors

 drivers/scsi/storvsc_drv.c |  148 +---
 1 files changed, 140 insertions(+), 8 deletions(-)

-- 
1.7.4.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 V5 07/11] megaraid_sas: Add the Support for SAS3.5 Generic Megaraid Controllers Capabilities

[Sasikumar Chandrasekaran]

The Megaraid driver has to support the SAS3.5 Generic Megaraid Controllers 
Firmware functionality.

This patch is depending on patch 6
This patch is same as V4 and there is no specific update for V5

Signed-off-by: Sasikumar Chandrasekaran 
Reviewed-by: Tomas Henzl 
---
 drivers/scsi/megaraid/megaraid_sas_base.c   | 53 ++---
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 19 ++-
 drivers/scsi/megaraid/megaraid_sas_fusion.h |  1 +
 3 files changed, 37 insertions(+), 36 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 92cb02f..4518ffc 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -5038,34 +5038,29 @@ static int megasas_init_fw(struct megasas_instance 
*instance)
 
reg_set = instance->reg_set;
 
-   switch (instance->pdev->device) {
-   case PCI_DEVICE_ID_LSI_FUSION:
-   case PCI_DEVICE_ID_LSI_PLASMA:
-   case PCI_DEVICE_ID_LSI_INVADER:
-   case PCI_DEVICE_ID_LSI_FURY:
-   case PCI_DEVICE_ID_LSI_INTRUDER:
-   case PCI_DEVICE_ID_LSI_INTRUDER_24:
-   case PCI_DEVICE_ID_LSI_CUTLASS_52:
-   case PCI_DEVICE_ID_LSI_CUTLASS_53:
+   if (fusion)
instance->instancet = _instance_template_fusion;
-   break;
-   case PCI_DEVICE_ID_LSI_SAS1078R:
-   case PCI_DEVICE_ID_LSI_SAS1078DE:
-   instance->instancet = _instance_template_ppc;
-   break;
-   case PCI_DEVICE_ID_LSI_SAS1078GEN2:
-   case PCI_DEVICE_ID_LSI_SAS0079GEN2:
-   instance->instancet = _instance_template_gen2;
-   break;
-   case PCI_DEVICE_ID_LSI_SAS0073SKINNY:
-   case PCI_DEVICE_ID_LSI_SAS0071SKINNY:
-   instance->instancet = _instance_template_skinny;
-   break;
-   case PCI_DEVICE_ID_LSI_SAS1064R:
-   case PCI_DEVICE_ID_DELL_PERC5:
-   default:
-   instance->instancet = _instance_template_xscale;
-   break;
+   else {
+   switch (instance->pdev->device) {
+   case PCI_DEVICE_ID_LSI_SAS1078R:
+   case PCI_DEVICE_ID_LSI_SAS1078DE:
+   instance->instancet = _instance_template_ppc;
+   break;
+   case PCI_DEVICE_ID_LSI_SAS1078GEN2:
+   case PCI_DEVICE_ID_LSI_SAS0079GEN2:
+   instance->instancet = _instance_template_gen2;
+   break;
+   case PCI_DEVICE_ID_LSI_SAS0073SKINNY:
+   case PCI_DEVICE_ID_LSI_SAS0071SKINNY:
+   instance->instancet = _instance_template_skinny;
+   break;
+   case PCI_DEVICE_ID_LSI_SAS1064R:
+   case PCI_DEVICE_ID_DELL_PERC5:
+   default:
+   instance->instancet = _instance_template_xscale;
+   instance->pd_list_not_supported = 1;
+   break;
+   }
}
 
if (megasas_transition_to_ready(instance, 0)) {
@@ -5814,7 +5809,9 @@ static int megasas_probe_one(struct pci_dev *pdev,
if ((instance->pdev->device == PCI_DEVICE_ID_LSI_FUSION) ||
(instance->pdev->device == PCI_DEVICE_ID_LSI_PLASMA))
fusion->adapter_type = THUNDERBOLT_SERIES;
-   else if (!instance->is_ventura)
+   else if (instance->is_ventura)
+   fusion->adapter_type = VENTURA_SERIES;
+   else
fusion->adapter_type = INVADER_SERIES;
}
break;
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index f64445f..5ef35b2 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -244,7 +244,10 @@ inline void megasas_return_cmd_fusion(struct 
megasas_instance *instance,
 
reg_set = instance->reg_set;
 
-   cur_max_fw_cmds = readl(>reg_set->outbound_scratch_pad_3) & 
0x00;
+   /* ventura FW does not fill outbound_scratch_pad_3 with queue depth */
+   if (!instance->is_ventura)
+   cur_max_fw_cmds =
+   readl(>reg_set->outbound_scratch_pad_3) & 0x00;
 
if (dual_qdepth_disable || !cur_max_fw_cmds)
cur_max_fw_cmds = 
instance->instancet->read_fw_status_reg(reg_set) & 0x00;
@@ -837,7 +840,7 @@ static int megasas_create_sg_sense_fusion(struct 
megasas_instance *instance)
drv_ops = (MFI_CAPABILITIES *) &(init_frame->driver_operations);
 
/* driver support Extended MSIX */
-   if (fusion->adapter_type == INVADER_SERIES)
+   if (fusion->adapter_type >= INVADER_SERIES)
drv_ops->mfi_capabilities.support_additional_msix = 1;
/* driver supports HA / Remote LUN over Fast Path interface */
   

[PATCH V5 01/11] megaraid_sas: Add new pci device Ids for SAS3.5 Generic Megaraid Controllers

[Sasikumar Chandrasekaran]

This patch contains new pci device ids for SAS3.5 Generic Megaraid Controllers

Rebased with latest upstearm code which has pci_alloc_irq_vectors conversion
changes from Hannes

Signed-off-by: Sasikumar Chandrasekaran 
Reviewed-by: Tomas Henzl 
---
 drivers/scsi/megaraid/megaraid_sas.h| 12 +---
 drivers/scsi/megaraid/megaraid_sas_base.c   | 14 +-
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 30 ++---
 3 files changed, 45 insertions(+), 11 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index fdd519c..cb82195 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -56,6 +56,11 @@
 #define PCI_DEVICE_ID_LSI_INTRUDER_24  0x00cf
 #define PCI_DEVICE_ID_LSI_CUTLASS_52   0x0052
 #define PCI_DEVICE_ID_LSI_CUTLASS_53   0x0053
+#define PCI_DEVICE_ID_LSI_VENTURA  0x0014
+#define PCI_DEVICE_ID_LSI_HARPOON  0x0016
+#define PCI_DEVICE_ID_LSI_TOMCAT   0x0017
+#define PCI_DEVICE_ID_LSI_VENTURA_4PORT0x001B
+#define PCI_DEVICE_ID_LSI_CRUSADER_4PORT   0x001C
 
 /*
  * Intel HBA SSDIDs
@@ -100,7 +105,7 @@
  */
 
 /*
- * MFI stands for  MegaRAID SAS FW Interface. This is just a moniker for 
+ * MFI stands for  MegaRAID SAS FW Interface. This is just a moniker for
  * protocol between the software and firmware. Commands are issued using
  * "message frames"
  */
@@ -1435,7 +1440,7 @@ enum FW_BOOT_CONTEXT {
 * register set for both 1068 and 1078 controllers
 * structure extended for 1078 registers
 */
- 
+
 struct megasas_register_set {
u32 doorbell;   /*h*/
u32 fusion_seq_offset;  /*0004h*/
@@ -1478,7 +1483,7 @@ struct megasas_register_set {
 
u32 inbound_high_queue_port ;   /*00C4h*/
 
-   u32 reserved_5; /*00C8h*/
+   u32 inbound_single_queue_port;  /*00C8h*/
u32 res_6[11];  /*CCh*/
u32 host_diag;
u32 seq_offset;
@@ -2142,6 +2147,7 @@ struct megasas_instance {
u8 is_rdpq;
bool dev_handle;
bool fw_sync_cache_support;
+   bool is_ventura;
 };
 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 6484c38..ea04fce 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -155,6 +155,12 @@ static int megasas_register_aen(struct megasas_instance 
*instance,
/* Intruder 24 port*/
{PCI_DEVICE(PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_LSI_CUTLASS_52)},
{PCI_DEVICE(PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_LSI_CUTLASS_53)},
+   /* VENTURA */
+   {PCI_DEVICE(PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_LSI_VENTURA)},
+   {PCI_DEVICE(PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_LSI_HARPOON)},
+   {PCI_DEVICE(PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_LSI_TOMCAT)},
+   {PCI_DEVICE(PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_LSI_VENTURA_4PORT)},
+   {PCI_DEVICE(PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_LSI_CRUSADER_4PORT)},
{}
 };
 
@@ -5714,6 +5720,12 @@ static int megasas_probe_one(struct pci_dev *pdev,
instance->pdev = pdev;
 
switch (instance->pdev->device) {
+   case PCI_DEVICE_ID_LSI_VENTURA:
+   case PCI_DEVICE_ID_LSI_HARPOON:
+   case PCI_DEVICE_ID_LSI_TOMCAT:
+   case PCI_DEVICE_ID_LSI_VENTURA_4PORT:
+   case PCI_DEVICE_ID_LSI_CRUSADER_4PORT:
+instance->is_ventura = true;
case PCI_DEVICE_ID_LSI_FUSION:
case PCI_DEVICE_ID_LSI_PLASMA:
case PCI_DEVICE_ID_LSI_INVADER:
@@ -5738,7 +5750,7 @@ static int megasas_probe_one(struct pci_dev *pdev,
if ((instance->pdev->device == PCI_DEVICE_ID_LSI_FUSION) ||
(instance->pdev->device == PCI_DEVICE_ID_LSI_PLASMA))
fusion->adapter_type = THUNDERBOLT_SERIES;
-   else
+   else if (!instance->is_ventura)
fusion->adapter_type = INVADER_SERIES;
}
break;
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 24778ba..8d7a397 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -189,15 +189,29 @@ inline void megasas_return_cmd_fusion(struct 
megasas_instance *instance,
  */
 static void
 megasas_fire_cmd_fusion(struct megasas_instance *instance,
-   union MEGASAS_REQUEST_DESCRIPTOR_UNION *req_desc)
+   union MEGASAS_REQUEST_DESCRIPTOR_UNION *req_desc, bool is_32bit)
 {
+   struct megasas_register_set __iomem *regs = instance->reg_set;
+   unsigned long flags;
+
+   if (is_32bit)
+   writel(le32_to_cpu(req_desc->u.low),
+  

[PATCH V5 04/11] megaraid_sas: SAS3.5 Generic Megaraid Controllers Stream Detection and IO Coalescing

[Sasikumar Chandrasekaran]

Detect sequential IO streams and pass those IOs directly to FW.

This patch is depending on patch 3
This patch is same as V4 and there is no specific update for V5

Signed-off-by: Sasikumar Chandrasekaran 
Reviewed-by: Tomas Henzl 
---
 drivers/scsi/megaraid/megaraid_sas.h|   1 +
 drivers/scsi/megaraid/megaraid_sas_base.c   |  43 +++-
 drivers/scsi/megaraid/megaraid_sas_fp.c |   2 +
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 163 +++-
 drivers/scsi/megaraid/megaraid_sas_fusion.h | 117 +++-
 5 files changed, 295 insertions(+), 31 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index 36aac88..3d86bc6 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -2070,6 +2070,7 @@ struct megasas_instance {
/* used to sync fire the cmd to fw */
spinlock_t hba_lock;
/* used to synch producer, consumer ptrs in dpc */
+   spinlock_t stream_lock;
spinlock_t completion_lock;
struct dma_pool *frame_dma_pool;
struct dma_pool *sense_dma_pool;
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 5a1a53b..8e20992 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -5001,7 +5001,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, loop, fw_msix_count = 0;
+   int i, j, loop, fw_msix_count = 0;
struct IOV_111 *iovPtr;
struct fusion_context *fusion;
 
@@ -5194,6 +5194,36 @@ static int megasas_init_fw(struct megasas_instance 
*instance)
}
 
memset(instance->ld_ids, 0xff, MEGASAS_MAX_LD_IDS);
+
+   /* stream detection initialization */
+   if (instance->is_ventura) {
+   fusion->stream_detect_by_ld =
+   kzalloc(sizeof(struct LD_STREAM_DETECT *)
+   * MAX_LOGICAL_DRIVES_EXT,
+   GFP_KERNEL);
+   if (!fusion->stream_detect_by_ld) {
+   dev_err(>pdev->dev,
+   "unable to allocate stream detection 
for pool of LDs\n");
+   goto fail_get_ld_pd_list;
+   }
+   for (i = 0; i < MAX_LOGICAL_DRIVES_EXT; ++i) {
+   fusion->stream_detect_by_ld[i] =
+   kmalloc(sizeof(struct LD_STREAM_DETECT),
+   GFP_KERNEL);
+   if (!fusion->stream_detect_by_ld[i]) {
+   dev_err(>pdev->dev,
+   "unable to allocate stream detect by 
LD\n ");
+for (j = 0; j < i; ++j)
+   kfree(fusion->stream_detect_by_ld[j]);
+   kfree(fusion->stream_detect_by_ld);
+   fusion->stream_detect_by_ld = NULL;
+   goto fail_get_ld_pd_list;
+   }
+   fusion->stream_detect_by_ld[i]->mru_bit_map
+   = MR_STREAM_BITMAP;
+   }
+   }
+
if (megasas_ld_list_query(instance,
  MR_LD_QUERY_TYPE_EXPOSED_TO_HOST))
megasas_get_ld_list(instance);
@@ -5313,6 +5343,8 @@ static int megasas_init_fw(struct megasas_instance 
*instance)
 
return 0;
 
+fail_get_ld_pd_list:
+   instance->instancet->disable_intr(instance);
 fail_get_pd_list:
instance->instancet->disable_intr(instance);
 fail_init_adapter:
@@ -5846,6 +5878,7 @@ static int megasas_probe_one(struct pci_dev *pdev,
 
spin_lock_init(>mfi_pool_lock);
spin_lock_init(>hba_lock);
+   spin_lock_init(>stream_lock);
spin_lock_init(>completion_lock);
 
mutex_init(>reset_mutex);
@@ -6353,6 +6386,14 @@ static void megasas_detach_one(struct pci_dev *pdev)
if (instance->msix_vectors)
pci_free_irq_vectors(instance->pdev);
 
+   if (instance->is_ventura) {
+   for (i = 0; i < MAX_LOGICAL_DRIVES_EXT; ++i)
+   kfree(fusion->stream_detect_by_ld[i]);
+   kfree(fusion->stream_detect_by_ld);
+   fusion->stream_detect_by_ld = NULL;
+   }
+
+
if (instance->ctrl_context) {
megasas_release_fusion(instance);
pd_seq_map_sz = sizeof(struct MR_PD_CFG_SEQ_NUM_SYNC) +
diff --git a/drivers/scsi/megaraid/megaraid_sas_fp.c 
b/drivers/scsi/megaraid/megaraid_sas_fp.c
index f237d00..a4e213b 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fp.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fp.c
@@ -935,6 +935,8 @@ u8 

[PATCH V5 02/11] megaraid_sas: 128 MSIX Support

[Sasikumar Chandrasekaran]

SAS3.5 Generic Megaraid based Controllers will have the support for 128 MSI-X 
vectors,
resulting in the need to support 128 reply queues

This patch is depending on patch 1
This patch is same as V4 and there is no specific update for V5

Signed-off-by: Sasikumar Chandrasekaran 
---
 drivers/scsi/megaraid/megaraid_sas.h|  1 +
 drivers/scsi/megaraid/megaraid_sas_base.c   | 25 ++---
 drivers/scsi/megaraid/megaraid_sas_fusion.c |  4 ++--
 3 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index cb82195..36aac88 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -2148,6 +2148,7 @@ struct megasas_instance {
bool dev_handle;
bool fw_sync_cache_support;
bool is_ventura;
+   bool msix_combined;
 };
 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 ea04fce..5a1a53b 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -5072,13 +5072,7 @@ static int megasas_init_fw(struct megasas_instance 
*instance)
goto fail_ready_state;
}
 
-   /*
-* MSI-X host index 0 is common for all adapter.
-* It is used for all MPT based Adapters.
-*/
-   instance->reply_post_host_index_addr[0] =
-   (u32 __iomem *)((u8 __iomem *)instance->reg_set +
-   MPI2_REPLY_POST_HOST_INDEX_OFFSET);
+
 
/* Check if MSI-X is supported while in ready state */
msix_enable = (instance->instancet->read_fw_status_reg(reg_set) &
@@ -5098,6 +5092,9 @@ static int megasas_init_fw(struct megasas_instance 
*instance)
instance->msix_vectors = ((scratch_pad_2
& MR_MAX_REPLY_QUEUES_EXT_OFFSET)
>> 
MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT) + 1;
+   if (instance->msix_vectors > 16)
+   instance->msix_combined = true;
+
if (rdpq_enable)
instance->is_rdpq = (scratch_pad_2 & 
MR_RDPQ_MODE_OFFSET) ?
1 : 0;
@@ -5131,6 +5128,20 @@ static int megasas_init_fw(struct megasas_instance 
*instance)
else
instance->msix_vectors = 0;
}
+   /*
+* MSI-X host index 0 is common for all adapter.
+* It is used for all MPT based Adapters.
+*/
+   if (instance->msix_combined) {
+   instance->reply_post_host_index_addr[0] =
+   (u32 *)((u8 *)instance->reg_set +
+   MPI2_SUP_REPLY_POST_HOST_INDEX_OFFSET);
+   } else {
+   instance->reply_post_host_index_addr[0] =
+   (u32 *)((u8 *)instance->reg_set +
+   MPI2_REPLY_POST_HOST_INDEX_OFFSET);
+   }
+
i = pci_alloc_irq_vectors(instance->pdev, 1, 1, PCI_IRQ_LEGACY);
if (i < 0)
goto fail_setup_irqs;
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 8d7a397..413e2030 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -2391,7 +2391,7 @@ static void megasas_build_ld_nonrw_fusion(struct 
megasas_instance *instance,
 * pending to be completed
 */
if (threshold_reply_count >= THRESHOLD_REPLY_COUNT) {
-   if (fusion->adapter_type == INVADER_SERIES)
+   if (instance->msix_combined)
writel(((MSIxIndex & 0x7) << 24) |
fusion->last_reply_idx[MSIxIndex],

instance->reply_post_host_index_addr[MSIxIndex/8]);
@@ -2407,7 +2407,7 @@ static void megasas_build_ld_nonrw_fusion(struct 
megasas_instance *instance,
return IRQ_NONE;
 
wmb();
-   if (fusion->adapter_type == INVADER_SERIES)
+   if (instance->msix_combined)
writel(((MSIxIndex & 0x7) << 24) |
fusion->last_reply_idx[MSIxIndex],
instance->reply_post_host_index_addr[MSIxIndex/8]);
-- 
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 V5 06/11] megaraid_sas: Dynamic Raid Map Changes for SAS3.5 Generic Megaraid Controllers

[Sasikumar Chandrasekaran]

SAS3.5 Generic Megaraid Controllers FW will support new dynamic RaidMap to have 
different
sizes for different number of supported VDs.

This patch is depending on patch 5
Code indentation is fixed for VD_EXT_DEBUG macro

Signed-off-by: Sasikumar Chandrasekaran 
---
 drivers/scsi/megaraid/megaraid_sas.h|   7 +
 drivers/scsi/megaraid/megaraid_sas_base.c   |  53 --
 drivers/scsi/megaraid/megaraid_sas_fp.c | 254 +++-
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 219 +++-
 drivers/scsi/megaraid/megaraid_sas_fusion.h | 240 ++
 5 files changed, 636 insertions(+), 137 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index a96889c..6ddf994 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -1434,6 +1434,12 @@ 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_MAX_RAID_MAP_SIZE_OFFSET_SHIFT  16
+#define MR_MAX_RAID_MAP_SIZE_MASK  0x1FF
+#define MR_MIN_MAP_SIZE0x1
+/* 64k */
+
 #define MR_CAN_HANDLE_SYNC_CACHE_OFFSET0X0100
 
 /*
@@ -2151,6 +2157,7 @@ struct megasas_instance {
bool fw_sync_cache_support;
bool is_ventura;
bool msix_combined;
+   u16 max_raid_mapsize;
 };
 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 8e20992..92cb02f 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -4424,8 +4424,7 @@ int megasas_alloc_cmds(struct megasas_instance *instance)
 static void megasas_update_ext_vd_details(struct megasas_instance *instance)
 {
struct fusion_context *fusion;
-   u32 old_map_sz;
-   u32 new_map_sz;
+   u32 ventura_map_sz = 0;
 
fusion = instance->ctrl_context;
/* For MFI based controllers return dummy success */
@@ -4455,21 +4454,34 @@ static void megasas_update_ext_vd_details(struct 
megasas_instance *instance)
instance->supportmax256vd ? "Extended VD(240 VD)firmware" :
"Legacy(64 VD) firmware");
 
-   old_map_sz = sizeof(struct MR_FW_RAID_MAP) +
-   (sizeof(struct MR_LD_SPAN_MAP) *
-   (instance->fw_supported_vd_count - 1));
-   new_map_sz = sizeof(struct MR_FW_RAID_MAP_EXT);
-   fusion->drv_map_sz = sizeof(struct MR_DRV_RAID_MAP) +
-   (sizeof(struct MR_LD_SPAN_MAP) *
-   (instance->drv_supported_vd_count - 1));
+   if (instance->max_raid_mapsize) {
+   ventura_map_sz = instance->max_raid_mapsize *
+   MR_MIN_MAP_SIZE; /* 64k */
+   fusion->current_map_sz = ventura_map_sz;
+   fusion->max_map_sz = ventura_map_sz;
+   } else {
+   fusion->old_map_sz =  sizeof(struct MR_FW_RAID_MAP) +
+   (sizeof(struct MR_LD_SPAN_MAP) *
+   (instance->fw_supported_vd_count - 1));
+   fusion->new_map_sz =  sizeof(struct MR_FW_RAID_MAP_EXT);
 
-   fusion->max_map_sz = max(old_map_sz, new_map_sz);
+   fusion->max_map_sz =
+   max(fusion->old_map_sz, fusion->new_map_sz);
 
+   if (instance->supportmax256vd)
+   fusion->current_map_sz = fusion->new_map_sz;
+   else
+   fusion->current_map_sz = fusion->old_map_sz;
+   }
+   /* irrespective of FW raid maps, driver raid map is constant */
+   fusion->drv_map_sz = sizeof(struct MR_DRV_RAID_MAP_ALL);
 
-   if (instance->supportmax256vd)
-   fusion->current_map_sz = new_map_sz;
-   else
-   fusion->current_map_sz = old_map_sz;
+#if VD_EXT_DEBUG
+   dev_info(>pdev->dev, "instance->max_raid_mapsize 0x%x\n ", 
instance->max_raid_mapsize);
+   dev_info(>pdev->dev, "new_map_sz = 0x%x, old_map_sz = 
0x%x\n", fusion->new_map_sz, fusion->old_map_sz);
+   dev_info(>pdev->dev, "ventura_map_sz = 0x%x, current_map_sz = 
0x%x\n", ventura_map_sz, fusion->current_map_sz);
+   dev_info(>pdev->dev, "fusion->drv_map_sz =0x%x, size of 
driver raid map 0x%lx\n", fusion->drv_map_sz, sizeof(struct 
MR_DRV_RAID_MAP_ALL));
+#endif
 }
 
 /**
@@ -4996,7 +5008,7 @@ static int megasas_init_fw(struct megasas_instance 
*instance)
 {
u32 max_sectors_1;
u32 max_sectors_2;
-   u32 tmp_sectors, msix_enable, scratch_pad_2;
+   u32 tmp_sectors, msix_enable, scratch_pad_2, scratch_pad_3;
resource_size_t base_addr;
struct megasas_register_set __iomem 

[PATCH V5 03/11] megaraid_sas: EEDP Escape Mode Support for SAS3.5 Generic Megaraid Controllers

[Sasikumar Chandrasekaran]

An UNMAP command on a PI formatted device will leave the Logical Block 
Application
Tag and Logical Block Reference Tag as all F's (for those LBAs that are 
unmapped).
To avoid IO errors if those LBAs are subsequently read before they are written 
with
valid tag fields, the MPI SCSI IO requests need to set the EEDPFlags element 
EEDP
Escape Mode field, Bits [7:6] appropriately.  A value of 2 should be set to 
disable
all PI checks if the Logical Block Application Tag is 0x for PI types 1 and 
2.
A value of 3 should be set to disable all PI checks if the Logical Block 
Application
Tag is 0x and the Logical Block Reference Tag is 0x for PI type 3.

This patch is depending on patch 2
This patch is same as V4 and there is no specific update for V5

Signed-off-by: Sasikumar Chandrasekaran 
Reviewed-by: Tomas Henzl 
---
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 1 +
 drivers/scsi/megaraid/megaraid_sas_fusion.h | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 413e2030..fe69c4a 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -1589,6 +1589,7 @@ static int megasas_create_sg_sense_fusion(struct 
megasas_instance *instance)
MPI2_SCSIIO_EEDPFLAGS_CHECK_REFTAG |
MPI2_SCSIIO_EEDPFLAGS_CHECK_REMOVE_OP |
MPI2_SCSIIO_EEDPFLAGS_CHECK_APPTAG |
+   MPI25_SCSIIO_EEDPFLAGS_DO_NOT_DISABLE_MODE |
MPI2_SCSIIO_EEDPFLAGS_CHECK_GUARD);
} else {
io_request->EEDPFlags = cpu_to_le16(
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.h 
b/drivers/scsi/megaraid/megaraid_sas_fusion.h
index e3bee04..9d22ade 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.h
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.h
@@ -175,6 +175,8 @@ enum REGION_TYPE {
 #define MPI2_SCSIIO_EEDPFLAGS_CHECK_APPTAG  (0x0200)
 #define MPI2_SCSIIO_EEDPFLAGS_CHECK_GUARD   (0x0100)
 #define MPI2_SCSIIO_EEDPFLAGS_INSERT_OP (0x0004)
+/* EEDP escape mode */
+#define MPI25_SCSIIO_EEDPFLAGS_DO_NOT_DISABLE_MODE  (0x0040)
 #define MPI2_FUNCTION_SCSI_IO_REQUEST   (0x00) /* SCSI IO */
 #define MPI2_FUNCTION_SCSI_TASK_MGMT(0x01)
 #define MPI2_REQ_DESCRIPT_FLAGS_HIGH_PRIORITY   (0x03)
-- 
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 V5 05/11] megaraid_sas: SAS3.5 Generic Megaraid Controllers Fast Path for RAID 1/10 Writes

[Sasikumar Chandrasekaran]

To improve RAID 1/10 Write performance, OS drivers need to issue the required 
Write
IOs as Fast Path IOs (after the appropriate checks allowing Fast Path to be 
used)
to the appropriate physical drives (translated from the OS logical IO) and wait 
for
all Write IOs to complete.  If any of the Write IOs fail or time out, the IO 
will be
re issued to FW as an LD IO so FW can perform the error handling.

This patch is depending on patch 4
This patch is same as V4 and there is no specific update for V5

Signed-off-by: Sasikumar Chandrasekaran 
Reviewed-by: Tomas Henzl 
---
 drivers/scsi/megaraid/megaraid_sas.h|   1 +
 drivers/scsi/megaraid/megaraid_sas_fp.c |  31 ++-
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 335 
 drivers/scsi/megaraid/megaraid_sas_fusion.h |  15 +-
 4 files changed, 329 insertions(+), 53 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index 3d86bc6..a96889c 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -2056,6 +2056,7 @@ struct megasas_instance {
 
u16 max_num_sge;
u16 max_fw_cmds;
+   u16 max_mpt_cmds;
u16 max_mfi_cmds;
u16 max_scsi_cmds;
u16 ldio_threshold;
diff --git a/drivers/scsi/megaraid/megaraid_sas_fp.c 
b/drivers/scsi/megaraid/megaraid_sas_fp.c
index a4e213b..eb9ff44 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fp.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fp.c
@@ -737,7 +737,7 @@ static u8 mr_spanset_get_phy_params(struct megasas_instance 
*instance, u32 ld,
struct MR_DRV_RAID_MAP_ALL *map)
 {
struct MR_LD_RAID  *raid = MR_LdRaidGet(ld, map);
-   u32 pd, arRef;
+   u32 pd, arRef, r1_alt_pd;
u8  physArm, span;
u64 row;
u8  retval = TRUE;
@@ -772,9 +772,16 @@ static u8 mr_spanset_get_phy_params(struct 
megasas_instance *instance, u32 ld,
arRef   = MR_LdSpanArrayGet(ld, span, map);
pd  = MR_ArPdGet(arRef, physArm, map);
 
-   if (pd != MR_PD_INVALID)
+   if (pd != MR_PD_INVALID) {
*pDevHandle = MR_PdDevHandleGet(pd, map);
-   else {
+   /* get second pd also for raid 1/10 fast path writes*/
+   if (raid->level == 1) {
+   r1_alt_pd = MR_ArPdGet(arRef, physArm + 1, map);
+   if (r1_alt_pd != MR_PD_INVALID)
+   io_info->r1_alt_dev_handle =
+   MR_PdDevHandleGet(r1_alt_pd, map);
+   }
+   } else {
*pDevHandle = cpu_to_le16(MR_PD_INVALID);
if ((raid->level >= 5) &&
((fusion->adapter_type == THUNDERBOLT_SERIES)  ||
@@ -819,7 +826,7 @@ u8 MR_GetPhyParams(struct megasas_instance *instance, u32 
ld, u64 stripRow,
struct MR_DRV_RAID_MAP_ALL *map)
 {
struct MR_LD_RAID  *raid = MR_LdRaidGet(ld, map);
-   u32 pd, arRef;
+   u32 pd, arRef, r1_alt_pd;
u8  physArm, span;
u64 row;
u8  retval = TRUE;
@@ -867,10 +874,17 @@ u8 MR_GetPhyParams(struct megasas_instance *instance, u32 
ld, u64 stripRow,
arRef   = MR_LdSpanArrayGet(ld, span, map);
pd  = MR_ArPdGet(arRef, physArm, map); /* Get the pd */
 
-   if (pd != MR_PD_INVALID)
+   if (pd != MR_PD_INVALID) {
/* Get dev handle from Pd. */
*pDevHandle = MR_PdDevHandleGet(pd, map);
-   else {
+   /* get second pd also for raid 1/10 fast path writes*/
+   if (raid->level == 1) {
+   r1_alt_pd = MR_ArPdGet(arRef, physArm + 1, map);
+   if (r1_alt_pd != MR_PD_INVALID)
+   io_info->r1_alt_dev_handle =
+   MR_PdDevHandleGet(r1_alt_pd, map);
+   }
+   } else {
/* set dev handle as invalid. */
*pDevHandle = cpu_to_le16(MR_PD_INVALID);
if ((raid->level >= 5) &&
@@ -1126,6 +1140,11 @@ u8 MR_GetPhyParams(struct megasas_instance *instance, 
u32 ld, u64 stripRow,
/* If IO on an invalid Pd, then FP is not possible.*/
if (io_info->devHandle == cpu_to_le16(MR_PD_INVALID))
io_info->fpOkForIo = FALSE;
+   /* set raid 1/10 fast path write capable bit in io_info */
+   if (io_info->fpOkForIo &&
+   (io_info->r1_alt_dev_handle != MR_PD_INVALID) &&
+   (raid->level == 1) && !isRead)
+   io_info->is_raid_1_fp_write = 1;
return retval;
} else if (isRead) {
uint stripIdx;
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 16275d5..6faf188 100644
--- 

[PATCH V5 08/11] megaraid_sas: Enable or Disable Fast path based on the PCI Threshold Bandwidth

[Sasikumar Chandrasekaran]

Large SEQ IO workload should sent as non fast path commands

This patch is depending on patch 7
This patch is same as V4 and there is no specific update for V5

Signed-off-by: Sasikumar Chandrasekaran 
---
 drivers/scsi/megaraid/megaraid_sas.h|  8 +
 drivers/scsi/megaraid/megaraid_sas_base.c   | 48 +
 drivers/scsi/megaraid/megaraid_sas_fp.c |  6 
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 20 +++-
 drivers/scsi/megaraid/megaraid_sas_fusion.h |  2 +-
 5 files changed, 75 insertions(+), 9 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index 6ddf994..0696903 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT {
 #define MFI_1068_FW_HANDSHAKE_OFFSET   0x64
 #define MFI_1068_FW_READY  0x
 
+#define MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL HZ
+
 #define MR_MAX_REPLY_QUEUES_OFFSET  0X001F
 #define MR_MAX_REPLY_QUEUES_EXT_OFFSET  0X003FC000
 #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
@@ -2101,6 +2103,10 @@ struct megasas_instance {
atomic_t ldio_outstanding;
atomic_t fw_reset_no_pci_access;
 
+   atomic64_t bytes_wrote; /* used for raid1 fast path enable or disable */
+   atomic_t r1_write_fp_capable;
+
+
struct megasas_instance_template *instancet;
struct tasklet_struct isr_tasklet;
struct work_struct work_init;
@@ -2142,6 +2148,7 @@ struct megasas_instance {
long reset_flags;
struct mutex reset_mutex;
struct timer_list sriov_heartbeat_timer;
+   struct timer_list r1_fp_hold_timer;
char skip_heartbeat_timer_del;
u8 requestorId;
char PlasmaFW111;
@@ -2158,6 +2165,7 @@ struct megasas_instance {
bool is_ventura;
bool msix_combined;
u16 max_raid_mapsize;
+   u64 pci_threshold_bandwidth; /* used to control the fp writes */
 };
 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 4518ffc..15a894b 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -1940,6 +1940,9 @@ void megaraid_sas_kill_hba(struct megasas_instance 
*instance)
}
/* Complete outstanding ioctls when adapter is killed */
megasas_complete_outstanding_ioctls(instance);
+   if (instance->is_ventura)
+   del_timer_sync(>r1_fp_hold_timer);
+
 }
 
  /**
@@ -2438,6 +2441,24 @@ void megasas_sriov_heartbeat_handler(unsigned long 
instance_addr)
}
 }
 
+/*Handler for disabling/enabling raid 1 fast paths*/
+void megasas_change_r1_fp_status(unsigned long instance_addr)
+{
+   struct megasas_instance *instance =
+   (struct megasas_instance *)instance_addr;
+   if (atomic64_read(>bytes_wrote) >=
+   instance->pci_threshold_bandwidth) {
+
+   atomic64_set(>bytes_wrote, 0);
+   atomic_set(>r1_write_fp_capable, 0);
+   } else {
+   atomic64_set(>bytes_wrote, 0);
+   atomic_set(>r1_write_fp_capable, 1);
+   }
+   mod_timer(>r1_fp_hold_timer,
+jiffies + MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
+}
+
 /**
  * megasas_wait_for_outstanding -  Wait for all outstanding cmds
  * @instance:  Adapter soft state
@@ -5357,6 +5378,17 @@ static int megasas_init_fw(struct megasas_instance 
*instance)
instance->skip_heartbeat_timer_del = 1;
}
 
+   if (instance->is_ventura) {
+   atomic64_set(>bytes_wrote, 0);
+   atomic_set(>r1_write_fp_capable, 1);
+   megasas_start_timer(instance,
+   >r1_fp_hold_timer,
+   megasas_change_r1_fp_status,
+   MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
+   dev_info(>pdev->dev, "starting the 
raid 1 fp timer with interval %d\n",
+   MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
+   }
+
return 0;
 
 fail_get_ld_pd_list:
@@ -6147,6 +6179,9 @@ static void megasas_shutdown_controller(struct 
megasas_instance *instance,
if (instance->requestorId && !instance->skip_heartbeat_timer_del)
del_timer_sync(>sriov_heartbeat_timer);
 
+   if (instance->is_ventura)
+   del_timer_sync(>r1_fp_hold_timer);
+
megasas_flush_cache(instance);
megasas_shutdown_controller(instance, MR_DCMD_HIBERNATE_SHUTDOWN);
 
@@ -6273,6 +6308,16 @@ static void megasas_shutdown_controller(struct 
megasas_instance *instance,
megasas_setup_jbod_map(instance);
instance->unload = 0;
 
+   if (instance->is_ventura) {
+   

[PATCH V5 11/11] megaraid_sas: driver version upgrade

[Sasikumar Chandrasekaran]

Upgrade driver version.

This patch is depending on patch 10
This patch is same as V4 and there is no specific update for V5

Signed-off-by: Sasikumar Chandrasekaran 
Reviewed-by: Tomas Henzl 
---
 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 d2dc340..5412759 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.812.07.00-rc1"
-#define MEGASAS_RELDATE"August 22, 2016"
+#define MEGASAS_VERSION"07.700.00.00-rc1"
+#define MEGASAS_RELDATE"November 29, 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 V5 10/11] megaraid_sas: Implement the PD Map support for SAS3.5 Generic Megaraid Controllers

[Sasikumar Chandrasekaran]

Update Linux driver to use new pdTargetId field for JBOD target ID

This patch is depending on patch 9

Signed-off-by: Sasikumar Chandrasekaran 
---
 drivers/scsi/megaraid/megaraid_sas.h| 105 +---
 drivers/scsi/megaraid/megaraid_sas_base.c   |   3 +
 drivers/scsi/megaraid/megaraid_sas_fusion.c |   6 ++
 drivers/scsi/megaraid/megaraid_sas_fusion.h |   3 +-
 4 files changed, 89 insertions(+), 28 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index 0696903..d2dc340 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -1317,7 +1317,55 @@ struct megasas_ctrl_info {
 #endif
} adapterOperations3;
 
-   u8  pad[0x800-0x7EC];
+   struct {
+#if defined(__BIG_ENDIAN_BITFIELD)
+   u8 reserved:7;
+   /* Indicates whether the CPLD image is part of
+   *  the package and stored in flash
+   */
+   u8 cpld_in_flash:1;
+#else
+   u8 cpld_in_flash:1;
+   u8 reserved:7;
+#endif
+   u8 reserved1[3];
+   /* Null terminated string. Has the version
+   *  information if cpld_in_flash = FALSE
+   */
+   u8 userCodeDefinition[12];
+   } cpld;  /* Valid only if upgradableCPLD is TRUE */
+
+   struct {
+   #if defined(__BIG_ENDIAN_BITFIELD)
+   u16 reserved:8;
+   u16 fw_swaps_bbu_vpd_info:1;
+   u16 support_pd_map_target_id:1;
+   u16 support_ses_ctrl_in_multipathcfg:1;
+   u16 image_upload_supported:1;
+   u16 support_encrypted_mfc:1;
+   u16 supported_enc_algo:1;
+   u16 support_ibutton_less:1;
+   u16 ctrl_info_ext_supported:1;
+   #else
+
+   u16 ctrl_info_ext_supported:1;
+   u16 support_ibutton_less:1;
+   u16 supported_enc_algo:1;
+   u16 support_encrypted_mfc:1;
+   u16 image_upload_supported:1;
+   /* FW supports LUN based association and target port based */
+   u16 support_ses_ctrl_in_multipathcfg:1;
+   /* association for the SES device connected in multipath mode */
+/* FW defines Jbod target Id within MR_PD_CFG_SEQ */
+   u16 support_pd_map_target_id:1;
+   /* FW swaps relevant fields in MR_BBU_VPD_INFO_FIXED to
+   *  provide the data in little endian order
+   */
+   u16 fw_swaps_bbu_vpd_info:1;
+   u16 reserved:8;
+   #endif
+   } adapter_operations4;
+   u8 pad[0x800-0x7FE]; /* 0x7FE pad to 2K for expansion */
 } __packed;
 
 /*
@@ -1557,33 +1605,35 @@ struct megasas_header {
 typedef union _MFI_CAPABILITIES {
struct {
 #if   defined(__BIG_ENDIAN_BITFIELD)
-   u32 reserved:20;
-   u32 support_qd_throttling:1;
-   u32 support_fp_rlbypass:1;
-   u32 support_vfid_in_ioframe:1;
-   u32 support_ext_io_size:1;
-   u32 support_ext_queue_depth:1;
-   u32 security_protocol_cmds_fw:1;
-   u32 support_core_affinity:1;
-   u32 support_ndrive_r1_lb:1;
-   u32 support_max_255lds:1;
-   u32 support_fastpath_wb:1;
-   u32 support_additional_msix:1;
-   u32 support_fp_remote_lun:1;
+   u32 reserved:19;
+   u32 support_pd_map_target_id:1;
+   u32 support_qd_throttling:1;
+   u32 support_fp_rlbypass:1;
+   u32 support_vfid_in_ioframe:1;
+   u32 support_ext_io_size:1;
+   u32 support_ext_queue_depth:1;
+   u32 security_protocol_cmds_fw:1;
+   u32 support_core_affinity:1;
+   u32 support_ndrive_r1_lb:1;
+   u32 support_max_255lds:1;
+   u32 support_fastpath_wb:1;
+   u32 support_additional_msix:1;
+   u32 support_fp_remote_lun:1;
 #else
-   u32 support_fp_remote_lun:1;
-   u32 support_additional_msix:1;
-   u32 support_fastpath_wb:1;
-   u32 support_max_255lds:1;
-   u32 support_ndrive_r1_lb:1;
-   u32 support_core_affinity:1;
-   u32 security_protocol_cmds_fw:1;
-   u32 support_ext_queue_depth:1;
-   u32 support_ext_io_size:1;
-   u32 support_vfid_in_ioframe:1;
-   u32 support_fp_rlbypass:1;
-   u32 support_qd_throttling:1;
-   u32 reserved:20;
+   u32 support_fp_remote_lun:1;
+   u32 support_additional_msix:1;
+   u32 support_fastpath_wb:1;
+   u32 support_max_255lds:1;
+   u32 support_ndrive_r1_lb:1;
+   u32 support_core_affinity:1;
+   u32 

[PATCH V5 09/11] megaraid_sas: ldio_outstanding variable is not decremented in completion path

[Sasikumar Chandrasekaran]

ldio outstanding variable needs to be decremented in io completion path for
iMR dual queue depth

This patch is depending on patch 8
This patch is same as V4 and there is no specific update for V5

Signed-off-by: Sasikumar Chandrasekaran 
Reviewed-by: Tomas Henzl 
---
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 9b08de7..d4c78b0 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -2571,7 +2571,6 @@ void megasas_prepare_secondRaid1_IO(struct 
megasas_instance *instance,
 
if (atomic_inc_return(>fw_outstanding) >
instance->host->can_queue) {
-   dev_err(>pdev->dev, "Throttle IOs beyond Controller 
queue depth\n");
atomic_dec(>fw_outstanding);
return SCSI_MLQUEUE_HOST_BUSY;
}
@@ -2803,6 +2802,9 @@ void megasas_prepare_secondRaid1_IO(struct 
megasas_instance *instance,
extStatus, data_length, sense);
scsi_io_req->RaidContext.raid_context.status = 
0;
scsi_io_req->RaidContext.raid_context.ex_status 
= 0;
+   if (instance->ldio_threshold
+   && megasas_cmd_type(scmd_local) == 
READ_WRITE_LDIO)
+   atomic_dec(>ldio_outstanding);
megasas_return_cmd_fusion(instance, cmd_fusion);
scsi_dma_unmap(scmd_local);
scmd_local->scsi_done(scmd_local);
@@ -3951,7 +3953,8 @@ int megasas_reset_fusion(struct Scsi_Host *shost, int 
reason)
scmd_local->result =
megasas_check_mpio_paths(instance,
scmd_local);
-   if (megasas_cmd_type(scmd_local) == 
READ_WRITE_LDIO)
+   if (instance->ldio_threshold &&
+   megasas_cmd_type(scmd_local) == 
READ_WRITE_LDIO)
atomic_dec(>ldio_outstanding);
megasas_return_cmd_fusion(instance, cmd_fusion);
scsi_dma_unmap(scmd_local);
-- 
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 V5 00/11] megaraid_sas: Updates for scsi-next

[Sasikumar Chandrasekaran]

Sasikumar Chandrasekaran (11):
  megaraid_sas: Add new pci device Ids for SAS3.5 Generic Megaraid
Controllers
  megaraid_sas: 128 MSIX Support
  megaraid_sas: EEDP Escape Mode Support for SAS3.5 Generic Megaraid
Controllers
  megaraid_sas: SAS3.5 Generic Megaraid Controllers Stream Detection and
IO Coalescing
  megaraid_sas: SAS3.5 Generic Megaraid Controllers Fast Path for RAID
1/10 Writes
  megaraid_sas: Dynamic Raid Map Changes for SAS3.5 Generic Megaraid
Controllers
  megaraid_sas: Add the Support for SAS3.5 Generic Megaraid Controllers
Capabilities
  megaraid_sas: Enable or Disable Fast path based on the PCI Threshold
Bandwidth
  megaraid_sas: ldio_outstanding variable is not decremented in
completion path
  megaraid_sas: Implement the PD Map support for SAS3.5 Generic Megaraid
Controllers
  megaraid_sas: driver version upgrade

 drivers/scsi/megaraid/megaraid_sas.h| 139 --
 drivers/scsi/megaraid/megaraid_sas_base.c   | 233 +++--
 drivers/scsi/megaraid/megaraid_sas_fp.c | 293 +--
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 742 +++-
 drivers/scsi/megaraid/megaraid_sas_fusion.h | 364 --
 5 files changed, 1495 insertions(+), 276 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 V4 04/11] megaraid_sas: SAS3.5 Generic Megaraid Controllers Stream Detection and IO Coalescing

[Sasikumar PC]

Hi Tomas,

Please see my response inline

Thanks
sasi

-Original Message-
From: Tomas Henzl [mailto:the...@redhat.com]
Sent: Monday, December 12, 2016 11:39 AM
To: Sasikumar Chandrasekaran; j...@kernel.org; h...@infradead.org
Cc: linux-scsi@vger.kernel.org; sathya.prak...@broadcom.com;
linux-ker...@vger.kernel.org; christopher.ow...@broadcom.com;
kiran-kumar.kast...@broadcom.com
Subject: Re: [PATCH V4 04/11] megaraid_sas: SAS3.5 Generic Megaraid
Controllers Stream Detection and IO Coalescing

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> Detect sequential IO streams and pass those IOs directly to FW.
>
> This patch is depending on patch 3
>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas.h|   5 +-
>  drivers/scsi/megaraid/megaraid_sas_base.c   |  43 +++-
>  drivers/scsi/megaraid/megaraid_sas_fp.c |   2 +
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 164
> +++-
> drivers/scsi/megaraid/megaraid_sas_fusion.h | 117 +++-
>  5 files changed, 298 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
> b/drivers/scsi/megaraid/megaraid_sas.h
> index 9d4ca8d..d07b3e1 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -105,7 +105,7 @@
>   */
>
>  /*
> - * MFI stands for  MegaRAID SAS FW Interface. This is just a moniker
> for
> + * MFI stands for  MegaRAID SAS FW Interface. This is just a moniker
> + for
>   * protocol between the software and firmware. Commands are issued using
>   * "message frames"
>   */
> @@ -1440,7 +1440,7 @@ enum FW_BOOT_CONTEXT {
>  * register set for both 1068 and 1078 controllers
>  * structure extended for 1078 registers  */
> -
> +
>  struct megasas_register_set {
>   u32 doorbell;   /*h*/
>   u32 fusion_seq_offset;  /*0004h*/
> @@ -2070,6 +2070,7 @@ struct megasas_instance {
>   /* used to sync fire the cmd to fw */
>   spinlock_t hba_lock;
>   /* used to synch producer, consumer ptrs in dpc */
> + spinlock_t stream_lock;
>   spinlock_t completion_lock;
>   struct dma_pool *frame_dma_pool;
>   struct dma_pool *sense_dma_pool;
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index c583e0b..c52f7be 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -5015,7 +5015,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, loop, fw_msix_count = 0;
> + int i, j, loop, fw_msix_count = 0;
>   struct IOV_111 *iovPtr;
>   struct fusion_context *fusion;
>
> @@ -5202,6 +5202,36 @@ static int megasas_init_fw(struct megasas_instance
> *instance)
>   }
>
>   memset(instance->ld_ids, 0xff, MEGASAS_MAX_LD_IDS);
> +
> + /* stream detection initialization */
> + if (instance->is_ventura) {
> + fusion->stream_detect_by_ld =
> + kzalloc(sizeof(struct LD_STREAM_DETECT *)
> + * MAX_LOGICAL_DRIVES_EXT,
> + GFP_KERNEL);
> + if (!fusion->stream_detect_by_ld) {
> + dev_err(>pdev->dev,
> + "unable to allocate stream detection 
> for pool of LDs\n");
> + goto fail_get_ld_pd_list;
> + }
> + for (i = 0; i < MAX_LOGICAL_DRIVES_EXT; ++i) {
> + fusion->stream_detect_by_ld[i] =
> + kmalloc(sizeof(struct LD_STREAM_DETECT),
> + GFP_KERNEL);
> + if (!fusion->stream_detect_by_ld[i]) {
> + dev_err(>pdev->dev,
> + "unable to allocate stream detect by 
> LD\n ");
> +  for (j = 0; j < i; ++j)
> + kfree(fusion->stream_detect_by_ld[j]);
> + kfree(fusion->stream_detect_by_ld);
> + fusion->stream_detect_by_ld = NULL;
> + goto fail_get_ld_pd_list;
> + }
> + fusion->stream_detect_by_ld[i]->mru_bit_map
> + = MR_STREAM_BITMAP;
> + }
> + }
> +
>   if (megasas_ld_list_query(instance,
> MR_LD_QUERY_TYPE_EXPOSED_TO_HOST))
>   megasas_get_ld_list(instance);
> @@ -5321,6 +5351,8 @@ static int megasas_init_fw(struct
> megasas_instance *instance)
>
>   return 0;
>
> +fail_get_ld_pd_list:
> + instance->instancet->disable_intr(instance);
>  fail_get_pd_list:
>   instance->instancet->disable_intr(instance);
>   megasas_destroy_irqs(instance);
> 

RE: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast path based on the PCI Threshold Bandwidth

[Sasikumar PC]

Hi Tomas,

Please see my response inline

Thanks
sasi

-Original Message-
From: Tomas Henzl [mailto:the...@redhat.com]
Sent: Friday, December 09, 2016 8:59 AM
To: Sasikumar Chandrasekaran; j...@kernel.org; h...@infradead.org
Cc: linux-scsi@vger.kernel.org; sathya.prak...@broadcom.com;
linux-ker...@vger.kernel.org; christopher.ow...@broadcom.com;
kiran-kumar.kast...@broadcom.com
Subject: Re: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast path
based on the PCI Threshold Bandwidth

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> Large SEQ IO workload should sent as non fast path commands
>
> This patch is depending on patch 7
>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas.h|  8 +
>  drivers/scsi/megaraid/megaraid_sas_base.c   | 48
+
>  drivers/scsi/megaraid/megaraid_sas_fp.c | 11 +--
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 20 +++-
> drivers/scsi/megaraid/megaraid_sas_fusion.h |  2 +-
>  5 files changed, 78 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
> b/drivers/scsi/megaraid/megaraid_sas.h
> index 3e087ab..eb5be2b 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT {
>  #define MFI_1068_FW_HANDSHAKE_OFFSET 0x64
>  #define MFI_1068_FW_READY0x
>
> +#define MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL HZ
> +
>  #define MR_MAX_REPLY_QUEUES_OFFSET  0X001F
>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET  0X003FC000
>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
> @@ -2101,6 +2103,10 @@ struct megasas_instance {
>   atomic_t ldio_outstanding;
>   atomic_t fw_reset_no_pci_access;
>
> + atomic64_t bytes_wrote; /* used for raid1 fast path enable or
disable */
> + atomic_t r1_write_fp_capable;

Is a an atomic variable needed for a just boolean variable?
Sasi - As we need to synchronize timer thread and IO issue threads,
With atomic, at any point of time the value will be definitive.
With boolean, it depends, the value could be in transit while
one thread is reading and other is writing.

> +
> +
>   struct megasas_instance_template *instancet;
>   struct tasklet_struct isr_tasklet;
>   struct work_struct work_init;
> @@ -2143,6 +2149,7 @@ struct megasas_instance {
>   long reset_flags;
>   struct mutex reset_mutex;
>   struct timer_list sriov_heartbeat_timer;
> + struct timer_list r1_fp_hold_timer;
>   char skip_heartbeat_timer_del;
>   u8 requestorId;
>   char PlasmaFW111;
> @@ -2159,6 +2166,7 @@ struct megasas_instance {
>   bool is_ventura;
>   bool msix_combined;
>   u16 max_raid_mapsize;
> + u64 pci_threshold_bandwidth; /* used to control the fp writes */
>  };
>  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 8aafb59..899d25c 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -1940,6 +1940,9 @@ void megaraid_sas_kill_hba(struct megasas_instance
*instance)
>   }
>   /* Complete outstanding ioctls when adapter is killed */
>   megasas_complete_outstanding_ioctls(instance);
> + if (instance->is_ventura)
> + del_timer_sync(>r1_fp_hold_timer);
> +
>  }
>
>   /**
> @@ -2438,6 +2441,24 @@ void megasas_sriov_heartbeat_handler(unsigned
long instance_addr)
>   }
>  }
>
> +/*Handler for disabling/enabling raid 1 fast paths*/ void
> +megasas_change_r1_fp_status(unsigned long instance_addr) {
> + struct megasas_instance *instance =
> + (struct megasas_instance *)instance_addr;
> + if (atomic64_read(>bytes_wrote) >=
> + instance->pci_threshold_bandwidth)
{
> +
> + atomic64_set(>bytes_wrote, 0);
> + atomic_set(>r1_write_fp_capable, 0);
> + } else {
> + atomic64_set(>bytes_wrote, 0);
> + atomic_set(>r1_write_fp_capable, 1);
> + }
> + mod_timer(>r1_fp_hold_timer,
> +  jiffies + MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
> +}
> +
>  /**
>   * megasas_wait_for_outstanding -Wait for all outstanding cmds
>   * @instance:Adapter soft state
> @@ -5371,6 +5392,17 @@ static int megasas_init_fw(struct
megasas_instance *instance)
>   instance->skip_heartbeat_timer_del = 1;
>   }
>
> + if (instance->is_ventura) {
> + atomic64_set(>bytes_wrote, 0);
> + atomic_set(>r1_write_fp_capable, 1);
> + megasas_start_timer(instance,
> + >r1_fp_hold_timer,
> + megasas_change_r1_fp_status,
> +
MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
> + 

RE: [PATCH V4 07/11] megaraid_sas: Add the Support for SAS3.5 Generic Megaraid Controllers Capabilities

[Sasikumar PC]

Hi Tomas,

Please see my response inline

Thanks
sasi
-Original Message-
From: Tomas Henzl [mailto:the...@redhat.com]
Sent: Friday, December 09, 2016 8:14 AM
To: Sasikumar Chandrasekaran; j...@kernel.org; h...@infradead.org
Cc: linux-scsi@vger.kernel.org; sathya.prak...@broadcom.com;
linux-ker...@vger.kernel.org; christopher.ow...@broadcom.com;
kiran-kumar.kast...@broadcom.com
Subject: Re: [PATCH V4 07/11] megaraid_sas: Add the Support for SAS3.5
Generic Megaraid Controllers Capabilities

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> The Megaraid driver has to support the SAS3.5 Generic Megaraid
Controllers Firmware functionality.
>
> This patch is depending on patch 6
>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas_base.c   | 53
++---
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 19 ++-
> drivers/scsi/megaraid/megaraid_sas_fusion.h |  1 +
>  3 files changed, 37 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index 3f06b57..8aafb59 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -5057,34 +5057,29 @@ static int megasas_init_fw(struct
> megasas_instance *instance)
>
>   reg_set = instance->reg_set;
>
> - switch (instance->pdev->device) {
> - case PCI_DEVICE_ID_LSI_FUSION:
> - case PCI_DEVICE_ID_LSI_PLASMA:
> - case PCI_DEVICE_ID_LSI_INVADER:
> - case PCI_DEVICE_ID_LSI_FURY:
> - case PCI_DEVICE_ID_LSI_INTRUDER:
> - case PCI_DEVICE_ID_LSI_INTRUDER_24:
> - case PCI_DEVICE_ID_LSI_CUTLASS_52:
> - case PCI_DEVICE_ID_LSI_CUTLASS_53:
> + if (fusion)
>   instance->instancet = _instance_template_fusion;
> - break;
> - case PCI_DEVICE_ID_LSI_SAS1078R:
> - case PCI_DEVICE_ID_LSI_SAS1078DE:
> - instance->instancet = _instance_template_ppc;
> - break;
> - case PCI_DEVICE_ID_LSI_SAS1078GEN2:
> - case PCI_DEVICE_ID_LSI_SAS0079GEN2:
> - instance->instancet = _instance_template_gen2;
> - break;
> - case PCI_DEVICE_ID_LSI_SAS0073SKINNY:
> - case PCI_DEVICE_ID_LSI_SAS0071SKINNY:
> - instance->instancet = _instance_template_skinny;
> - break;
> - case PCI_DEVICE_ID_LSI_SAS1064R:
> - case PCI_DEVICE_ID_DELL_PERC5:
> - default:
> - instance->instancet = _instance_template_xscale;
> - break;
> + else {
> + switch (instance->pdev->device) {
> + case PCI_DEVICE_ID_LSI_SAS1078R:
> + case PCI_DEVICE_ID_LSI_SAS1078DE:
> + instance->instancet =
_instance_template_ppc;
> + break;
> + case PCI_DEVICE_ID_LSI_SAS1078GEN2:
> + case PCI_DEVICE_ID_LSI_SAS0079GEN2:
> + instance->instancet =
_instance_template_gen2;
> + break;
> + case PCI_DEVICE_ID_LSI_SAS0073SKINNY:
> + case PCI_DEVICE_ID_LSI_SAS0071SKINNY:
> + instance->instancet =
_instance_template_skinny;
> + break;
> + case PCI_DEVICE_ID_LSI_SAS1064R:
> + case PCI_DEVICE_ID_DELL_PERC5:
> + default:
> + instance->instancet =
_instance_template_xscale;
> + instance->pd_list_not_supported = 1;
> + break;
> + }
>   }
>
>   if (megasas_transition_to_ready(instance, 0)) { @@ -5828,7 +5823,9

> @@ static int megasas_probe_one(struct pci_dev *pdev,
>   if ((instance->pdev->device == PCI_DEVICE_ID_LSI_FUSION)
||
>   (instance->pdev->device ==
PCI_DEVICE_ID_LSI_PLASMA))
>   fusion->adapter_type = THUNDERBOLT_SERIES;
> - else if (!instance->is_ventura)
> + else if (instance->is_ventura)
> + fusion->adapter_type = VENTURA_SERIES;
> + else
>   fusion->adapter_type = INVADER_SERIES;
>   }
>   break;
> diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> index 58f86aa..f968a23 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> @@ -244,7 +244,10 @@ inline void megasas_return_cmd_fusion(struct
> megasas_instance *instance,
>
>   reg_set = instance->reg_set;
>
> - cur_max_fw_cmds =
readl(>reg_set->outbound_scratch_pad_3) & 0x00;
> + /* ventura FW does not fill outbound_scratch_pad_3 with queue
depth */
> + if (!instance->is_ventura)
> + cur_max_fw_cmds =
> + readl(>reg_set->outbound_scratch_pad_3) &
0x00;
>
>   if (dual_qdepth_disable || !cur_max_fw_cmds)

This test connected with the fact that ventura skips reading

RE: [PATCH V4 06/11] megaraid_sas: Dynamic Raid Map Changes for SAS3.5 Generic Megaraid Controllers

[Sasikumar PC]

Hi Tomas,

Please see my response inline

Thanks
sasi

-Original Message-
From: Tomas Henzl [mailto:the...@redhat.com]
Sent: Friday, December 09, 2016 7:55 AM
To: Sasikumar Chandrasekaran; j...@kernel.org; h...@infradead.org
Cc: linux-scsi@vger.kernel.org; sathya.prak...@broadcom.com;
linux-ker...@vger.kernel.org; christopher.ow...@broadcom.com;
kiran-kumar.kast...@broadcom.com
Subject: Re: [PATCH V4 06/11] megaraid_sas: Dynamic Raid Map Changes for
SAS3.5 Generic Megaraid Controllers

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> SAS3.5 Generic Megaraid Controllers FW will support new dynamic RaidMap
to have different
> sizes for different number of supported VDs.
>
> This patch is depending on patch 5
>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas.h|   7 +
>  drivers/scsi/megaraid/megaraid_sas_base.c   |  61 --
>  drivers/scsi/megaraid/megaraid_sas_fp.c | 303

>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 223 
>  drivers/scsi/megaraid/megaraid_sas_fusion.h | 240
++
>  5 files changed, 699 insertions(+), 135 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
b/drivers/scsi/megaraid/megaraid_sas.h
> index f4d6a94..3e087ab 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -1434,6 +1434,12 @@ 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_MAX_RAID_MAP_SIZE_OFFSET_SHIFT16
> +#define MR_MAX_RAID_MAP_SIZE_MASK0x1FF
> +#define MR_MIN_MAP_SIZE  0x1
> +/* 64k */
> +
>  #define MR_CAN_HANDLE_SYNC_CACHE_OFFSET  0X0100
>
>  /*
> @@ -2152,6 +2158,7 @@ struct megasas_instance {
>   bool fw_sync_cache_support;
>   bool is_ventura;
>   bool msix_combined;
> + u16 max_raid_mapsize;
>  };
>  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 c52f7be..3f06b57 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -4424,8 +4424,7 @@ int megasas_alloc_cmds(struct megasas_instance
*instance)
>  static void megasas_update_ext_vd_details(struct megasas_instance
*instance)
>  {
>   struct fusion_context *fusion;
> - u32 old_map_sz;
> - u32 new_map_sz;
> + u32 ventura_map_sz = 0;
>
>   fusion = instance->ctrl_context;
>   /* For MFI based controllers return dummy success */
> @@ -4455,21 +4454,39 @@ static void megasas_update_ext_vd_details(struct
megasas_instance *instance)
>   instance->supportmax256vd ? "Extended VD(240 VD)firmware"
:
>   "Legacy(64 VD) firmware");
>
> - old_map_sz = sizeof(struct MR_FW_RAID_MAP) +
> - (sizeof(struct MR_LD_SPAN_MAP) *
> - (instance->fw_supported_vd_count - 1));
> - new_map_sz = sizeof(struct MR_FW_RAID_MAP_EXT);
> - fusion->drv_map_sz = sizeof(struct MR_DRV_RAID_MAP) +
> - (sizeof(struct MR_LD_SPAN_MAP) *
> - (instance->drv_supported_vd_count - 1));
> -
> - fusion->max_map_sz = max(old_map_sz, new_map_sz);
> + if (instance->max_raid_mapsize) {
> + ventura_map_sz = instance->max_raid_mapsize *
> + MR_MIN_MAP_SIZE; /* 64k */
> + fusion->current_map_sz = ventura_map_sz;
> + fusion->max_map_sz = ventura_map_sz;
> + } else {
> + fusion->old_map_sz =  sizeof(struct MR_FW_RAID_MAP) +
> + (sizeof(struct MR_LD_SPAN_MAP) *
> + (instance->fw_supported_vd_count -
1));
> + fusion->new_map_sz =  sizeof(struct MR_FW_RAID_MAP_EXT);
>
> + fusion->max_map_sz =
> + max(fusion->old_map_sz, fusion->new_map_sz);
>
> - if (instance->supportmax256vd)
> - fusion->current_map_sz = new_map_sz;
> - else
> - fusion->current_map_sz = old_map_sz;
> + if (instance->supportmax256vd)
> + fusion->current_map_sz = fusion->new_map_sz;
> + else
> + fusion->current_map_sz = fusion->old_map_sz;
> + }
> + /* irrespective of FW raid maps, driver raid map is constant */
> + fusion->drv_map_sz = sizeof(struct MR_DRV_RAID_MAP_ALL);
> +#if VD_EXT_DEBUG
> + dev_info(>pdev->dev, "instance->max_raid_mapsize 0x%x \n
",
> + instance->max_raid_mapsize);
> + dev_info(>pdev->dev,
> + "new_map_sz = 0x%x, old_map_sz = 0x%x, "
> + "ventura_map_sz = 0x%x, current_map_sz = 0x%x "
> + 

[PATCH 1/1] scsi:fnic Avoid sending reset to fnic firmware when another reset is already in progress

[Satish Kharat]

This fix is to avoid calling fnic_fw_reset_handler through fnic_host_reset
when a finc reset is alreay in progress.

Signed-off-by: Satish Kharat 
Signed-off-by: Sesidhar Baddela 
---
 drivers/scsi/fnic/fnic.h  |  1 +
 drivers/scsi/fnic/fnic_scsi.c | 16 
 2 files changed, 17 insertions(+)

diff --git a/drivers/scsi/fnic/fnic.h b/drivers/scsi/fnic/fnic.h
index 9ddc920..9e4b770 100644
--- a/drivers/scsi/fnic/fnic.h
+++ b/drivers/scsi/fnic/fnic.h
@@ -248,6 +248,7 @@ struct fnic {
struct completion *remove_wait; /* device remove thread blocks */
 
atomic_t in_flight; /* io counter */
+   bool internal_reset_inprogress;
u32 _reserved;  /* fill hole */
unsigned long state_flags;  /* protected by host lock */
enum fnic_state state;
diff --git a/drivers/scsi/fnic/fnic_scsi.c b/drivers/scsi/fnic/fnic_scsi.c
index 2544a37..adb3d58 100644
--- a/drivers/scsi/fnic/fnic_scsi.c
+++ b/drivers/scsi/fnic/fnic_scsi.c
@@ -2581,6 +2581,19 @@ int fnic_host_reset(struct scsi_cmnd *sc)
unsigned long wait_host_tmo;
struct Scsi_Host *shost = sc->device->host;
struct fc_lport *lp = shost_priv(shost);
+   struct fnic *fnic = lport_priv(lp);
+   unsigned long flags;
+
+   spin_lock_irqsave(>fnic_lock, flags);
+   if (fnic->internal_reset_inprogress == 0) {
+   fnic->internal_reset_inprogress = 1;
+   } else {
+   spin_unlock_irqrestore(>fnic_lock, flags);
+   FNIC_SCSI_DBG(KERN_DEBUG, fnic->lport->host,
+   "host reset in progress skipping another host reset\n");
+   return SUCCESS;
+   }
+   spin_unlock_irqrestore(>fnic_lock, flags);
 
/*
 * If fnic_reset is successful, wait for fabric login to complete
@@ -2601,6 +2614,9 @@ int fnic_host_reset(struct scsi_cmnd *sc)
}
}
 
+   spin_lock_irqsave(>fnic_lock, flags);
+   fnic->internal_reset_inprogress = 0;
+   spin_unlock_irqrestore(>fnic_lock, flags);
return ret;
 }
 
-- 
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

Re: [PATCH 00/22] qla2xxx: Target code enhancemets and feature update

[Christoph Hellwig]

Hi Madhani,

lots of huge and not very useful changes in here.  Can you please
resend a series with just the obvious bug fixes for Linux 4.10 for
now while redoing the remaining patches?
--
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 08/22] qla2xxx: Refactore target code to remove symbol dependency

[Christoph Hellwig]

 - the new qla2x00_free_fcport is entirely pointless, please drop
   that part of the patch (and even if it wasn't pointless it should
   have been a patch on it's own)
 - please use struct names and not typedefs for your new structures
 - pretty much avery single items in your list should be a separate
   patch.  And some of them are actively counterproductive and should
   be dropped:

- Remove direct access of scsi_status field in se_cmd
- Remove se_cmd from qlt_do_ctio_completion
- Remove se_cmd access in srr code section
- Move se_cmd struct outside of qla_tgt_cmd/qla_tgt_mgmt_cmd.
--
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 v3] blk-mq: Fix failed allocation path when mapping queues

[Gabriel Krisman Bertazi]

From: Gabriel Krisman Bertazi 

In blk_mq_map_swqueue, there is a memory optimization that frees the
tags of a queue that has gone unmapped.  Later, if that hctx is remapped
after another topology change, the tags need to be reallocated.

If this allocation fails, a simple WARN_ON triggers, but the block layer
ends up with an active hctx without any corresponding set of tags.
Then, any income IO to that hctx can trigger an Oops.

I can reproduce it consistently by running IO, flipping CPUs on and off
and eventually injecting a memory allocation failure in that path.

In the fix below, if the system experiences a failed allocation of any
hctx's tags, we remap all the ctxs of that queue to the hctx_0, which
should always keep it's tags.  There is a minor performance hit, since
our mapping just got worse after the error path, but this is
the simplest solution to handle this error path.  The performance hit
will disappear after another successful remap.

I considered dropping the memory optimization all together, but it
seemed a bad trade-off to handle this very specific error case.

This should apply cleanly on top of Jens' for-next branch.

The Oops is the one below:

SP (3fff935ce4d0) is in userspace
1:mon> e
cpu 0x1: Vector: 300 (Data Access) at [c00fe99eb110]
pc: c05e868c: __sbitmap_queue_get+0x2c/0x180
lr: c0575328: __bt_get+0x48/0xd0
sp: c00fe99eb390
   msr: 90010280b033
   dar: 28
 dsisr: 4000
  current = 0xc00fe9966800
  paca= 0xc7e80300   softe: 0irq_happened: 0x01
pid   = 11035, comm = aio-stress
Linux version 4.8.0-rc6+ (root@bean) (gcc version 5.4.0 20160609
(Ubuntu/IBM 5.4.0-6ubuntu1~16.04.2) ) #3 SMP Mon Oct 10 20:16:53 CDT 2016
1:mon> s
[c00fe99eb3d0] c0575328 __bt_get+0x48/0xd0
[c00fe99eb400] c0575838 bt_get.isra.1+0x78/0x2d0
[c00fe99eb480] c0575cb4 blk_mq_get_tag+0x44/0x100
[c00fe99eb4b0] c056f6f4 __blk_mq_alloc_request+0x44/0x220
[c00fe99eb500] c0570050 blk_mq_map_request+0x100/0x1f0
[c00fe99eb580] c0574650 blk_mq_make_request+0xf0/0x540
[c00fe99eb640] c0561c44 generic_make_request+0x144/0x230
[c00fe99eb690] c0561e00 submit_bio+0xd0/0x200
[c00fe99eb740] c03ef740 ext4_io_submit+0x90/0xb0
[c00fe99eb770] c03e95d8 ext4_writepages+0x588/0xdd0
[c00fe99eb910] c025a9f0 do_writepages+0x60/0xc0
[c00fe99eb940] c0246c88 __filemap_fdatawrite_range+0xf8/0x180
[c00fe99eb9e0] c0246f90 filemap_write_and_wait_range+0x70/0xf0
[c00fe99eba20] c03dd844 ext4_sync_file+0x214/0x540
[c00fe99eba80] c0364718 vfs_fsync_range+0x78/0x130
[c00fe99ebad0] c03dd46c ext4_file_write_iter+0x35c/0x430
[c00fe99ebb90] c038c280 aio_run_iocb+0x3b0/0x450
[c00fe99ebce0] c038dc28 do_io_submit+0x368/0x730
[c00fe99ebe30] c0009404 system_call+0x38/0xec

Signed-off-by: Gabriel Krisman Bertazi 
Cc: Brian King 
Cc: Douglas Miller 
Cc: linux-bl...@vger.kernel.org
Cc: linux-scsi@vger.kernel.org
Reviewed-by: Douglas Miller 
---
 block/blk-mq.c | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/block/blk-mq.c b/block/blk-mq.c
index 4a052dd..2493b5d 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1884,7 +1884,7 @@ static void blk_mq_init_cpu_queues(struct request_queue 
*q,
 static void blk_mq_map_swqueue(struct request_queue *q,
   const struct cpumask *online_mask)
 {
-   unsigned int i;
+   unsigned int i, hctx_idx;
struct blk_mq_hw_ctx *hctx;
struct blk_mq_ctx *ctx;
struct blk_mq_tag_set *set = q->tag_set;
@@ -1907,6 +1907,21 @@ static void blk_mq_map_swqueue(struct request_queue *q,
if (!cpumask_test_cpu(i, online_mask))
continue;
 
+   hctx_idx = q->mq_map[i];
+   /* unmapped hw queue can be remapped after CPU topo changed */
+   if (!set->tags[hctx_idx]) {
+   set->tags[hctx_idx] = blk_mq_init_rq_map(set, hctx_idx);
+
+   /*
+* If tags initialization fail for some hctx,
+* that hctx won't be brought online.  In this
+* case, remap the current ctx to hctx[0] which
+* is guaranteed to always have tags allocated
+*/
+   if (!set->tags[hctx_idx])
+   q->mq_map[i] = 0;
+   }
+
ctx = per_cpu_ptr(q->queue_ctx, i);
hctx = blk_mq_map_queue(q, i);
 
@@ -1923,7 +1938,11 @@ static void blk_mq_map_swqueue(struct request_queue *q,
 * disable it and free the request entries.
  

Re: [PATCH 05/22] qla2xxx: Add DebugFS node of irq vector cpuid

[Christoph Hellwig]

On Tue, Dec 06, 2016 at 12:30:34PM -0800, Himanshu Madhani wrote:
> From: Quinn Tran 
> 
> > cat /sys/kernel/debug/qla2xxx/*/irq_cpuid
> qla2xxx_81
> IRQ Name  Vector  CPUID
> qla2xxx (default)  150 9
> qla2xxx (rsp_q)151 9
> qla2xxx (atio_q)   152 9

Doesn't make sense - an interrupt can be assigned to multiple
CPUIDs, and you can see the assignment based on the irq count
in /proc/interrupts
--
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 03/22] qla2xxx: Set tcm_qla2xxx version to automatically track qla2xxx version.

[Christoph Hellwig]

Please just remove TCM_QLA2XXX_VERSION entirely and use QLA2XXX_VERSION
directly instead.
--
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 01/22] qla2xxx: Fix wrong IOCB type assumption.

[Christoph Hellwig]

On Tue, Dec 06, 2016 at 12:30:30PM -0800, Himanshu Madhani wrote:
> + uint32_t unpacked_lun = 0;

Please remove the unpacked_lun variable as well, and just directly
pass 0 to qlt_issue_task_mgmt.
--
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 15/22] qla2xxx: Rename qlini_mode parameter

[Christoph Hellwig]

On Tue, Dec 06, 2016 at 12:30:44PM -0800, Himanshu Madhani wrote:
> From: Quinn Tran 
> 
> Qlogic's adapter is able to behave in multiple modes:
> initiator, target, exclusive/either, and dual/both.
> 
> This patch renames the qlini_mode -> qlop_mode and allow
> different setting for each port and exchange resource control.

Removing an old module parameter will break existing setups.  Please
add the new one overriding the old parameter, but don't remove the old
one.
--
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 14/22] qla2xxx: Add interrupt polling mechanism

[Christoph Hellwig]

On Tue, Dec 06, 2016 at 12:30:43PM -0800, Himanshu Madhani wrote:
> From: Quinn Tran 
> 
> This patch adds capability to poll for an interrupt, If hardware
> does not generate any interrupt for 2 seconds.

This description sounds like the hardware might be buggy and not
generate interrupts, in which case 2 seconds is a very long time.

Can you explain the intention a bit better?
--
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 11/22] qla2xxx: Refactor session management code.

[Christoph Hellwig]

On Tue, Dec 06, 2016 at 12:30:40PM -0800, Himanshu Madhani wrote:
>  9 files changed, 762 insertions(+), 474 deletions(-)

Again, a refactor that almost doubles the amount of code is a bad
one, please go back to the drawing board.
--
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 09/22] qla2xxx: Refactor T10-DIF PI support

[Christoph Hellwig]

On Tue, Dec 06, 2016 at 12:30:38PM -0800, Himanshu Madhani wrote:
> From: Quinn Tran 
> 
> qla2xxx currently access T10-DIF protection opcode and type
> field in se_cmd struct. Add translation code so qla2xxx driver
> would not acces private TCM data structure.

And what's the point of doing that?

>  11 files changed, 661 insertions(+), 242 deletions(-)

And independent of the above a "cleanup" that adds over 400 lines of
code is simply not acceptable.
--
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 v3] blk-mq: Fix failed allocation path when mapping queues

[Jens Axboe]

On 12/14/2016 01:48 PM, Gabriel Krisman Bertazi wrote:
> From: Gabriel Krisman Bertazi 
> 
> In blk_mq_map_swqueue, there is a memory optimization that frees the
> tags of a queue that has gone unmapped.  Later, if that hctx is remapped
> after another topology change, the tags need to be reallocated.
> 
> If this allocation fails, a simple WARN_ON triggers, but the block layer
> ends up with an active hctx without any corresponding set of tags.
> Then, any income IO to that hctx can trigger an Oops.
> 
> I can reproduce it consistently by running IO, flipping CPUs on and off
> and eventually injecting a memory allocation failure in that path.
> 
> In the fix below, if the system experiences a failed allocation of any
> hctx's tags, we remap all the ctxs of that queue to the hctx_0, which
> should always keep it's tags.  There is a minor performance hit, since
> our mapping just got worse after the error path, but this is
> the simplest solution to handle this error path.  The performance hit
> will disappear after another successful remap.
> 
> I considered dropping the memory optimization all together, but it
> seemed a bad trade-off to handle this very specific error case.

Thanks, this looks fine to me now. Both of your patches are queued
up for inclusion in 4.10.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] scsi: avoid a permanent stop of the scsi device's request queue

[Martin K. Petersen]

> "Wei" == Wei Fang  writes:

Wei> A race between scanning and fc_remote_port_delete() may result in a
Wei> permanent stop if the device gets blocked before
Wei> scsi_sysfs_add_sdev() and unblocked after.  The reason is that
Wei> blocking a device sets both the SDEV_BLOCKED state and the
Wei> QUEUE_FLAG_STOPPED.  However, scsi_sysfs_add_sdev() unconditionally
Wei> sets SDEV_RUNNING which causes the device to be ignored by
Wei> scsi_target_unblock() and thus never have its QUEUE_FLAG_STOPPED
Wei> cleared leading to a device which is apparently running but has a
Wei> stopped queue.

Wei> We actually have two places where SDEV_RUNNING is set: once in
Wei> scsi_add_lun() which respects the blocked flag and once in
Wei> scsi_sysfs_add_sdev() which doesn't.  Since the second set is
Wei> entirely spurious, simply remove it to fix the problem.

Applied to 4.10/scsi-fixes.

-- 
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 v2] mpt3sas: Recognize and act on iopriority info

[Martin K. Petersen]

> "Adam" == Adam Manzanares  writes:

Adam> This patch adds support for request iopriority handling in the
Adam> mpt3sas layer. This works only when a ATA device is behind the
Adam> SATL. The ATA device also has to indicate that it supports command
Adam> priorities in the identify information that is pulled from the
Adam> SATL.

Applied to 4.10/scsi-fixes.

-- 
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 00/22] qla2xxx: Target code enhancemets and feature update

[Madhani, Himanshu]

Hi Bart, 




On 12/12/16, 3:10 PM, "Madhani, Himanshu"  wrote:

>Hi Nic, 
>
>
>
>On 12/6/16, 12:30 PM, "Himanshu Madhani"  wrote:
>
>>Hi Nic, 
>>
>>Please consider this series for target-pending. This series is based on
>>scsi-misc series that was submitted earlier today.
>>
>>Here's link for that series
>> http://marc.info/?l=linux-scsi=148105128210090=2 
>>
>>This series contains following changes
>>
>>o Clean up Target code and tcm_qla2xxx for cleaner interaction.
>>o Enhanced and strengthen support for T10-DIF/PI.
>>o Renamed qlini_mode to qlop_mode for better readbility.
>>o Improve driver capability to manage dual personality 
>>  (i.e. Initiator and Target) simultaneously.
>>o Added capability to send non-critical MBX via IOCB path. 
>>o Some of the pending bug-fixes for target code.
>>
>>Thanks, 
>>Himanshu
>>
>>Himanshu Madhani (3):
>>  qla2xxx: Include ATIO queue in firmware dump when in target mode
>>  qla2xxx: Set tcm_qla2xxx version to automatically track qla2xxx
>>version.
>>  qla2xxx: Clear BIT 15 in NVRAM during initialization.
>>
>>Joe Carnuccio (1):
>>  qla2xxx: Rerfactor use of sp context
>>
>>Quinn Tran (18):
>>  qla2xxx: Fix wrong IOCB type assumption.
>>  qla2xxx: Add DebugFS node of irq vector cpuid
>>  qla2xxx: Collect addtional debug data for FW
>>  qla2xxx: Fix crash due to null pointer access.
>>  qla2xxx: Refactore target code to remove symbol dependency
>>  qla2xxx: Refactor T10-DIF PI support
>>  qla2xxx: Add framework for Async fabric discovery.
>>  qla2xxx: Refactor session management code.
>>  qla2xxx: Add Dual mode support in the driver
>>  qla2xxx: Fix invalid handle erroneous message.
>>  qla2xxx: Add interrupt polling mechanism
>>  qla2xxx: Rename qlini_mode parameter
>>  qla2xxx: Improve RSCN handling in driver
>>  qla2xxx: Fix slow mem alloc behind lock
>>  qla2xxx: Reduce exess wait during chip reset
>>  qla2xxx: Allow relogin to go through if remote login did not finish
>>  qla2xxx: Improve submission of non critical MB interface.
>>  qla2xxx: Add check for corrupt ATIO.
>>
>> drivers/scsi/qla2xxx/qla_attr.c|  366 -
>> drivers/scsi/qla2xxx/qla_bsg.c |   21 +-
>> drivers/scsi/qla2xxx/qla_dbg.c |2 +-
>> drivers/scsi/qla2xxx/qla_dbg.h |1 +
>> drivers/scsi/qla2xxx/qla_def.h |  287 +++-
>> drivers/scsi/qla2xxx/qla_dfs.c |  237 ++-
>> drivers/scsi/qla2xxx/qla_fw.h  |  107 +-
>> drivers/scsi/qla2xxx/qla_gbl.h |   86 +-
>> drivers/scsi/qla2xxx/qla_gs.c  |  733 -
>> drivers/scsi/qla2xxx/qla_init.c| 1604 +++-
>> drivers/scsi/qla2xxx/qla_inline.h  |   34 +-
>> drivers/scsi/qla2xxx/qla_iocb.c|  172 ++-
>> drivers/scsi/qla2xxx/qla_isr.c |  414 --
>> drivers/scsi/qla2xxx/qla_mbx.c |  553 +--
>> drivers/scsi/qla2xxx/qla_mid.c |   15 +-
>> drivers/scsi/qla2xxx/qla_mr.c  |   52 +-
>> drivers/scsi/qla2xxx/qla_os.c  |  454 --
>> drivers/scsi/qla2xxx/qla_target.c  | 2890 
>> +---
>> drivers/scsi/qla2xxx/qla_target.h  |  257 ++--
>> drivers/scsi/qla2xxx/qla_tmpl.c|   24 +
>> drivers/scsi/qla2xxx/tcm_qla2xxx.c |  753 --
>> drivers/scsi/qla2xxx/tcm_qla2xxx.h |   16 +-
>> 22 files changed, 6658 insertions(+), 2420 deletions(-)
>>
>>-- 
>>1.8.3.1
>>
>
>Would you please review/comment on these patches. 
>
>Thanks,
>Himanshu
>>

Can we get some review comments so that I can address them before sending 
updated series. 

Thanks,
- Himanshu
>

Re: [PATCH v5 0/5] qla2xxx: Feature updaes for driver.

[Martin K. Petersen]

> "Himanshu" == Himanshu Madhani  writes:

Himanshu> Please consider this revised series for inclusion into
Himanshu> scsi-misc.  This series has incorporated partial changes based
Himanshu> on review comments from Christoph and Hannes.

Applied to 4.10/scsi-fixes.

-- 
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 v2] scsi: hpsa: remove memory allocate failure message

[Martin K. Petersen]

> "Amit" == kushwaha a  writes:

Amit> This patch cleanup warning reported by checkpatch.pl WARNING:
Amit> Possible unnecessary 'out of memory' message With no available
Amit> memory, a warn on message already gets printed by page alloc apis
Amit> and modified goto use if memory unallocated.

Applied to 4.10/scsi-fixes.

-- 
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 RESEND] Update 3ware driver email addresses

[Martin K. Petersen]

> "Adam" == adam radford  writes:

Adam> This change updates the 3ware drivers (3w-, 3w-9xxx, 3w-sas)
Adam> email addresses from linuxr...@lsi.com to aradf...@gmail.com,
Adam> since the old email address doesn't exist.

Applied to 4.10/scsi-fixes.

Thanks for doing this!

-- 
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: Samsung SSD 1.92TB PM863 Enterprise 2.5" SATA3 errors withc stable 4.4.34

[Vasiliy Tolstov]

2016-12-14 15:48 GMT+03:00 Greg KH :
> Do you also have problems with this on the 4.9 kernel release?  We can't
> add any changes to 4.4 that is not already made in 4.9.


Thanks, i'm try to create reproducible fio test on 4.4.x and after
that go to 4.9

-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru
--
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: Samsung SSD 1.92TB PM863 Enterprise 2.5" SATA3 errors withc stable 4.4.34

[Vasiliy Tolstov]

2016-12-14 15:22 GMT+03:00 Johannes Thumshirn :
> Random shot in the dark, have you tried changing the cable?
> HostInt: HBA Internal error
> PHYRdyChg: PhyRdy signal changed state
> 10B8B: 10b to 8b decoding error occurred
> DevExch: Device presence has changed
>
> This could indicate a problem with the cabling and/or connectors.


This can happening, but i don't have cables - all disk attached to
motherboard via internal drive bay. And also - ssd is new and this
problem persists across many servers.

-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] zfcp fixes

[Martin K. Petersen]

> "Steffen" == Steffen Maier  writes:

Steffen,

Steffen> here is a series of important zfcp fixes all marked for stable.
Steffen> They apply to the fixes branch of James' scsi.git or to
Steffen> v4.9-rc8.

Applied to 4.10/scsi-fixes.

-- 
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] scsi: libcxgbi: return error if interface is not up

[Martin K. Petersen]

> "Varun" == Varun Prakash  writes:

Varun> Do not post hw active open cmd if IFF_UP is not set or link is
Varun> down on the interface, return -ENETDOWN in this case.

Applied to 4.10/scsi-fixes.

-- 
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] scsi: cxgb4i,libcxgbi: add missing module_put()

[Martin K. Petersen]

> "Varun" == Varun Prakash  writes:

Varun> Add module_put() in cxgbi_sock_act_open_req_arp_failure() to
Varun> release module reference in case of arp failure, also check
Varun> return value of try_module_get() before posting active open hw
Varun> cmd.

Applied to 4.10/scsi-fixes.

-- 
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 scsi 0/3] cxgb4i: add support for Chelsio T6 adapters

[Martin K. Petersen]

> "Varun" == Varun Prakash  writes:

Varun> This patch series adds support for Chelsio T6 adapters in iSCSI
Varun> initiator offload driver(cxgb4i).

Applied to 4.10/scsi-queue.

-- 
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 v3 3/3] qedi: Add QLogic FastLinQ offload iSCSI driver framework.

[Martin K. Petersen]

> "Manish" == Manish Rangankar  writes:

Manish> The QLogic FastLinQ Driver for iSCSI (qedi) is the iSCSI
Manish> specific module for 41000 Series Converged Network Adapters by
Manish> QLogic.

Applied to 4.10/scsi-fixes.

-- 
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

[Bug 176951] boot fails unless acpi=off Acer Travelmate X-349

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=176951

--- Comment #7 from mus@gmail.com ---
Update:

It seems like this was partly fixed by BIOS upgrade 1.07 (only available via
Windows Update).

Fedora x64 and Ubuntu x64 are confirmed to boot after the BIOS upgrade (see the
mentioned acer community thread).

However, Arch Linux x64 still doesn't boot and I haven't figured out the
difference yet. Arch has kernel 4.8.11 while Fedora boots fine with 4.8.6 and
4.8.13, so I doubt it's the kernel version.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: SCSI: usage of DID_REQUEUE vs DID_RESET for returning SCSI commands to be retried

[Kashyap Desai]

> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Hannes Reinecke
> Sent: Wednesday, December 14, 2016 9:07 PM
> To: Sumit Saxena; linux-scsi
> Subject: Re: SCSI: usage of DID_REQUEUE vs DID_RESET for returning SCSI
> commands to be retried
>
> On 12/13/2016 02:19 PM, Sumit Saxena wrote:
> > 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.
> >
> Hmm.
>
> DID_RESET is meant to be an indicator to the SCSI midlayer that the host /
> device was reset, and the command _should_ be retried.
> DID_REQUEUE OTOH is an indicator to the SCSI midlayer to retry the
> command.
>
> The problem with DID_RESET is that it's slightly underspecified; there is
> no
> indication if the command has been processed (and if so, up to which
> parts?)
> DID_REQUEUE, OTOH, will always cause a retry.
>
> So yeah, I guess DID_REQUEUE is a better choice here.

Thanks Hannes. We thought DID_REQUEUE functionality will be a better choice
and we are planning to move that with proposed patch.

Thanks for your feedback.  We will be sending the final patch to upstream.
Now, queuing this change for internal testing.


>
> 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
--
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: SCSI: usage of DID_REQUEUE vs DID_RESET for returning SCSI commands to be retried

[Hannes Reinecke]

On 12/13/2016 02:19 PM, Sumit Saxena wrote:

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.


Hmm.

DID_RESET is meant to be an indicator to the SCSI midlayer that the host 
/ device was reset, and the command _should_ be retried.

DID_REQUEUE OTOH is an indicator to the SCSI midlayer to retry the command.

The problem with DID_RESET is that it's slightly underspecified; there 
is no indication if the command has been processed (and if so, up to 
which parts?)

DID_REQUEUE, OTOH, will always cause a retry.

So yeah, I guess DID_REQUEUE is a better choice here.

Cheers,

Hannes
--
Dr. Hannes ReineckeTeamlead 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 RESEND v2 2/2] blk-mq: Avoid memory reclaim when remapping queues

[Jens Axboe]

On 12/06/2016 08:31 AM, Gabriel Krisman Bertazi wrote:
> While stressing memory and IO at the same time we changed SMT settings,
> we were able to consistently trigger deadlocks in the mm system, which
> froze the entire machine.
> 
> I think that under memory stress conditions, the large allocations
> performed by blk_mq_init_rq_map may trigger a reclaim, which stalls
> waiting on the block layer remmaping completion, thus deadlocking the
> system.  The trace below was collected after the machine stalled,
> waiting for the hotplug event completion.
> 
> The simplest fix for this is to make allocations in this path
> non-reclaimable, with GFP_NOIO.  With this patch, We couldn't hit the
> issue anymore.

This looks fine.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND v2 1/2] blk-mq: Fix failed allocation path when mapping queues

[Jens Axboe]

On 12/06/2016 08:31 AM, Gabriel Krisman Bertazi wrote:
> This should apply cleanly on top of Jen's for-next branch.

Jens, not Jen.

> @@ -1893,6 +1893,15 @@ static void blk_mq_map_swqueue(struct request_queue *q,
>   if (!cpumask_test_cpu(i, online_mask))
>   continue;
>  
> + hctx_idx = q->mq_map[i];
> + /* unmapped hw queue can be remapped after CPU topo changed */
> + if (!set->tags[hctx_idx]) {
> + set->tags[hctx_idx] = blk_mq_init_rq_map(set, hctx_idx);
> +
> + if (!set->tags[hctx_idx])
> + q->mq_map[i] = 0;
> + }

This needs a comment on why you're assigning mq_map[i] - because we keep
queue 0, in case the rest fail allocating.

> @@ -1917,11 +1929,8 @@ static void blk_mq_map_swqueue(struct request_queue *q,
>   continue;
>   }
>  
> - /* unmapped hw queue can be remapped after CPU topo changed */
> - if (!set->tags[i])
> - set->tags[i] = blk_mq_init_rq_map(set, i);
>   hctx->tags = set->tags[i];
> - WARN_ON(!hctx->tags);
> + BUG_ON(!hctx->tags);

No BUG_ON(), please, it's not necessary to take down the machine if this fails.
It might be game over for that machine, if the driver is hosting the data
or root fs, but it might not be.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Samsung SSD 1.92TB PM863 Enterprise 2.5" SATA3 errors withc stable 4.4.34

[Greg KH]

On Wed, Dec 14, 2016 at 03:07:48PM +0300, Vasiliy Tolstov wrote:
> Hi! I have stable problems with all Samsung SSD drivers like PM863 and
> EVO 850 Pro.
> 
> Time after time scsi bus reset link with messages:
> [ 2477.973617] ata1: exception Emask 0x50 SAct 0x0 SErr 0x4090800
> action 0xe frozen
> [ 2477.975036] ata1: irq_stat 0x00400040, connection status changed
> [ 2477.976396] ata1: SError: { HostInt PHYRdyChg 10B8B DevExch }
> [ 2477.977766] ata1: hard resetting link
> [ 2478.701015] ata1: SATA link down (SStatus 0 SControl 300)
> [ 2483.700924] ata1: hard resetting link
> [ 2484.020924] ata1: SATA link down (SStatus 0 SControl 300)
> [ 2484.022257] ata1: limiting SATA link speed to 1.5 Gbps
> [ 2489.020766] ata1: hard resetting link
> [ 2489.340828] ata1: SATA link down (SStatus 0 SControl 310)
> [ 2489.342158] ata1.00: disabled
> [ 2489.343452] ata1: EH complete
> [ 2489.344806] ata1.00: detaching (SCSI 0:0:0:0)
> [ 2489.347434] sd 0:0:0:0: [sda] Stopping disk
> [ 2489.348605] sd 0:0:0:0: [sda] Start/Stop Unit failed: Result:
> hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
> [ 3457.586929] ata1: exception Emask 0x10 SAct 0x0 SErr 0x404
> action 0xe frozen
> [ 3457.588224] ata1: irq_stat 0x0040, connection status changed
> [ 3457.589453] ata1: SError: { CommWake DevExch }
> [ 3457.590679] ata1: hard resetting link
> [ 3458.312616] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [ 3461.139831] ata1.00: ATA-9: SAMSUNG MZ7LM1T9HCJM-0E003, GXT3003Q,
> max UDMA/133
> [ 3461.141027] ata1.00: 3750748848 sectors, multi 16: LBA48 NCQ (depth
> 31/32), AA
> [ 3461.142882] ata1.00: configured for UDMA/133
> [ 3461.144004] ata1: EH complete
> [ 3461.145545] scsi 0:0:0:0: Direct-Access ATA SAMSUNG MZ7LM1T9 003Q
> PQ: 0 ANSI: 5
> [ 3461.147069] sd 0:0:0:0: Attached scsi generic sg0 type 0
> [ 3461.147082] sd 0:0:0:0: [sda] 3750748848 512-byte logical blocks:
> (1.92 TB/1.75 TiB)
> [ 3461.147649] sd 0:0:0:0: [sda] Write Protect is off
> [ 3461.147652] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> [ 3461.147849] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
> enabled, doesn't support DPO or FUA
> [ 3461.152457] sd 0:0:0:0: [sda] Attached SCSI removable disk
> 
> I'm try to remove drive and add it again message not appears may be
> one hour or more. I'm try different servers from HP and Supermicro and
> error is present. Also i'm try various disk from this series and
> nothing changed.
> 
> If i have massive workload like writing to ext4 fs on this ssd drivers
> i get corrupted ext4 journal and readonly fs.
> 
> My kernel version is 4.4.34
> May be some Samsung engineers presented in this mailing list and ca
> help to solve this errors? Or for server i need only Intel SSD (yes if
> i use intel ssd this error not happening, this is not intel
> advertising)

Do you also have problems with this on the 4.9 kernel release?  We can't
add any changes to 4.4 that is not already made in 4.9.

thanks,

greg k-h
--
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: Samsung SSD 1.92TB PM863 Enterprise 2.5" SATA3 errors withc stable 4.4.34

[Johannes Thumshirn]

On Wed, Dec 14, 2016 at 03:07:48PM +0300, Vasiliy Tolstov wrote:
> Hi! I have stable problems with all Samsung SSD drivers like PM863 and
> EVO 850 Pro.
> 
> Time after time scsi bus reset link with messages:
> [ 2477.973617] ata1: exception Emask 0x50 SAct 0x0 SErr 0x4090800
> action 0xe frozen
> [ 2477.975036] ata1: irq_stat 0x00400040, connection status changed
> [ 2477.976396] ata1: SError: { HostInt PHYRdyChg 10B8B DevExch }

Random shot in the dark, have you tried changing the cable?
HostInt: HBA Internal error
PHYRdyChg: PhyRdy signal changed state 
10B8B: 10b to 8b decoding error occurred
DevExch: Device presence has changed

This could indicate a problem with the cabling and/or connectors.

Byte,
Johannes

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
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

Samsung SSD 1.92TB PM863 Enterprise 2.5" SATA3 errors withc stable 4.4.34

[Vasiliy Tolstov]

Hi! I have stable problems with all Samsung SSD drivers like PM863 and
EVO 850 Pro.

Time after time scsi bus reset link with messages:
[ 2477.973617] ata1: exception Emask 0x50 SAct 0x0 SErr 0x4090800
action 0xe frozen
[ 2477.975036] ata1: irq_stat 0x00400040, connection status changed
[ 2477.976396] ata1: SError: { HostInt PHYRdyChg 10B8B DevExch }
[ 2477.977766] ata1: hard resetting link
[ 2478.701015] ata1: SATA link down (SStatus 0 SControl 300)
[ 2483.700924] ata1: hard resetting link
[ 2484.020924] ata1: SATA link down (SStatus 0 SControl 300)
[ 2484.022257] ata1: limiting SATA link speed to 1.5 Gbps
[ 2489.020766] ata1: hard resetting link
[ 2489.340828] ata1: SATA link down (SStatus 0 SControl 310)
[ 2489.342158] ata1.00: disabled
[ 2489.343452] ata1: EH complete
[ 2489.344806] ata1.00: detaching (SCSI 0:0:0:0)
[ 2489.347434] sd 0:0:0:0: [sda] Stopping disk
[ 2489.348605] sd 0:0:0:0: [sda] Start/Stop Unit failed: Result:
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[ 3457.586929] ata1: exception Emask 0x10 SAct 0x0 SErr 0x404
action 0xe frozen
[ 3457.588224] ata1: irq_stat 0x0040, connection status changed
[ 3457.589453] ata1: SError: { CommWake DevExch }
[ 3457.590679] ata1: hard resetting link
[ 3458.312616] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 3461.139831] ata1.00: ATA-9: SAMSUNG MZ7LM1T9HCJM-0E003, GXT3003Q,
max UDMA/133
[ 3461.141027] ata1.00: 3750748848 sectors, multi 16: LBA48 NCQ (depth
31/32), AA
[ 3461.142882] ata1.00: configured for UDMA/133
[ 3461.144004] ata1: EH complete
[ 3461.145545] scsi 0:0:0:0: Direct-Access ATA SAMSUNG MZ7LM1T9 003Q
PQ: 0 ANSI: 5
[ 3461.147069] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 3461.147082] sd 0:0:0:0: [sda] 3750748848 512-byte logical blocks:
(1.92 TB/1.75 TiB)
[ 3461.147649] sd 0:0:0:0: [sda] Write Protect is off
[ 3461.147652] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 3461.147849] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[ 3461.152457] sd 0:0:0:0: [sda] Attached SCSI removable disk

I'm try to remove drive and add it again message not appears may be
one hour or more. I'm try different servers from HP and Supermicro and
error is present. Also i'm try various disk from this series and
nothing changed.

If i have massive workload like writing to ext4 fs on this ssd drivers
i get corrupted ext4 journal and readonly fs.

My kernel version is 4.4.34
May be some Samsung engineers presented in this mailing list and ca
help to solve this errors? Or for server i need only Intel SSD (yes if
i use intel ssd this error not happening, this is not intel
advertising)

-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru
--
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 6/6] media/cobalt: use pci_irq_allocate_vectors

[Hans Verkuil]

On 14/12/16 11:47, Christoph Hellwig wrote:

On Wed, Dec 14, 2016 at 11:37:17AM +0100, Hans Verkuil wrote:

Completely forgot this. Is it OK to queue it for 4.11? Or is it blocking
other follow-up work you want to do for 4.10?


My plan was to see if Bjorn would take the patch to do the trivial removal
of pci_enable_msix_exact and pci_enable_msix_range even as a late 4.10 patch
given it's so harmless, but either way there is follow work pending ASAP
so getting it in for 4.10 would be very helpful.



OK, then I'll make a pull request for 4.10 tomorrow.

Regards,

Hans
--
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 6/6] media/cobalt: use pci_irq_allocate_vectors

[Christoph Hellwig]

On Wed, Dec 14, 2016 at 11:37:17AM +0100, Hans Verkuil wrote:
> Completely forgot this. Is it OK to queue it for 4.11? Or is it blocking
> other follow-up work you want to do for 4.10?

My plan was to see if Bjorn would take the patch to do the trivial removal
of pci_enable_msix_exact and pci_enable_msix_range even as a late 4.10 patch
given it's so harmless, but either way there is follow work pending ASAP
so getting it in for 4.10 would be very helpful.
--
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 6/6] media/cobalt: use pci_irq_allocate_vectors

[Hans Verkuil]

On 14/12/16 11:29, Christoph Hellwig wrote:

Hi Hans,

just checked the current Linux tree and cobalt still uses the old
pci_enable_msi_range call.  Did you queue this patch up for 4.10?
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



Completely forgot this. Is it OK to queue it for 4.11? Or is it blocking
other follow-up work you want to do for 4.10?

Regards,

Hans
--
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 6/6] media/cobalt: use pci_irq_allocate_vectors

[Christoph Hellwig]

Hi Hans,

just checked the current Linux tree and cobalt still uses the old
pci_enable_msi_range call.  Did you queue this patch up for 4.10?
--
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