Re: [PATCH 07/20] [SCSI] mpt3sas: Bump mpt3sas Driver version to v5.100.00.00
Sreekanth Reddy sreekanth.re...@avagotech.com writes: Bump mpt3sas Driver version to v5.100.00.00 Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line unsubscribe linux-scsi in
Re: [PATCH v1 06/20] [SCSI] mpt3sas: Provides the physical location of sas drives
Sreekanth Reddy sreekanth.re...@avagotech.com writes: This Patch will provide more details of the devices such as slot number, enclosure logical id, enclosure level connector name in the following scenarios, - When end device is added in the topology, - When the end device is removed from the setup, - When the SCSI mid layer issues TASK ABORT/ DEVICE RESET/ TARGET RESET during error handling, - When any command to the device fails with Sense key Hardware error or Medium error or Unit Attention, - When firmware returns device error or device not ready status for the end device, - When a Predicted fault is detected on an end device. This information can be used by the user to identify the location of the desired drive in the topology. Driver will get these information by reading the sas device page0. Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line unsubscribe linux-scsi in
Re: [PATCH 15/20] [SCSI] mpt3sas: Return host busy error status to SML when DMA mapping of scatter gather list fails for a SCSI command
Sreekanth Reddy sreekanth.re...@avagotech.com writes: scsi_dma_map API will return a negative value (i.e. -ENOMEM) if DMA mapping of sg lists fails and zero if the sg list in the SCSI cmd is NULL. But drivers doesn't handled sg list DMA mapping failure case properly. Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line unsubscribe linux-scsi in
Re: [PATCH 20/20] [SCSI] mpt3sas : Bump mpt3sas driver version to 9.100.00.00
Sreekanth Reddy sreekanth.re...@avagotech.com writes: Bump mpt3sas driver version to 9.100.00.00 Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line unsubscribe linux-scsi in
Re: [PATCH 10/20] [SCSI] mpt3sas: Add branding string support for OEM's HBA
Sreekanth Reddy sreekanth.re...@avagotech.com writes: Added the following Dell branding to the mpt3sas driver. VendorID DeviceID SubsystemVendor ID SubsystemDevice ID Dell Branding String 0x1000 0x0097 0x1028 0x1F46 DELL 12Gbps HBA Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line unsubscribe linux-scsi in
Re: [PATCH 14/20 v1] [SCSI] mpt3sas: Complete the SCSI command with DID_RESET status for log_info value 0x0x32010081
Sreekanth Reddy sreekanth.re...@avagotech.com writes: For any SCSI command, if the driver receives IOC status = SCSI_IOC_TERMINATED and log info = 0x32010081 then that command will be completed with DID_RESET host status. The definition of this log info value is Virtual IO has failed and has to be retried. Firmware will provide this log info value with IOC Status SCSI_IOC_TERMINATED, whenever a drive (with is a part of a volume) is pulled and pushed back within some minimal delay. With this log info value, firmware informs the driver to retry the failed IO command infinite times, so to provide some time for the firmware to discover the reinserted drive successfully instated of just retrying failed command for five times(doesn't giving enough time for firmware to complete the drive discovery) and failing the IO permanently even though drive came back successfully. Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line unsubscribe linux-scsi in
Re: [PATCH 12/20] [SCSI] mpt3sas: Bump mpt3sas driver version to v6.100.00.00
Sreekanth Reddy sreekanth.re...@avagotech.com writes: Bump mpt3sas driver version to v6.100.00.00. Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line unsubscribe linux-scsi in
Re: [PATCH 11/20] [SCSI] mpt3sas: Add branding string support for OEM custom HBA
Sreekanth Reddy sreekanth.re...@avagotech.com writes: Add the following OEM's branding to the mpt3sas driver. VendorID DeviceID SubsystemVendor ID SubsystemDevice ID Cisco Branding String 0x1000 0x97 SVID = 0x1137 0x014C Cisco 9300-8E 12G SAS HBA I'm not so keen on all this branding stuff. It is purely cosmetic and doesn't change driver behavior. Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line unsubscribe linux-scsi in
[PATCH 0/2] IBM CXL Flash Superpipe
This patch set is intended for the 4.3 release and adds support for the superpipe features provided by the IBM CXL Flash adapter. This function was originally presented in an RFC patch set in late April. To ease the digestion of these enhancements, we have further split it across the two patches in this set. The IBM Power processor architecture provides support for CAPI (Coherent Accelerator Power Interface), which is available to certain PCIe slots on Power 8 systems. CAPI can be thought of as a special tunneling protocol through PCIe that allow PCIe adapters to look like special purpose co-processors which can read or write an application's memory and generate page faults. As a result, the host interface to an adapter running in CAPI mode does not require data buffers to be mapped to the device's memory (IOMMU bypass) nor does it require memory to be pinned. Application specific accelerators are constructed by burning logic to either an FPGA or ASIC that accelerates a certain function in hardware. This logic is referred to as an Accelerator Function Unit or AFU. AFUs and their associated software are designed to leverage the benefits that CAPI provides to reduce the burden on CPUs and achieve higher performance. Examples of AFUs include compression, encryption, sorting, etc. The cxlflash adapter contains an AFU that enhances the performance of accessing an external flash storage device by allowing user space applications to establish a 'superpipe' through which they may directly access the storage, bypassing the traditional storage stack and reducing path length per-I/O by more than an order of magnitude. The AFU also supports a translation function that allows users to segment a physical device into 'n' virtual devices [by programmatic means] and refer to these segments as if they were a true physical device. This function enables a more efficient use of a physical device and provides for a secure multi-tenant environment. At a high-level, the cxlflash adapter looks and behaves very much like a SCSI HBA. Like other SCSI adapters it understands SCSI CDBs and LUN discovery. It also provides health monitoring, error recovery, and link event reporting. At a lower level, the cxlflash adapter requires some additional items not found in a traditional SCSI HBA driver. These include the following: - A programmatic API (implemented as ioctls) that user applications interact with when they desire to take advantage of the superpipe access from user space. These ioctls allow the user to gain access to the CAPI resources (ie: interrupts, MMIO space, etc.) that are required to use the superpipe. Additionally, they allow applications to use the AFUs virtual partitioning function. Note that while the ioctls are new, under the covers they make use of existing functionality found in the cxl driver (drivers/misc/cxl). - A block allocation table (implemented as a bitmap) per physical device attached to the cxlflash adapter that is operating in the virtual partitioned mode. This table manages the segmentation of the physical device and is used to derive the entries found in the LUN mapping table. - A LUN mapping table that is shared with the AFU and used by the AFU to associate the resource handles referring to a specific virtual device with blocks on the physical device. - The ability to send a limited set of SCSI commands directly to the adapter to determine capacity and identification data as well as wipe blocks that are no longer in use when a virtual device is released. This set of commands includes READ_CAPACITY and WRITE_SAME. Accompanying this adapter driver but not included here is a user space library (known as the block library) that will hide the interaction between user space and the cxlflash driver. Most (if not all) users will chose to use this library when developing superpipe-aware applications. The block library can be found on Github: https://github.com/mikehollinger/ibmcapikv More technical details are found within Documentation/powerpc/cxlflash.txt The following patches are bisectable: Patch 1 contains base enablement of superpipe function. Patch 2 adds support for segmentation of physical LUNs from user space. Matthew R. Ochs (2): cxlflash: Base superpipe support cxlflash: Virtual LUN support Documentation/powerpc/cxlflash.txt | 298 ++ drivers/scsi/cxlflash/Makefile |2 +- drivers/scsi/cxlflash/common.h | 18 + drivers/scsi/cxlflash/main.c | 12 + drivers/scsi/cxlflash/superpipe.c | 1884 drivers/scsi/cxlflash/superpipe.h | 210 drivers/scsi/cxlflash/vlun.c | 1096 + include/uapi/scsi/cxlflash_ioctl.h | 159 +++ 8 files changed, 3678 insertions(+), 1 deletion(-) create mode 100644 Documentation/powerpc/cxlflash.txt create mode 100644 drivers/scsi/cxlflash/superpipe.c create mode 100644 drivers/scsi/cxlflash/superpipe.h create mode 100644 drivers/scsi/cxlflash/vlun.c create
[PATCH 1/2] cxlflash: Base superpipe support
Add superpipe supporting infrastructure to device driver for the IBM CXL Flash adapter. This patch allows userspace applications to take advantage of the accelerated I/O features that this adapter provides and bypass the traditional filesystem stack. Signed-off-by: Matthew R. Ochs mro...@linux.vnet.ibm.com Signed-off-by: Manoj N. Kumar ma...@linux.vnet.ibm.com --- Documentation/powerpc/cxlflash.txt | 298 ++ drivers/scsi/cxlflash/Makefile |2 +- drivers/scsi/cxlflash/common.h | 18 + drivers/scsi/cxlflash/main.c | 12 + drivers/scsi/cxlflash/superpipe.c | 1856 drivers/scsi/cxlflash/superpipe.h | 210 include/uapi/scsi/cxlflash_ioctl.h | 159 +++ 7 files changed, 2554 insertions(+), 1 deletion(-) create mode 100644 Documentation/powerpc/cxlflash.txt create mode 100644 drivers/scsi/cxlflash/superpipe.c create mode 100644 drivers/scsi/cxlflash/superpipe.h create mode 100644 include/uapi/scsi/cxlflash_ioctl.h diff --git a/Documentation/powerpc/cxlflash.txt b/Documentation/powerpc/cxlflash.txt new file mode 100644 index 000..c4d3849 --- /dev/null +++ b/Documentation/powerpc/cxlflash.txt @@ -0,0 +1,298 @@ +Introduction + + +The IBM Power architecture provides support for CAPI (Coherent +Accelerator Power Interface), which is available to certain PCIe slots +on Power 8 systems. CAPI can be thought of as a special tunneling +protocol through PCIe that allow PCIe adapters to look like special +purpose co-processors which can read or write an application's +memory and generate page faults. As a result, the host interface to +an adapter running in CAPI mode does not require the data buffers to +be mapped to the device's memory (IOMMU bypass) nor does it require +memory to be pinned. + +On Linux, Coherent Accelerator (CXL) kernel services present CAPI +devices as a PCI device by implementing a virtual PCI host bridge. +This abstraction simplifies the infrastructure and programming +model, allowing for drivers to look similar to other native PCI +device drivers. + +CXL provides a mechanism by which user space applications can +directly talk to a device (network or storage) bypassing the typical +kernel/device driver stack. The CXL Flash Adapter Driver enables a +user space application direct access to Flash storage. + +The CXL Flash Adapter Driver is a kernel module that sits in the +SCSI stack as a low level device driver (below the SCSI disk and +protocol drivers) for the IBM CXL Flash Adapter. This driver is +responsible for the initialization of the adapter, setting up the +special path for user space access, and performing error recovery. It +communicates directly the Flash Accelerator Functional Unit (AFU) +as described in Documentation/powerpc/cxl.txt. + +The cxlflash driver supports two, mutually exclusive, modes of +operation at the device (LUN) level: + +- Any flash device (LUN) can be configured to be accessed as a + regular disk device (i.e.: /dev/sdc). This is the default mode. + +- Any flash device (LUN) can be configured to be accessed from + user space with a special block library. This mode further + specifies the means of accessing the device and provides for + either raw access to the entire LUN (referred to as direct + or physical LUN access) or access to a kernel/AFU-mediated + partition of the LUN (referred to as virtual LUN access). The + segmentation of a disk device into virtual LUNs is assisted + by special translation services provided by the Flash AFU. + +Overview + + +The Coherent Accelerator Interface Architecture (CAIA) introduces a +concept of a master context. A master typically has special privileges +granted to it by the kernel or hypervisor allowing it to perform AFU +wide management and control. The master may or may not be involved +directly in each user I/O, but at the minimum is involved in the +initial setup before the user application is allowed to send requests +directly to the AFU. + +The CXL Flash Adapter Driver establishes a master context with the +AFU. It uses memory mapped I/O (MMIO) for this control and setup. The +Adapter Problem Space Memory Map looks like this: + + +---+ + |512 * 64 KB User MMIO | + |(per context) | + | User Accessible | + +---+ + |512 * 128 B per context| + |Provisioning and Control | + | Trusted Process accessible | + +---+ + | 64 KB Global | +
[PATCH 2/2] cxlflash: Virtual LUN support
Add support for physical LUN segmentation (virtual LUNs) to device
driver supporting the IBM CXL Flash adapter. This patch allows user
space applications to virtually segment a physical LUN into N virtual
LUNs, taking advantage of the translation features provided by this card.
Signed-off-by: Matthew R. Ochs mro...@linux.vnet.ibm.com
Signed-off-by: Manoj N. Kumar ma...@linux.vnet.ibm.com
---
drivers/scsi/cxlflash/Makefile|2 +-
drivers/scsi/cxlflash/superpipe.c | 28 +
drivers/scsi/cxlflash/vlun.c | 1096 +
3 files changed, 1125 insertions(+), 1 deletion(-)
create mode 100644 drivers/scsi/cxlflash/vlun.c
diff --git a/drivers/scsi/cxlflash/Makefile b/drivers/scsi/cxlflash/Makefile
index 3de309c..fac300b 100644
--- a/drivers/scsi/cxlflash/Makefile
+++ b/drivers/scsi/cxlflash/Makefile
@@ -1,2 +1,2 @@
obj-$(CONFIG_CXLFLASH) += cxlflash.o
-cxlflash-y += main.o superpipe.o
+cxlflash-y += main.o superpipe.o vlun.o
diff --git a/drivers/scsi/cxlflash/superpipe.c
b/drivers/scsi/cxlflash/superpipe.c
index 4ea6c72..1237172 100644
--- a/drivers/scsi/cxlflash/superpipe.c
+++ b/drivers/scsi/cxlflash/superpipe.c
@@ -29,6 +29,19 @@
struct cxlflash_global global;
/**
+ * marshall_rele_to_resize() - translate release to resize structure
+ * @rele: Source structure from which to translate/copy.
+ * @resize:Destination structure for the translate/copy.
+ */
+static void marshall_rele_to_resize(struct dk_cxlflash_release *release,
+ struct dk_cxlflash_resize *resize)
+{
+ resize-hdr = release-hdr;
+ resize-context_id = release-context_id;
+ resize-rsrc_handle = release-rsrc_handle;
+}
+
+/**
* marshall_det_to_rele() - translate detach to release structure
* @detach:Destination structure for the translate/copy.
* @rele: Source structure from which to translate/copy.
@@ -172,6 +185,7 @@ void cxlflash_list_terminate(void)
spin_lock_irqsave(global.slock, flags);
list_for_each_entry_safe(lun_info, temp, global.luns, list) {
list_del(lun_info-list);
+ cxlflash_ba_terminate(lun_info-blka.ba_lun);
kfree(lun_info);
}
@@ -611,6 +625,7 @@ int cxlflash_disk_release(struct scsi_device *sdev,
struct lun_info *lun_info = sdev-hostdata;
struct afu *afu = cfg-afu;
+ struct dk_cxlflash_resize size;
res_hndl_t res_hndl = release-rsrc_handle;
int rc = 0;
@@ -647,6 +662,16 @@ int cxlflash_disk_release(struct scsi_device *sdev,
* Afterwards we clear the remaining fields.
*/
switch (lun_info-mode) {
+ case MODE_VIRTUAL:
+ marshall_rele_to_resize(release, size);
+ size.req_size = 0;
+ rc = cxlflash_vlun_resize(sdev, size);
+ if (rc) {
+ pr_err(%s: resize failed rc %d\n, __func__, rc);
+ goto out;
+ }
+
+ break;
case MODE_PHYSICAL:
/*
* Clear the Format 1 RHT entry for direct access
@@ -1768,9 +1793,12 @@ int cxlflash_ioctl(struct scsi_device *sdev, int cmd,
void __user *arg)
} ioctl_tbl[] = { /* NOTE: order matters here */
{sizeof(struct dk_cxlflash_attach), (sioctl)cxlflash_disk_attach},
{sizeof(struct dk_cxlflash_udirect), cxlflash_disk_direct_open},
+ {sizeof(struct dk_cxlflash_uvirtual), cxlflash_disk_virtual_open},
+ {sizeof(struct dk_cxlflash_resize), (sioctl)cxlflash_vlun_resize},
{sizeof(struct dk_cxlflash_release), (sioctl)cxlflash_disk_release},
{sizeof(struct dk_cxlflash_detach), (sioctl)cxlflash_disk_detach},
{sizeof(struct dk_cxlflash_verify), (sioctl)cxlflash_disk_verify},
+ {sizeof(struct dk_cxlflash_clone), (sioctl)cxlflash_disk_clone},
{sizeof(struct dk_cxlflash_recover_afu), (sioctl)cxlflash_afu_recover},
{sizeof(struct dk_cxlflash_manage_lun), (sioctl)cxlflash_manage_lun},
};
diff --git a/drivers/scsi/cxlflash/vlun.c b/drivers/scsi/cxlflash/vlun.c
new file mode 100644
index 000..94cc2ec
--- /dev/null
+++ b/drivers/scsi/cxlflash/vlun.c
@@ -0,0 +1,1096 @@
+/*
+ * CXL Flash Device Driver
+ *
+ * Written by: Manoj N. Kumar ma...@linux.vnet.ibm.com, IBM Corporation
+ * Matthew R. Ochs mro...@linux.vnet.ibm.com, IBM Corporation
+ *
+ * Copyright (C) 2015 IBM Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include linux/delay.h
+#include linux/file.h
+#include linux/moduleparam.h
+#include linux/syscalls.h
+#include misc/cxl.h
+#include asm/unaligned.h
+
+#include scsi/scsi_host.h
+#include uapi/scsi/cxlflash_ioctl.h
+
+#include sislite.h
+#include
Re: [PATCH 09/20] [SCSI] mpt3sas: MPI 2.5 Rev J (2.5.5) specification and 2.00.34 header files
Sreekanth Reddy sreekanth.re...@avagotech.com writes:
@@ -1334,9 +1336,17 @@ typedef struct _MPI2_CONFIG_PAGE_BIOS_1 {
*PTR_MPI2_CONFIG_PAGE_BIOS_1,
Mpi2BiosPage1_t, *pMpi2BiosPage1_t;
-#define MPI2_BIOSPAGE1_PAGEVERSION (0x05)
+#define MPI2_BIOSPAGE1_PAGEVERSION (0x06)
/*values for BIOS Page 1 BiosOptions field */
+#define MPI2_BIOSPAGE1_OPTIONS_X86_DISABLE_BIOS (0x0400)
Looks like you may have some bad whitespace here ^^^.
+
+#define MPI2_BIOSPAGE1_OPTIONS_MASK_REGISTRATION_UEFI_BSD(0x0300)
+#define MPI2_BIOSPAGE1_OPTIONS_USE_BIT0_REGISTRATION_UEFI_BSD
(0x)
+#define MPI2_BIOSPAGE1_OPTIONS_FULL_REGISTRATION_UEFI_BSD(0x0100)
+#define MPI2_BIOSPAGE1_OPTIONS_ADAPTER_REGISTRATION_UEFI_BSD (0x0200)
+#define MPI2_BIOSPAGE1_OPTIONS_DISABLE_REGISTRATION_UEFI_BSD (0x0300)
Otherwise OK.
Reviewed-by: Martin K. Petersen martin.peter...@oracle.com
--
Martin K. Petersen Oracle Linux Engineering
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
Re: [PATCH 16/20] [SCSI] mpt3sas: Added support for customer specific branding
Sreekanth Reddy sreekanth.re...@avagotech.com writes: Added support for below customer specific brandings VendorID DeviceID SubsystemVendor ID SubsystemDevice ID Cisco Branding String 0x1000 0x97 0x1137 0x154 Cisco 9300-8i 12Gbps SAS HBA 0x1000 0x97 0x1137 0x155 Cisco 12G Modular SAS Pass through Controller 0x1000 0x97 0x1137 0x156 UCS C3X60 12G SAS Pass through Controller Same comment about not actually changing driver behavior. These changes belong in pci.ids, not in a driver. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line unsubscribe linux-scsi in
Re: [PATCH 17/20 v1] [SCSI] mpt3sas: Use alloc_ordered_workqueue() API instead of create_singlethread_workqueue() API
Sreekanth Reddy sreekanth.re...@avagotech.com writes: Created a thread using alloc_ordered_workqueue() API in order to process the works from firmware Work-queue sequentially instead of create_singlethread_workqueue() API. Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line unsubscribe linux-scsi in
Re: [PATCH 18/20] [SCSI] mpt3sas: Call dma_mapping_error() API after mapping an address with dma_map_single() API
Sreekanth Reddy sreekanth.re...@avagotech.com writes: Added dma_mapping_error() API after mapping an address with dma_map_single() API. Otherwise when CONFIG_DMA_API_DEBUG is enabled in the kernel, then it complains about mpt3sas driver not calling dma_mapping_error after mapping an address with dma_map_single Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line unsubscribe linux-scsi in
Re: [PATCH 08/20] [SCSI] mpt3sas: Update MPI2 strings to MPI2.5
Sreekanth Reddy sreekanth.re...@avagotech.com writes: Update MPI2 strings to MPI2.5. Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line unsubscribe linux-scsi in
Re: [PATCH 13/20] [SCSI] mpt3sas: MPI 2.5 Rev K (2.5.6) specifications
Sreekanth Reddy sreekanth.re...@avagotech.com writes: Below are the new changes to MPI 2.5 Rev K(2.5.6) specification and 2.00.35 header files 1) Added a minimum size requirement for target mode command buffers. 2) Added MinMSIxIndex and MaxMSIxIndex fields to CommandBufferPostBase Request. 3) For BIOS Page 1, added SSUTimeout field, and added Product Name String Format bits to the BiosOptions field Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line unsubscribe linux-scsi in
Re: Merging se_dev_entry and se_lun?
On Fri, Jun 19, 2015 at 08:40:23AM +0200, Hannes Reinecke wrote: Having a list here implies that 'se_lun' can have _several_ se_dev_entry structure attached to it, which I found rather curious. Can you give me an example where this might be the case? Or can we replace the list with a simple pointer or even merge both? Each initiator has it's own dev entry. What might make sense with the new list-based dev entry handling is to merge the se_lun_acl and se_dev_entry, but it would be a fair amount of work. -- 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/8] tcm_loop updates
On 06/19/2015 08:48 AM, Christoph Hellwig wrote: What's the benefit of the SAS transport class writeout? I honestly always saw tcm_loop as a simple loopback driver, with the different transport IDs in the PR code as a gimmick. Note that vhost and xen-blkback copies that style and I did plan to consolidate it in common code. The benefit is that tcm_loop will show up in the system as a 'real' SAS hba; long-term goal is to simulate SAS multipathing here. I was even planning on adding simlated FC infrastructure, too; with that we could simulate FC multipathing, too, and our QA would be _so_ happy... Again, these patches are mainly a collection of patches I've done to test various scenarios, in the hope others might find them useful, too. So I can easily hold off these patches until you've posted your rework. Cheers, Hannes -- Dr. Hannes ReineckezSeries Storage 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 8/8] target: display 'write_protect' attribute for demo-mode LUNs
On Thu, Jun 18, 2015 at 11:43:42AM +0200, Hannes Reinecke wrote: When LUNs are mapped with a demo-mode initiator we're missing the 'write_protect' attribute to set a LUN read-only. I don't think it's a good idea as-is. The target core clearly differenciates between demo mode and production mode read only, and some drivers already expose attributes for these. I have a big series in progress to clean the mess around this area up. So for now please don't add anything here, it should become much simpler after my changes, and I might be able to incorporate something like this after the main series. -- 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: problem: connection teardown is always blocked because host is busy doing work on other connections
Hi Mike, I am unaware of your talk with Sony about this issue. Anyways, I will leave it for Sony to follow it through. Thanks. -Minh On Thu, Jun 18, 2015 at 11:16 PM, Mike Christie micha...@cs.wisc.edu wrote: On 6/18/15, 8:09 PM, Minh Tran wrote: From: Minh Duc Tran minhduc.t...@avagotech.com This blocking is ok if we use software iscsi or iser where each connection has a separate host. In the case of hw iscsi offload, one host could have hundreds of connections and some connections may have IOs running which makes host-host_busy is always TRUE. Another problem is the host_lock taken here is disruptive to other connections' EH paths. Wouldn't using target_busy a better choice here? Do you talk to John :) I had told him to do that a couple days ago when you guys emailed me about this offlist. However, I think Christoph wants to remove target_busy so you need to think of something else. I think you could take the session eh_mutex in the libiscsi session and conn teardown functions and rely on refcounting and state checks in the eh callouts. -- 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
Merging se_dev_entry and se_lun?
Hi Nic, having done the patch to export 'write_protect' for demo-mode LUNs I've came across one puzzling item: struct se_lun uses a list to refer to the underlying se_dev_entry structures. Which I found rather curious, as from my understanding 'se_lun' is the structure for the mapped LUN (ie the LUN visible to the initiator) and 'se_dev_entry' is the underlying physical device as visible to the LUN. As such I would have expected a 1:1 relationship between both, ie a simple pointer from se_lun to se_dev_entry. Having a list here implies that 'se_lun' can have _several_ se_dev_entry structure attached to it, which I found rather curious. Can you give me an example where this might be the case? Or can we replace the list with a simple pointer or even merge both? Reason I'm asking is the lun_access / dev_flags field; it really looks like it being a duplicate (I would judge 'write_protect' to be a property of the mapped LUN, and not of the underlying device), but in either case having it in both places requires a synchronisation between both, as for demo-mode LUNs we can only change it via se_lun, and for others we have to change it via the se_dev_entry. Cheers, Hannes -- Dr. Hannes ReineckezSeries Storage 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: hpsa static checker issues
On Thu, Jun 18, 2015 at 06:42:14PM +, Don Brace wrote: Dan, You had noted three concerns covering: mutex_unlock, decode sense data, and a goto label issue, that were detected during your static checker run. I have patches that address these issues. I am thinking that I need to post these three patches linux-scsi. Is that correct? Yes. That's right. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
problem: connection teardown is always blocked because host is busy doing work on other connections
From: Minh Duc Tran minhduc.t...@avagotech.com
This blocking is ok if we use software iscsi or iser where each
connection has a separate host. In the case of hw iscsi offload, one
host could have hundreds of connections and some connections may have
IOs running which makes host-host_busy is always TRUE. Another
problem is the host_lock taken here is disruptive to other
connections' EH paths. Wouldn't using target_busy a better choice
here?
void iscsi_conn_teardown(struct iscsi_cls_conn *cls_conn)
{
.
...
/*
* Block until all in-progress commands for this connection
* time out or fail.
*/
for (;;) {
spin_lock_irqsave(session-host-host_lock, flags);
if (!atomic_read(session-host-host_busy)) { /* OK
for ERL == 0 */
spin_unlock_irqrestore(session-host-host_lock, flags);
break;
}
spin_unlock_irqrestore(session-host-host_lock, flags);
msleep_interruptible(500);
iscsi_conn_printk(KERN_INFO, conn, iscsi conn_destroy():
host_busy %d host_failed %d\n,
atomic_read(session-host-host_busy),
session-host-host_failed);
/*
* force eh_abort() to unblock
*/
wake_up(conn-ehwait);
}
--
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 8/8] target: display 'write_protect' attribute for demo-mode LUNs
On 06/19/2015 08:51 AM, Christoph Hellwig wrote: On Thu, Jun 18, 2015 at 11:43:42AM +0200, Hannes Reinecke wrote: When LUNs are mapped with a demo-mode initiator we're missing the 'write_protect' attribute to set a LUN read-only. I don't think it's a good idea as-is. The target core clearly differenciates between demo mode and production mode read only, and some drivers already expose attributes for these. I have a big series in progress to clean the mess around this area up. So for now please don't add anything here, it should become much simpler after my changes, and I might be able to incorporate something like this after the main series. I've done this particular patch to simulate write-protected LUNs via tcm_loop. As the hooks already had been there I thought this to be the 'cleanest' approach. Of course, if you have other suggestions on how this should be achieved I'm happy to try this. Cheers, Hannes -- Dr. Hannes ReineckezSeries Storage 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 0/8] tcm_loop updates
What's the benefit of the SAS transport class writeout? I honestly always saw tcm_loop as a simple loopback driver, with the different transport IDs in the PR code as a gimmick. Note that vhost and xen-blkback copies that style and I did plan to consolidate it in common code. -- 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: problem: connection teardown is always blocked because host is busy doing work on other connections
On 6/18/15, 8:09 PM, Minh Tran wrote: From: Minh Duc Tran minhduc.t...@avagotech.com This blocking is ok if we use software iscsi or iser where each connection has a separate host. In the case of hw iscsi offload, one host could have hundreds of connections and some connections may have IOs running which makes host-host_busy is always TRUE. Another problem is the host_lock taken here is disruptive to other connections' EH paths. Wouldn't using target_busy a better choice here? Do you talk to John :) I had told him to do that a couple days ago when you guys emailed me about this offlist. However, I think Christoph wants to remove target_busy so you need to think of something else. I think you could take the session eh_mutex in the libiscsi session and conn teardown functions and rely on refcounting and state checks in the eh callouts. -- 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 7/8] target_core_alua: disallow READ_CAPACITY when in standby
On Thu, Jun 18, 2015 at 11:43:41AM +0200, Hannes Reinecke wrote: Strictly speaking SPC doesn't require READ CAPACITY and friends to be supported while in the port is in standby. But it does allow it. We should always aim to implement the best possible behavior instead of aiming for the worst. -- 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 7/8] target_core_alua: disallow READ_CAPACITY when in standby
On 06/19/2015 08:49 AM, Christoph Hellwig wrote: On Thu, Jun 18, 2015 at 11:43:41AM +0200, Hannes Reinecke wrote: Strictly speaking SPC doesn't require READ CAPACITY and friends to be supported while in the port is in standby. But it does allow it. We should always aim to implement the best possible behavior instead of aiming for the worst. Right. As mentioned in my other mail this patch was primarily to fixup READ CAPACITY issues in the linux kernel. I'll be updating the patch to make it optional. Cheers, Hannes -- Dr. Hannes ReineckezSeries Storage 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: integrate scsi_dh better into the scsi core V2
On 05/18/2015 07:36 PM, Hannes Reinecke wrote: On 05/18/2015 07:28 PM, Christoph Hellwig wrote: Any chance to get reviews for the updated patch 1 and the new patch 3 so that the whole series is in reviewed state? Working on it. There had been issues with v1 where multipath wouldn't start up properly if no hardware handlers were attached which I need to check before sending out the review. So, I've been looking into it. While the principle is okay, there are some issues with the current state (eg sdev-handler is never assigned). Do you have an updated patchset or should I send some incremental patches? Cheers, Hannes -- Dr. Hannes ReineckezSeries Storage 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
Re: [PATCH 5/6] target: Send UA upon LUN RESET tmr completion
On Thu, Jun 11, 2015 at 10:01:28AM +0200, Hannes Reinecke wrote:
SAM mandates that an BUS DEVICE RESET FUNCTION OCCURRED
UA needs to be send after a LUN RESET tmr has completed.
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/target/target_core_transport.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/target/target_core_transport.c
b/drivers/target/target_core_transport.c
index a0e0d3a..bb60c0c4 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -3064,6 +3064,17 @@ static void target_tmr_work(struct work_struct *work)
ret = core_tmr_lun_reset(dev, tmr, NULL, NULL);
tmr-response = (!ret) ? TMR_FUNCTION_COMPLETE :
TMR_FUNCTION_REJECTED;
+ if (tmr-response == TMR_FUNCTION_COMPLETE) {
+ struct se_dev_entry *deve;
+
+ rcu_read_lock();
+ deve = target_nacl_find_deve(cmd-se_sess-se_node_acl,
+ cmd-orig_fe_lun);
+ if (deve)
+ core_scsi3_ua_allocate(deve, 0x29,
+
ASCQ_29H_BUS_DEVICE_RESET_FUNCTION_OCCURRED);
+ rcu_read_unlock();
This should use the target_ua_allocate_lun helper.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
Re: Merging se_dev_entry and se_lun?
On 06/19/2015 08:56 AM, Christoph Hellwig wrote: On Fri, Jun 19, 2015 at 08:40:23AM +0200, Hannes Reinecke wrote: Having a list here implies that 'se_lun' can have _several_ se_dev_entry structure attached to it, which I found rather curious. Can you give me an example where this might be the case? Or can we replace the list with a simple pointer or even merge both? Each initiator has it's own dev entry. But isn't 'se_lun' per initiator, too? Cheers, Hannes -- Dr. Hannes ReineckezSeries Storage 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
Re: [PATCH 01/20] [SCSI] mpt3sas: Added Combined Reply Queue feature to extend up-to 96 MSIX vector support
On Fri, Jun 19, 2015 at 2:44 PM, Johannes Thumshirn jthumsh...@suse.de wrote: On Thu, Jun 18, 2015 at 03:27:26PM +0530, Sreekanth Reddy wrote: Hi, Any other review comments on this patch. please let us known if any changes are required. Thanks, Sreekanth Have you sent a follow up on this I may have missed? On Fri, Jun 12, 2015 at 4:46 PM, Sreekanth Reddy sreekanth.re...@avagotech.com wrote: Thanks Johannes, we will take care of this point in our current on-development mpt2sas/mpt3sas merging activity. diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c b/drivers/scsi/mpt3sas/mpt3sas_base.c [...] index 14a781b..c13a365 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_base.c +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c @@ -83,7 +83,7 @@ static int msix_disable = -1; module_param(msix_disable, int, 0); MODULE_PARM_DESC(msix_disable, disable msix routed interrupts (default=0)); -static int max_msix_vectors = 8; +static int max_msix_vectors = -1; module_param(max_msix_vectors, int, 0); MODULE_PARM_DESC(max_msix_vectors, max msix vectors - (default=8)); ^^^ When changing the default value, please also update the description reflecting this change. Johannes, I didn't notice this previously, I will post next version of this patch by updating the module parameter description Thanks, Sreekanth Thanks -- Johannes Thumshirn Storage jthumsh...@suse.de +49 911 74053 689 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) -- Regards, Sreekanth -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] target: Send UA on ALUA target port group change
On 06/19/2015 03:05 PM, Christoph Hellwig wrote:
--- a/drivers/target/target_core_alua.c
+++ b/drivers/target/target_core_alua.c
@@ -1880,12 +1880,19 @@ static void core_alua_put_tg_pt_gp_from_name(
static void __target_attach_tg_pt_gp(struct se_lun *lun,
struct t10_alua_tg_pt_gp *tg_pt_gp)
{
+struct se_dev_entry *se_deve;
+
assert_spin_locked(lun-lun_tg_pt_gp_lock);
spin_lock(tg_pt_gp-tg_pt_gp_lock);
lun-lun_tg_pt_gp = tg_pt_gp;
list_add_tail(lun-lun_tg_pt_gp_link, tg_pt_gp-tg_pt_gp_lun_list);
tg_pt_gp-tg_pt_gp_members++;
+spin_lock_bh(lun-lun_deve_lock);
+list_for_each_entry(se_deve, lun-lun_deve_list, lun_link)
+core_scsi3_ua_allocate(se_deve, 0x3f,
+ ASCQ_3FH_INQUIRY_DATA_HAS_CHANGED);
+spin_unlock_bh(lun-lun_deve_lock);
spin_unlock(tg_pt_gp-tg_pt_gp_lock);
Taking a _bh lock inside a regular spinlock is completely broken.
Fortunately I don't think lun_deve_lock needs to disable bottom halves,
but this needs to be fixed first.
This harks back to my previous mail:
Under which circumstances will there be more than one se_dev_entry
structures in lun_deve_list?
Isn't there a 1:1 relationship?
Cheers,
Hannes
--
Dr. Hannes ReineckezSeries Storage
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
Re: [PATCH 6/6] target: Send UA when changing LUN inventory
On 06/19/2015 03:07 PM, Christoph Hellwig wrote:
+hlist_for_each_entry_rcu(tmp, nacl-lun_entry_hlist, link) {
+if (tmp == new)
+continue;
+core_scsi3_ua_allocate(tmp, 0x3F,
+ASCQ_3FH_REPORTED_LUNS_DATA_HAS_CHANGED);
+}
+rcu_read_unlock();
+
+rcu_read_lock();
+hlist_for_each_entry_rcu(tmp, nacl-lun_entry_hlist, link) {
+if (tmp == new)
+continue;
+core_scsi3_ua_allocate(tmp, 0x3F,
+ASCQ_3FH_REPORTED_LUNS_DATA_HAS_CHANGED);
+}
+rcu_read_unlock();
+
+rcu_read_lock();
+hlist_for_each_entry_rcu(tmp, nacl-lun_entry_hlist, link)
+core_scsi3_ua_allocate(tmp, 0x3F,
+ASCQ_3FH_REPORTED_LUNS_DATA_HAS_CHANGED);
+rcu_read_unlock();
Please add a helper instead of duplicating this three times.
Okay.
Cheers,
Hannes
--
Dr. Hannes ReineckezSeries Storage
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
Re: [PATCH 4/6] target: Send UA on ALUA target port group change
On Fri, Jun 19, 2015 at 03:09:34PM +0200, Hannes Reinecke wrote: This harks back to my previous mail: Under which circumstances will there be more than one se_dev_entry structures in lun_deve_list? Isn't there a 1:1 relationship? No. See my answer to your previous mail. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in
Re: integrate scsi_dh better into the scsi core V2
On 06/19/2015 03:17 PM, Christoph Hellwig wrote: Feel free to take over the series as your ALUA changes rely on it. D'accord. Cheers, Hannes -- Dr. Hannes ReineckezSeries Storage 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
Re: Merging se_dev_entry and se_lun?
On Fri, Jun 19, 2015 at 03:21:27PM +0200, Hannes Reinecke wrote: Each initiator has it's own dev entry. But isn't 'se_lun' per initiator, too? No. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in
Re: [PATCH 4/6] target: Send UA on ALUA target port group change
--- a/drivers/target/target_core_alua.c
+++ b/drivers/target/target_core_alua.c
@@ -1880,12 +1880,19 @@ static void core_alua_put_tg_pt_gp_from_name(
static void __target_attach_tg_pt_gp(struct se_lun *lun,
struct t10_alua_tg_pt_gp *tg_pt_gp)
{
+ struct se_dev_entry *se_deve;
+
assert_spin_locked(lun-lun_tg_pt_gp_lock);
spin_lock(tg_pt_gp-tg_pt_gp_lock);
lun-lun_tg_pt_gp = tg_pt_gp;
list_add_tail(lun-lun_tg_pt_gp_link, tg_pt_gp-tg_pt_gp_lun_list);
tg_pt_gp-tg_pt_gp_members++;
+ spin_lock_bh(lun-lun_deve_lock);
+ list_for_each_entry(se_deve, lun-lun_deve_list, lun_link)
+ core_scsi3_ua_allocate(se_deve, 0x3f,
+ASCQ_3FH_INQUIRY_DATA_HAS_CHANGED);
+ spin_unlock_bh(lun-lun_deve_lock);
spin_unlock(tg_pt_gp-tg_pt_gp_lock);
Taking a _bh lock inside a regular spinlock is completely broken.
Fortunately I don't think lun_deve_lock needs to disable bottom halves,
but this needs to be fixed first.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
Re: [PATCH 5/6] target: Send UA upon LUN RESET tmr completion
On 06/19/2015 03:06 PM, Christoph Hellwig wrote:
On Thu, Jun 11, 2015 at 10:01:28AM +0200, Hannes Reinecke wrote:
SAM mandates that an BUS DEVICE RESET FUNCTION OCCURRED
UA needs to be send after a LUN RESET tmr has completed.
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/target/target_core_transport.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/target/target_core_transport.c
b/drivers/target/target_core_transport.c
index a0e0d3a..bb60c0c4 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -3064,6 +3064,17 @@ static void target_tmr_work(struct work_struct *work)
ret = core_tmr_lun_reset(dev, tmr, NULL, NULL);
tmr-response = (!ret) ? TMR_FUNCTION_COMPLETE :
TMR_FUNCTION_REJECTED;
+if (tmr-response == TMR_FUNCTION_COMPLETE) {
+struct se_dev_entry *deve;
+
+rcu_read_lock();
+deve = target_nacl_find_deve(cmd-se_sess-se_node_acl,
+ cmd-orig_fe_lun);
+if (deve)
+core_scsi3_ua_allocate(deve, 0x29,
+
ASCQ_29H_BUS_DEVICE_RESET_FUNCTION_OCCURRED);
+rcu_read_unlock();
This should use the target_ua_allocate_lun helper.
Yep, will be doing so.
Cheers,
Hannes
--
Dr. Hannes ReineckezSeries Storage
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
Re: [PATCH 6/6] target: Send UA when changing LUN inventory
+ hlist_for_each_entry_rcu(tmp, nacl-lun_entry_hlist, link) {
+ if (tmp == new)
+ continue;
+ core_scsi3_ua_allocate(tmp, 0x3F,
+ ASCQ_3FH_REPORTED_LUNS_DATA_HAS_CHANGED);
+ }
+ rcu_read_unlock();
+
+ rcu_read_lock();
+ hlist_for_each_entry_rcu(tmp, nacl-lun_entry_hlist, link) {
+ if (tmp == new)
+ continue;
+ core_scsi3_ua_allocate(tmp, 0x3F,
+ ASCQ_3FH_REPORTED_LUNS_DATA_HAS_CHANGED);
+ }
+ rcu_read_unlock();
+
+ rcu_read_lock();
+ hlist_for_each_entry_rcu(tmp, nacl-lun_entry_hlist, link)
+ core_scsi3_ua_allocate(tmp, 0x3F,
+ ASCQ_3FH_REPORTED_LUNS_DATA_HAS_CHANGED);
+ rcu_read_unlock();
Please add a helper instead of duplicating this three times.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
Re: integrate scsi_dh better into the scsi core V2
Feel free to take over the series as your ALUA changes rely on it. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in
Re: [PATCH 06/20] [SCSI] mpt3sas: Provides the physical location of sas drives
On Fri, Jun 19, 2015 at 2:49 PM, Johannes Thumshirn jthumsh...@suse.de wrote:
On Fri, Jun 12, 2015 at 03:12:18PM +0530, Sreekanth Reddy wrote:
This Patch will provide more details of the devices such as slot number,
enclosure logical id, enclosure level connector name in the following
scenarios,
- When end device is added in the topology,
- When the end device is removed from the setup,
- When the SCSI mid layer issues TASK ABORT/ DEVICE RESET/ TARGET RESET
during error handling,
- When any command to the device fails with Sense key Hardware error or
Medium error or Unit Attention,
- When firmware returns device error or device not ready status for the end
device,
- When a Predicted fault is detected on an end device.
This information can be used by the user to identify the location of the
desired drive in the topology.
Driver will get these information by reading the sas device page0.
Signed-off-by: Sreekanth Reddy sreekanth.re...@avagotech.com
---
drivers/scsi/mpt3sas/mpt3sas_base.h | 2 +
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 238
+--
2 files changed, 201 insertions(+), 39 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index b79ad4f..293ad23 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -317,6 +317,8 @@ struct _sas_device {
u8 fast_path;
u8 pfa_led_on;
u8 pend_sas_rphy_add;
+ u8 enclosure_level;
+ u8 connector_name[4];
Minor nit of different indent here, don't know if it is worth re-sending?
Not an Issue. I will post the next version of this patch by adjusting
this indent.
Thanks,
Sreekanth
Other than that:
Reviewed-by: Johannes Thumshirn jthumsh...@suse.de
--
Johannes Thumshirn Storage
jthumsh...@suse.de +49 911 74053 689
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)
--
Regards,
Sreekanth
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
[PATCH resend] mpt2sas: setpci reset kernel panic fix
Issue Descrition:
Lack of syncrhonization between ioctl, BRM status access, PCI resource
handling results in kernel oops
please refer bugzilla ID: 95101
Patch Descrition:
To provide syncrhonization locks were introduced
1. pci_access_mutex: mutex to sycnronize ioctl, sysfs show path and pci
resource handling
2. gioc_lock : global spin lock over mulitple warp drive controllers to protect
list operations on ioc(controller) list
From ba692140278e6e2b660896c32206b26dac98d215 Mon Sep 17 00:00:00 2001
From: Nagarajkumar Narayanan nagarajkumar.naraya...@seagate.com
Date: Thu, 19 Mar 2015 12:02:07 +0530
Subject: [PATCH] mpt2sas setpci kernel oops fix
Signed-off-by: Nagarajkumar Narayanan nagarajkumar.naraya...@seagate.com
---
drivers/scsi/mpt2sas/mpt2sas_base.c | 10 +++
drivers/scsi/mpt2sas/mpt2sas_base.h | 20 +-
drivers/scsi/mpt2sas/mpt2sas_ctl.c | 48 +
drivers/scsi/mpt2sas/mpt2sas_scsih.c | 32 ++-
4 files changed, 102 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c
b/drivers/scsi/mpt2sas/mpt2sas_base.c
index 11248de..d2a498c 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -108,13 +108,18 @@ _scsih_set_fwfault_debug(const char *val, struct
kernel_param *kp)
{
int ret = param_set_int(val, kp);
struct MPT2SAS_ADAPTER *ioc;
+ unsigned long flags;
if (ret)
return ret;
+ /* global ioc spinlock to protect controller list on list operations */
+ mpt2sas_initialize_gioc_lock();
printk(KERN_INFO setting fwfault_debug(%d)\n, mpt2sas_fwfault_debug);
+ spin_lock_irqsave(gioc_lock, flags);
list_for_each_entry(ioc, mpt2sas_ioc_list, list)
ioc-fwfault_debug = mpt2sas_fwfault_debug;
+ spin_unlock_irqrestore(gioc_lock, flags);
return 0;
}
@@ -4436,6 +4441,9 @@ mpt2sas_base_free_resources(struct MPT2SAS_ADAPTER *ioc)
__func__));
if (ioc-chip_phys ioc-chip) {
+ /* synchronizing freeing resource with pci_access_mutex lock */
+ if (ioc-is_warpdrive)
+ mutex_lock(ioc-pci_access_mutex);
_base_mask_interrupts(ioc);
ioc-shost_recovery = 1;
_base_make_ioc_ready(ioc, CAN_SLEEP, SOFT_RESET);
@@ -4454,6 +4462,8 @@ mpt2sas_base_free_resources(struct MPT2SAS_ADAPTER *ioc)
pci_disable_pcie_error_reporting(pdev);
pci_disable_device(pdev);
}
+ if (ioc-is_warpdrive)
+ mutex_unlock(ioc-pci_access_mutex);
return;
}
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.h
b/drivers/scsi/mpt2sas/mpt2sas_base.h
index caff8d1..a0d26f0 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.h
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.h
@@ -799,6 +799,12 @@ typedef void (*MPT2SAS_FLUSH_RUNNING_CMDS)(struct
MPT2SAS_ADAPTER *ioc);
* @delayed_tr_list: target reset link list
* @delayed_tr_volume_list: volume target reset link list
* @@temp_sensors_count: flag to carry the number of temperature sensors
+ * @pci_access_mutex: Mutex to synchronize ioctl,sysfs show path and
+ * pci resource handling. PCI resource freeing will lead to free
+ * vital hardware/memory resource, which might be in use by cli/sysfs
+ * path functions resulting in Null pointer reference followed by kernel
+ * crash. To avoid the above race condition we use mutex syncrhonization
+ * which ensures the syncrhonization between cli/sysfs_show path
*/
struct MPT2SAS_ADAPTER {
struct list_head list;
@@ -1015,6 +1021,7 @@ struct MPT2SAS_ADAPTER {
u8 mfg_pg10_hide_flag;
u8 hide_drives;
+ struct mutex pci_access_mutex;
};
typedef u8 (*MPT_CALLBACK)(struct MPT2SAS_ADAPTER *ioc, u16 smid, u8
msix_index,
@@ -1023,6 +1030,17 @@ typedef u8 (*MPT_CALLBACK)(struct MPT2SAS_ADAPTER *ioc,
u16 smid, u8 msix_index,
/* base shared API */
extern struct list_head mpt2sas_ioc_list;
+/* spinlock on list operations over IOCs
++ * Case: when multiple warpdrive cards(IOCs) are in use
++ * Each IOC will added to the ioc list stucture on initialization.
++ * Watchdog threads run at regular intervals to check IOC for any
++ * fault conditions which will trigger the dead_ioc thread to
++ * deallocate pci resource, resulting deleting the IOC netry from list,
++ * this deletion need to protected by spinlock to enusre that
++ * ioc removal is syncrhonized, if not synchronized it might lead to
++ * list_del corruption as the ioc list is traversed in cli path
++ */
+extern spinlock_t gioc_lock;
void mpt2sas_base_start_watchdog(struct MPT2SAS_ADAPTER *ioc);
void mpt2sas_base_stop_watchdog(struct MPT2SAS_ADAPTER *ioc);
@@ -1099,7 +1117,7 @@ struct _sas_device
*mpt2sas_scsih_sas_device_find_by_sas_address(
struct MPT2SAS_ADAPTER *ioc, u64 sas_address);
void
[PATCH v1 01/20] [SCSI] mpt3sas: Added Combined Reply Queue feature to extend up-to 96 MSIX vector support
In this patch, increased the number of MSIX vector support for SAS3 C0 HBAs to
up-to 96.
Following are changes that are done in this patch
1. Support this feature only for SAS3 C0 cards and also only when reply post
free queue count is greater than 8.
2. Instead of using single ReplyPostHostIndex system interface, here 12
ReplyPostHostIndex system interfaces are used. reply post free queues numbered
from 0 to 7 use the first ReplyPostHostIndex system interface to update its
corresponding ReplyPostHostIndex values, reply post free queues numbered from 8
to 15 will use the second ReplyPostHostIndex system interface and so on. These
12 ReplyPostHostIndex system interfaces address are saved in the array
replyPostRegisterIndex[].
3. Update the ReplyPostHostIndex value of corresponding reply post free queue
in the (its msix_index/8)th entry of replyPostRegisterIndex[] array after
processing the reply post descriptor.
Changes in v1:
Updated the description of module parameter max_msix_vectors
Signed-off-by: Sreekanth Reddy sreekanth.re...@avagotech.com
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 72 -
drivers/scsi/mpt3sas/mpt3sas_base.h | 7 +++-
2 files changed, 70 insertions(+), 9 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 14a781b..7d0ec5c 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -83,10 +83,10 @@ static int msix_disable = -1;
module_param(msix_disable, int, 0);
MODULE_PARM_DESC(msix_disable, disable msix routed interrupts (default=0));
-static int max_msix_vectors = 8;
+static int max_msix_vectors = -1;
module_param(max_msix_vectors, int, 0);
MODULE_PARM_DESC(max_msix_vectors,
-max msix vectors - (default=8));
+max msix vectors);
static int mpt3sas_fwfault_debug;
MODULE_PARM_DESC(mpt3sas_fwfault_debug,
@@ -1009,8 +1009,15 @@ _base_interrupt(int irq, void *bus_id)
}
wmb();
- writel(reply_q-reply_post_host_index | (msix_index
- MPI2_RPHI_MSIX_INDEX_SHIFT), ioc-chip-ReplyPostHostIndex);
+ if (ioc-msix96_vector) {
+ writel(reply_q-reply_post_host_index | ((msix_index 7)
+ MPI2_RPHI_MSIX_INDEX_SHIFT),
+ ioc-replyPostRegisterIndex[msix_index/8]);
+ } else {
+ writel(reply_q-reply_post_host_index | (msix_index
+ MPI2_RPHI_MSIX_INDEX_SHIFT),
+ ioc-chip-ReplyPostHostIndex);
+ }
atomic_dec(reply_q-busy);
return IRQ_HANDLED;
}
@@ -1560,8 +1567,6 @@ _base_check_enable_msix(struct MPT3SAS_ADAPTER *ioc)
pci_read_config_word(ioc-pdev, base + 2, message_control);
ioc-msix_vector_count = (message_control 0x3FF) + 1;
- if (ioc-msix_vector_count 8)
- ioc-msix_vector_count = 8;
dinitprintk(ioc, pr_info(MPT3SAS_FMT
msix is supported, vector_count(%d)\n,
ioc-name, ioc-msix_vector_count));
@@ -1880,6 +1885,31 @@ mpt3sas_base_map_resources(struct MPT3SAS_ADAPTER *ioc)
if (r)
goto out_fail;
+ /* Use the Combined reply queue feature only for SAS3 C0 HBAs and
+* also only when reply queue count is greater than 8
+*/
+ if (ioc-msix96_vector ioc-reply_queue_count 8) {
+ /* If this is an 96 vector supported device,
+ set up ReplyPostIndex addresses */
+ ioc-replyPostRegisterIndex = kcalloc(12,
+ sizeof(resource_size_t *), GFP_KERNEL);
+ if (!ioc-replyPostRegisterIndex) {
+ dfailprintk(ioc, printk(MPT3SAS_FMT
+ allocation for reply Post Register Index failed!!!\n,
+ ioc-name));
+ r = -ENOMEM;
+ goto out_fail;
+ }
+
+ for (i = 0; i 12; i++) {
+ ioc-replyPostRegisterIndex[i] = (resource_size_t *)
+ ((u8 *)ioc-chip-Doorbell +
+ MPI25_SUP_REPLY_POST_HOST_INDEX_OFFSET +
+ (i * 0x10));
+ }
+ } else
+ ioc-msix96_vector = 0;
+
list_for_each_entry(reply_q, ioc-reply_queue_list, list)
pr_info(MPT3SAS_FMT %s: IRQ %d\n,
reply_q-name, ((ioc-msix_enable) ? PCI-MSI-X enabled :
@@ -1901,6 +1931,8 @@ mpt3sas_base_map_resources(struct MPT3SAS_ADAPTER *ioc)
pci_release_selected_regions(ioc-pdev, ioc-bars);
pci_disable_pcie_error_reporting(pdev);
pci_disable_device(pdev);
+ if (ioc-msix96_vector)
+ kfree(ioc-replyPostRegisterIndex);
return r;
}
@@ -4522,8 +4554,16 @@ _base_make_ioc_operational(struct MPT3SAS_ADAPTER *ioc,
int
Re: [PATCH resend] mpt2sas: setpci reset kernel panic fix
@@ -79,7 +79,8 @@ static int _scsih_scan_finished(struct Scsi_Host *shost,
unsigned long time);
/* global parameters */
LIST_HEAD(mpt2sas_ioc_list);
-
+/* global ioc lock for list operations */
+spinlock_t gioc_lock;
/* local parameters */
static u8 scsi_io_cb_idx = -1;
static u8 tm_cb_idx = -1;
@@ -279,6 +280,20 @@ static struct pci_device_id scsih_pci_table[] = {
MODULE_DEVICE_TABLE(pci, scsih_pci_table);
/**
+ * mpt2sas_initialize_gioc_lock - initialize the gobal ioc lock
+ */
+void
+mpt2sas_initialize_gioc_lock(void)
+{
+ static int gioc_lock_initialize;
+
+ if (!gioc_lock_initialize) {
+ spin_lock_init(gioc_lock);
+ gioc_lock_initialize = 1;
+ }
+}
Just use DEFINE_SPINLOCK() to initialize the lock at compile time.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
Re: [PATCH resend] mpt2sas: setpci reset kernel panic fix
Hi Nagarajkumar,
On Fri, Jun 19, 2015 at 04:46:44PM +0530, Nagarajkumar Narayanan wrote:
Issue Descrition:
Lack of syncrhonization between ioctl, BRM status access, PCI resource
handling results in kernel oops
please refer bugzilla ID: 95101
Patch Descrition:
To provide syncrhonization locks were introduced
1. pci_access_mutex: mutex to sycnronize ioctl, sysfs show path and pci
resource handling
2. gioc_lock : global spin lock over mulitple warp drive controllers to
protect list operations on ioc(controller) list
This part ^^
From ba692140278e6e2b660896c32206b26dac98d215 Mon Sep 17 00:00:00 2001
From: Nagarajkumar Narayanan nagarajkumar.naraya...@seagate.com
Date: Thu, 19 Mar 2015 12:02:07 +0530
Subject: [PATCH] mpt2sas setpci kernel oops fix
Belongs in here.
Signed-off-by: Nagarajkumar Narayanan nagarajkumar.naraya...@seagate.com
---
drivers/scsi/mpt2sas/mpt2sas_base.c | 10 +++
drivers/scsi/mpt2sas/mpt2sas_base.h | 20 +-
drivers/scsi/mpt2sas/mpt2sas_ctl.c | 48 +
drivers/scsi/mpt2sas/mpt2sas_scsih.c | 32 ++-
4 files changed, 102 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c
b/drivers/scsi/mpt2sas/mpt2sas_base.c
index 11248de..d2a498c 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -108,13 +108,18 @@ _scsih_set_fwfault_debug(const char *val, struct
kernel_param *kp)
{
int ret = param_set_int(val, kp);
struct MPT2SAS_ADAPTER *ioc;
+ unsigned long flags;
if (ret)
return ret;
+ /* global ioc spinlock to protect controller list on list operations */
+ mpt2sas_initialize_gioc_lock();
printk(KERN_INFO setting fwfault_debug(%d)\n, mpt2sas_fwfault_debug);
+ spin_lock_irqsave(gioc_lock, flags);
list_for_each_entry(ioc, mpt2sas_ioc_list, list)
ioc-fwfault_debug = mpt2sas_fwfault_debug;
+ spin_unlock_irqrestore(gioc_lock, flags);
return 0;
}
@@ -4436,6 +4441,9 @@ mpt2sas_base_free_resources(struct MPT2SAS_ADAPTER *ioc)
__func__));
if (ioc-chip_phys ioc-chip) {
+ /* synchronizing freeing resource with pci_access_mutex lock */
+ if (ioc-is_warpdrive)
+ mutex_lock(ioc-pci_access_mutex);
_base_mask_interrupts(ioc);
ioc-shost_recovery = 1;
_base_make_ioc_ready(ioc, CAN_SLEEP, SOFT_RESET);
@@ -4454,6 +4462,8 @@ mpt2sas_base_free_resources(struct MPT2SAS_ADAPTER *ioc)
pci_disable_pcie_error_reporting(pdev);
pci_disable_device(pdev);
}
+ if (ioc-is_warpdrive)
+ mutex_unlock(ioc-pci_access_mutex);
return;
}
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.h
b/drivers/scsi/mpt2sas/mpt2sas_base.h
index caff8d1..a0d26f0 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.h
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.h
@@ -799,6 +799,12 @@ typedef void (*MPT2SAS_FLUSH_RUNNING_CMDS)(struct
MPT2SAS_ADAPTER *ioc);
* @delayed_tr_list: target reset link list
* @delayed_tr_volume_list: volume target reset link list
* @@temp_sensors_count: flag to carry the number of temperature sensors
+ * @pci_access_mutex: Mutex to synchronize ioctl,sysfs show path and
+ * pci resource handling. PCI resource freeing will lead to free
+ * vital hardware/memory resource, which might be in use by cli/sysfs
+ * path functions resulting in Null pointer reference followed by kernel
+ * crash. To avoid the above race condition we use mutex syncrhonization
+ * which ensures the syncrhonization between cli/sysfs_show path
*/
struct MPT2SAS_ADAPTER {
struct list_head list;
@@ -1015,6 +1021,7 @@ struct MPT2SAS_ADAPTER {
u8 mfg_pg10_hide_flag;
u8 hide_drives;
+ struct mutex pci_access_mutex;
};
typedef u8 (*MPT_CALLBACK)(struct MPT2SAS_ADAPTER *ioc, u16 smid, u8
msix_index,
@@ -1023,6 +1030,17 @@ typedef u8 (*MPT_CALLBACK)(struct MPT2SAS_ADAPTER
*ioc, u16 smid, u8 msix_index,
/* base shared API */
extern struct list_head mpt2sas_ioc_list;
+/* spinlock on list operations over IOCs
++ * Case: when multiple warpdrive cards(IOCs) are in use
++ * Each IOC will added to the ioc list stucture on initialization.
++ * Watchdog threads run at regular intervals to check IOC for any
++ * fault conditions which will trigger the dead_ioc thread to
++ * deallocate pci resource, resulting deleting the IOC netry from list,
++ * this deletion need to protected by spinlock to enusre that
++ * ioc removal is syncrhonized, if not synchronized it might lead to
++ * list_del corruption as the ioc list is traversed in cli path
++ */
There are some '++' instead of '+'
+extern spinlock_t gioc_lock;
void mpt2sas_base_start_watchdog(struct MPT2SAS_ADAPTER *ioc);
void
Re: [PATCH resend] mpt2sas: setpci reset kernel panic fix
On Fri, Jun 19, 2015 at 04:15:12AM -0700, Christoph Hellwig wrote:
@@ -79,7 +79,8 @@ static int _scsih_scan_finished(struct Scsi_Host *shost,
unsigned long time);
/* global parameters */
LIST_HEAD(mpt2sas_ioc_list);
-
+/* global ioc lock for list operations */
+spinlock_t gioc_lock;
/* local parameters */
static u8 scsi_io_cb_idx = -1;
static u8 tm_cb_idx = -1;
@@ -279,6 +280,20 @@ static struct pci_device_id scsih_pci_table[] = {
MODULE_DEVICE_TABLE(pci, scsih_pci_table);
/**
+ * mpt2sas_initialize_gioc_lock - initialize the gobal ioc lock
+ */
+void
+mpt2sas_initialize_gioc_lock(void)
+{
+ static int gioc_lock_initialize;
+
+ if (!gioc_lock_initialize) {
+ spin_lock_init(gioc_lock);
+ gioc_lock_initialize = 1;
+ }
+}
Just use DEFINE_SPINLOCK() to initialize the lock at compile time.
Or yes, even better.
--
Johannes Thumshirn Storage
jthumsh...@suse.de +49 911 74053 689
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
Re: [PATCH v1 01/20] [SCSI] mpt3sas: Added Combined Reply Queue feature to extend up-to 96 MSIX vector support
On Fri, Jun 19, 2015 at 04:25:46PM +0530, Sreekanth Reddy wrote:
In this patch, increased the number of MSIX vector support for SAS3 C0 HBAs
to up-to 96.
Following are changes that are done in this patch
1. Support this feature only for SAS3 C0 cards and also only when reply post
free queue count is greater than 8.
2. Instead of using single ReplyPostHostIndex system interface, here 12
ReplyPostHostIndex system interfaces are used. reply post free queues
numbered from 0 to 7 use the first ReplyPostHostIndex system interface to
update its corresponding ReplyPostHostIndex values, reply post free queues
numbered from 8 to 15 will use the second ReplyPostHostIndex system interface
and so on. These 12 ReplyPostHostIndex system interfaces address are saved in
the array replyPostRegisterIndex[].
3. Update the ReplyPostHostIndex value of corresponding reply post free queue
in the (its msix_index/8)th entry of replyPostRegisterIndex[] array after
processing the reply post descriptor.
Changes in v1:
Updated the description of module parameter max_msix_vectors
Signed-off-by: Sreekanth Reddy sreekanth.re...@avagotech.com
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 72
-
drivers/scsi/mpt3sas/mpt3sas_base.h | 7 +++-
2 files changed, 70 insertions(+), 9 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 14a781b..7d0ec5c 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -83,10 +83,10 @@ static int msix_disable = -1;
module_param(msix_disable, int, 0);
MODULE_PARM_DESC(msix_disable, disable msix routed interrupts
(default=0));
-static int max_msix_vectors = 8;
+static int max_msix_vectors = -1;
module_param(max_msix_vectors, int, 0);
MODULE_PARM_DESC(max_msix_vectors,
- max msix vectors - (default=8));
+ max msix vectors);
static int mpt3sas_fwfault_debug;
MODULE_PARM_DESC(mpt3sas_fwfault_debug,
@@ -1009,8 +1009,15 @@ _base_interrupt(int irq, void *bus_id)
}
wmb();
- writel(reply_q-reply_post_host_index | (msix_index
- MPI2_RPHI_MSIX_INDEX_SHIFT), ioc-chip-ReplyPostHostIndex);
+ if (ioc-msix96_vector) {
+ writel(reply_q-reply_post_host_index | ((msix_index 7)
+ MPI2_RPHI_MSIX_INDEX_SHIFT),
+ ioc-replyPostRegisterIndex[msix_index/8]);
+ } else {
+ writel(reply_q-reply_post_host_index | (msix_index
+ MPI2_RPHI_MSIX_INDEX_SHIFT),
+ ioc-chip-ReplyPostHostIndex);
+ }
atomic_dec(reply_q-busy);
return IRQ_HANDLED;
}
@@ -1560,8 +1567,6 @@ _base_check_enable_msix(struct MPT3SAS_ADAPTER *ioc)
pci_read_config_word(ioc-pdev, base + 2, message_control);
ioc-msix_vector_count = (message_control 0x3FF) + 1;
- if (ioc-msix_vector_count 8)
- ioc-msix_vector_count = 8;
dinitprintk(ioc, pr_info(MPT3SAS_FMT
msix is supported, vector_count(%d)\n,
ioc-name, ioc-msix_vector_count));
@@ -1880,6 +1885,31 @@ mpt3sas_base_map_resources(struct MPT3SAS_ADAPTER *ioc)
if (r)
goto out_fail;
+ /* Use the Combined reply queue feature only for SAS3 C0 HBAs and
+ * also only when reply queue count is greater than 8
+ */
+ if (ioc-msix96_vector ioc-reply_queue_count 8) {
+ /* If this is an 96 vector supported device,
+ set up ReplyPostIndex addresses */
+ ioc-replyPostRegisterIndex = kcalloc(12,
+ sizeof(resource_size_t *), GFP_KERNEL);
+ if (!ioc-replyPostRegisterIndex) {
+ dfailprintk(ioc, printk(MPT3SAS_FMT
+ allocation for reply Post Register Index failed!!!\n,
+ioc-name));
+ r = -ENOMEM;
+ goto out_fail;
+ }
+
+ for (i = 0; i 12; i++) {
+ ioc-replyPostRegisterIndex[i] = (resource_size_t *)
+ ((u8 *)ioc-chip-Doorbell +
+ MPI25_SUP_REPLY_POST_HOST_INDEX_OFFSET +
+ (i * 0x10));
+ }
+ } else
+ ioc-msix96_vector = 0;
+
list_for_each_entry(reply_q, ioc-reply_queue_list, list)
pr_info(MPT3SAS_FMT %s: IRQ %d\n,
reply_q-name, ((ioc-msix_enable) ? PCI-MSI-X enabled :
@@ -1901,6 +1931,8 @@ mpt3sas_base_map_resources(struct MPT3SAS_ADAPTER *ioc)
pci_release_selected_regions(ioc-pdev, ioc-bars);
pci_disable_pcie_error_reporting(pdev);
pci_disable_device(pdev);
+ if (ioc-msix96_vector)
+ kfree(ioc-replyPostRegisterIndex);
return r;
}
@@ -4522,8 +4554,16 @@
Re: [PATCH v1 06/20] [SCSI] mpt3sas: Provides the physical location of sas drives
On Fri, Jun 19, 2015 at 04:26:31PM +0530, Sreekanth Reddy wrote:
This Patch will provide more details of the devices such as slot number,
enclosure logical id, enclosure level connector name in the following
scenarios,
- When end device is added in the topology,
- When the end device is removed from the setup,
- When the SCSI mid layer issues TASK ABORT/ DEVICE RESET/ TARGET RESET
during error handling,
- When any command to the device fails with Sense key Hardware error or
Medium error or Unit Attention,
- When firmware returns device error or device not ready status for the end
device,
- When a Predicted fault is detected on an end device.
This information can be used by the user to identify the location of the
desired drive in the topology.
Driver will get these information by reading the sas device page0.
Signed-off-by: Sreekanth Reddy sreekanth.re...@avagotech.com
---
drivers/scsi/mpt3sas/mpt3sas_base.h | 2 +
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 238
+--
2 files changed, 201 insertions(+), 39 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index b79ad4f..fc694f1 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -317,6 +317,8 @@ struct _sas_device {
u8 fast_path;
u8 pfa_led_on;
u8 pend_sas_rphy_add;
+ u8 enclosure_level;
+ u8 connector_name[4];
};
/**
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index d457dba..64dd90b 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -585,6 +585,22 @@ _scsih_sas_device_remove(struct MPT3SAS_ADAPTER *ioc,
if (!sas_device)
return;
+ pr_info(MPT3SAS_FMT
+ removing handle(0x%04x), sas_addr(0x%016llx)\n,
+ ioc-name, sas_device-handle,
+ (unsigned long long) sas_device-sas_address);
+
+ if (sas_device-enclosure_handle != 0)
+ pr_info(MPT3SAS_FMT
+removing enclosure logical id(0x%016llx), slot(%d)\n,
+ioc-name, (unsigned long long)
+sas_device-enclosure_logical_id, sas_device-slot);
+
+ if (sas_device-connector_name[0] != '\0')
+ pr_info(MPT3SAS_FMT
+removing enclosure level(0x%04x), connector name( %s)\n,
+ioc-name, sas_device-enclosure_level,
+sas_device-connector_name);
spin_lock_irqsave(ioc-sas_device_lock, flags);
list_del(sas_device-list);
@@ -663,6 +679,18 @@ _scsih_sas_device_add(struct MPT3SAS_ADAPTER *ioc,
ioc-name, __func__, sas_device-handle,
(unsigned long long)sas_device-sas_address));
+ if (sas_device-enclosure_handle != 0)
+ dewtprintk(ioc, pr_info(MPT3SAS_FMT
+ %s: enclosure logical id(0x%016llx), slot( %d)\n,
+ ioc-name, __func__, (unsigned long long)
+ sas_device-enclosure_logical_id, sas_device-slot));
+
+ if (sas_device-connector_name[0] != '\0')
+ dewtprintk(ioc, pr_info(MPT3SAS_FMT
+ %s: enclosure level(0x%04x), connector name( %s)\n,
+ ioc-name, __func__,
+ sas_device-enclosure_level, sas_device-connector_name));
+
spin_lock_irqsave(ioc-sas_device_lock, flags);
list_add_tail(sas_device-list, ioc-sas_device_list);
spin_unlock_irqrestore(ioc-sas_device_lock, flags);
@@ -704,6 +732,18 @@ _scsih_sas_device_init_add(struct MPT3SAS_ADAPTER *ioc,
__func__, sas_device-handle,
(unsigned long long)sas_device-sas_address));
+ if (sas_device-enclosure_handle != 0)
+ dewtprintk(ioc, pr_info(MPT3SAS_FMT
+ %s: enclosure logical id(0x%016llx), slot( %d)\n,
+ ioc-name, __func__, (unsigned long long)
+ sas_device-enclosure_logical_id, sas_device-slot));
+
+ if (sas_device-connector_name[0] != '\0')
+ dewtprintk(ioc, pr_info(MPT3SAS_FMT
+ %s: enclosure level(0x%04x), connector name( %s)\n,
+ ioc-name, __func__, sas_device-enclosure_level,
+ sas_device-connector_name));
+
spin_lock_irqsave(ioc-sas_device_lock, flags);
list_add_tail(sas_device-list, ioc-sas_device_init_list);
_scsih_determine_boot_device(ioc, sas_device, 0);
@@ -1772,10 +1812,16 @@ _scsih_slave_configure(struct scsi_device *sdev)
sas_addr(0x%016llx), phy(%d), device_name(0x%016llx)\n,
ds, handle, (unsigned long long)sas_device-sas_address,
sas_device-phy, (unsigned long long)sas_device-device_name);
- sdev_printk(KERN_INFO, sdev,
- %s: enclosure_logical_id(0x%016llx), slot(%d)\n,
- ds, (unsigned long long)
-
[PATCH v1 06/20] [SCSI] mpt3sas: Provides the physical location of sas drives
This Patch will provide more details of the devices such as slot number,
enclosure logical id, enclosure level connector name in the following
scenarios,
- When end device is added in the topology,
- When the end device is removed from the setup,
- When the SCSI mid layer issues TASK ABORT/ DEVICE RESET/ TARGET RESET during
error handling,
- When any command to the device fails with Sense key Hardware error or Medium
error or Unit Attention,
- When firmware returns device error or device not ready status for the end
device,
- When a Predicted fault is detected on an end device.
This information can be used by the user to identify the location of the
desired drive in the topology.
Driver will get these information by reading the sas device page0.
Signed-off-by: Sreekanth Reddy sreekanth.re...@avagotech.com
---
drivers/scsi/mpt3sas/mpt3sas_base.h | 2 +
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 238 +--
2 files changed, 201 insertions(+), 39 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index b79ad4f..fc694f1 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -317,6 +317,8 @@ struct _sas_device {
u8 fast_path;
u8 pfa_led_on;
u8 pend_sas_rphy_add;
+ u8 enclosure_level;
+ u8 connector_name[4];
};
/**
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index d457dba..64dd90b 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -585,6 +585,22 @@ _scsih_sas_device_remove(struct MPT3SAS_ADAPTER *ioc,
if (!sas_device)
return;
+ pr_info(MPT3SAS_FMT
+ removing handle(0x%04x), sas_addr(0x%016llx)\n,
+ ioc-name, sas_device-handle,
+ (unsigned long long) sas_device-sas_address);
+
+ if (sas_device-enclosure_handle != 0)
+ pr_info(MPT3SAS_FMT
+ removing enclosure logical id(0x%016llx), slot(%d)\n,
+ ioc-name, (unsigned long long)
+ sas_device-enclosure_logical_id, sas_device-slot);
+
+ if (sas_device-connector_name[0] != '\0')
+ pr_info(MPT3SAS_FMT
+ removing enclosure level(0x%04x), connector name( %s)\n,
+ ioc-name, sas_device-enclosure_level,
+ sas_device-connector_name);
spin_lock_irqsave(ioc-sas_device_lock, flags);
list_del(sas_device-list);
@@ -663,6 +679,18 @@ _scsih_sas_device_add(struct MPT3SAS_ADAPTER *ioc,
ioc-name, __func__, sas_device-handle,
(unsigned long long)sas_device-sas_address));
+ if (sas_device-enclosure_handle != 0)
+ dewtprintk(ioc, pr_info(MPT3SAS_FMT
+ %s: enclosure logical id(0x%016llx), slot( %d)\n,
+ ioc-name, __func__, (unsigned long long)
+ sas_device-enclosure_logical_id, sas_device-slot));
+
+ if (sas_device-connector_name[0] != '\0')
+ dewtprintk(ioc, pr_info(MPT3SAS_FMT
+ %s: enclosure level(0x%04x), connector name( %s)\n,
+ ioc-name, __func__,
+ sas_device-enclosure_level, sas_device-connector_name));
+
spin_lock_irqsave(ioc-sas_device_lock, flags);
list_add_tail(sas_device-list, ioc-sas_device_list);
spin_unlock_irqrestore(ioc-sas_device_lock, flags);
@@ -704,6 +732,18 @@ _scsih_sas_device_init_add(struct MPT3SAS_ADAPTER *ioc,
__func__, sas_device-handle,
(unsigned long long)sas_device-sas_address));
+ if (sas_device-enclosure_handle != 0)
+ dewtprintk(ioc, pr_info(MPT3SAS_FMT
+ %s: enclosure logical id(0x%016llx), slot( %d)\n,
+ ioc-name, __func__, (unsigned long long)
+ sas_device-enclosure_logical_id, sas_device-slot));
+
+ if (sas_device-connector_name[0] != '\0')
+ dewtprintk(ioc, pr_info(MPT3SAS_FMT
+ %s: enclosure level(0x%04x), connector name( %s)\n,
+ ioc-name, __func__, sas_device-enclosure_level,
+ sas_device-connector_name));
+
spin_lock_irqsave(ioc-sas_device_lock, flags);
list_add_tail(sas_device-list, ioc-sas_device_init_list);
_scsih_determine_boot_device(ioc, sas_device, 0);
@@ -1772,10 +1812,16 @@ _scsih_slave_configure(struct scsi_device *sdev)
sas_addr(0x%016llx), phy(%d), device_name(0x%016llx)\n,
ds, handle, (unsigned long long)sas_device-sas_address,
sas_device-phy, (unsigned long long)sas_device-device_name);
- sdev_printk(KERN_INFO, sdev,
- %s: enclosure_logical_id(0x%016llx), slot(%d)\n,
- ds, (unsigned long long)
- sas_device-enclosure_logical_id, sas_device-slot);
+
RE: [patch] hpsa: fix an sprintf() overflow in the reset handler
With a size of 48 while it won't overflow since you're using snprintf the
string with a maximum value in %d:
echo -n cmd 2147483647 RESET FAILED, new lockup detected |wc -c
48
is 48 characters long without a null terminator on the string (and in the
unlikely event that it's somehow a the largest possible negative value it would
be 49 characters after including the minus sign without a null terminator). If
you always want a complete message no matter what the value formatted as %d
will be I believe it needs to have a length of 50. The worst that will happen
now though because you're using snprintf is you'll drop the trailing d or
ed in the message with very large positive or negative numbers.
My somewhat sketchy memory of the hpsa driver is that the nr_cmds member of the
struct ctlr_info is never more than 1040 (?) anyway. If things are working
correctly I don't think it should ever happen but I thought I should point out
that msg isn't large enough to contain the complete contents of the longest
possible character string.
-Original Message-
From: linux-scsi-ow...@vger.kernel.org
[mailto:linux-scsi-ow...@vger.kernel.org] On Behalf Of Don Brace
Sent: Thursday, June 18, 2015 11:36 PM
To: Dan Carpenter
Cc: James E.J. Bottomley; ISS StorageDev; dl Team ESD Storage Dev Support;
linux-scsi@vger.kernel.org; kernel-janit...@vger.kernel.org
Subject: RE: [patch] hpsa: fix an sprintf() overflow in the reset handler
-Original Message-
From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
Sent: Thursday, June 04, 2015 9:48 AM
To: Don Brace
Cc: James E.J. Bottomley; iss_storage...@hp.com; dl Team ESD Storage
Dev Support; linux-scsi@vger.kernel.org;
kernel-janit...@vger.kernel.org
Subject: [patch] hpsa: fix an sprintf() overflow in the reset handler
The string cmd %d RESET FAILED, new lockup detected is not quite
large enough so the sprintf() will overflow. I have increased the
size of the buffer and also changed the sprintf calls to snprintf.
Fixes: 73153fe533bc ('hpsa: use block layer tag for command
allocation')
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c index
1dafeb4..cab4e98 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -5104,7 +5104,7 @@ static int hpsa_eh_device_reset_handler(struct
scsi_cmnd *scsicmd)
int rc;
struct ctlr_info *h;
struct hpsa_scsi_dev_t *dev;
- char msg[40];
+ char msg[48];
/* find the controller to which the command to be aborted was sent */
h = sdev_to_hba(scsicmd-device);
@@ -5122,16 +5122,18 @@ static int hpsa_eh_device_reset_handler(struct
scsi_cmnd *scsicmd)
/* if controller locked up, we can guarantee command won't complete
*/
if (lockup_detected(h)) {
- sprintf(msg, cmd %d RESET FAILED, lockup detected,
- hpsa_get_cmd_index(scsicmd));
+ snprintf(msg, sizeof(msg),
+ cmd %d RESET FAILED, lockup detected,
+ hpsa_get_cmd_index(scsicmd));
hpsa_show_dev_msg(KERN_WARNING, h, dev, msg);
return FAILED;
}
/* this reset request might be the result of a lockup; check */
if (detect_controller_lockup(h)) {
- sprintf(msg, cmd %d RESET FAILED, new lockup detected,
- hpsa_get_cmd_index(scsicmd));
+ snprintf(msg, sizeof(msg),
+ cmd %d RESET FAILED, new lockup detected,
+ hpsa_get_cmd_index(scsicmd));
hpsa_show_dev_msg(KERN_WARNING, h, dev, msg);
return FAILED;
}
@@ -5145,7 +5147,8 @@ static int hpsa_eh_device_reset_handler(struct
scsi_cmnd *scsicmd)
/* send a reset to the SCSI LUN which the command was sent to */
rc = hpsa_do_reset(h, dev, dev-scsi3addr, HPSA_RESET_TYPE_LUN,
DEFAULT_REPLY_QUEUE);
- sprintf(msg, reset %s, rc == 0 ? completed successfully : failed);
+ snprintf(msg, sizeof(msg), reset %s,
+ rc == 0 ? completed successfully : failed);
hpsa_show_dev_msg(KERN_WARNING, h, dev, msg);
return rc == 0 ? SUCCESS : FAILED;
}
Signed-off-by: Don Brace don.br...@pmcs.com
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in the
body of a message to majord...@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/20] [SCSI] mpt3sas: Added Combined Reply Queue feature to extend up-to 96 MSIX vector support
On Thu, Jun 18, 2015 at 03:27:26PM +0530, Sreekanth Reddy wrote: Hi, Any other review comments on this patch. please let us known if any changes are required. Thanks, Sreekanth Have you sent a follow up on this I may have missed? On Fri, Jun 12, 2015 at 4:46 PM, Sreekanth Reddy sreekanth.re...@avagotech.com wrote: Thanks Johannes, we will take care of this point in our current on-development mpt2sas/mpt3sas merging activity. diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c b/drivers/scsi/mpt3sas/mpt3sas_base.c [...] index 14a781b..c13a365 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_base.c +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c @@ -83,7 +83,7 @@ static int msix_disable = -1; module_param(msix_disable, int, 0); MODULE_PARM_DESC(msix_disable, disable msix routed interrupts (default=0)); -static int max_msix_vectors = 8; +static int max_msix_vectors = -1; module_param(max_msix_vectors, int, 0); MODULE_PARM_DESC(max_msix_vectors, max msix vectors - (default=8)); ^^^ When changing the default value, please also update the description reflecting this change. Thanks -- Johannes Thumshirn Storage jthumsh...@suse.de +49 911 74053 689 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 06/20] [SCSI] mpt3sas: Provides the physical location of sas drives
On Fri, Jun 12, 2015 at 03:12:18PM +0530, Sreekanth Reddy wrote:
This Patch will provide more details of the devices such as slot number,
enclosure logical id, enclosure level connector name in the following
scenarios,
- When end device is added in the topology,
- When the end device is removed from the setup,
- When the SCSI mid layer issues TASK ABORT/ DEVICE RESET/ TARGET RESET
during error handling,
- When any command to the device fails with Sense key Hardware error or
Medium error or Unit Attention,
- When firmware returns device error or device not ready status for the end
device,
- When a Predicted fault is detected on an end device.
This information can be used by the user to identify the location of the
desired drive in the topology.
Driver will get these information by reading the sas device page0.
Signed-off-by: Sreekanth Reddy sreekanth.re...@avagotech.com
---
drivers/scsi/mpt3sas/mpt3sas_base.h | 2 +
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 238
+--
2 files changed, 201 insertions(+), 39 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index b79ad4f..293ad23 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -317,6 +317,8 @@ struct _sas_device {
u8 fast_path;
u8 pfa_led_on;
u8 pend_sas_rphy_add;
+ u8 enclosure_level;
+ u8 connector_name[4];
Minor nit of different indent here, don't know if it is worth re-sending?
Other than that:
Reviewed-by: Johannes Thumshirn jthumsh...@suse.de
--
Johannes Thumshirn Storage
jthumsh...@suse.de +49 911 74053 689
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 01/20] [SCSI] mpt3sas: Added Combined Reply Queue feature to extend up-to 96 MSIX vector support
On Fri, Jun 19, 2015 at 02:51:00PM +0530, Sreekanth Reddy wrote: On Fri, Jun 19, 2015 at 2:44 PM, Johannes Thumshirn jthumsh...@suse.de wrote: On Thu, Jun 18, 2015 at 03:27:26PM +0530, Sreekanth Reddy wrote: Hi, Any other review comments on this patch. please let us known if any changes are required. Thanks, Sreekanth Have you sent a follow up on this I may have missed? On Fri, Jun 12, 2015 at 4:46 PM, Sreekanth Reddy sreekanth.re...@avagotech.com wrote: Thanks Johannes, we will take care of this point in our current on-development mpt2sas/mpt3sas merging activity. diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c b/drivers/scsi/mpt3sas/mpt3sas_base.c [...] index 14a781b..c13a365 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_base.c +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c @@ -83,7 +83,7 @@ static int msix_disable = -1; module_param(msix_disable, int, 0); MODULE_PARM_DESC(msix_disable, disable msix routed interrupts (default=0)); -static int max_msix_vectors = 8; +static int max_msix_vectors = -1; module_param(max_msix_vectors, int, 0); MODULE_PARM_DESC(max_msix_vectors, max msix vectors - (default=8)); ^^^ When changing the default value, please also update the description reflecting this change. Johannes, I didn't notice this previously, I will post next version of this patch by updating the module parameter description No problem :-) Thanks, Sreekanth Thanks -- Johannes Thumshirn Storage jthumsh...@suse.de +49 911 74053 689 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) -- Regards, Sreekanth -- Johannes Thumshirn Storage jthumsh...@suse.de +49 911 74053 689 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 04/20] [SCSI] mpt3sas: Remove redundancy code while freeing the controller resources.
Sreekanth Reddy sreekanth.re...@avagotech.com writes: Removed the redundancy code while freeing the controller resources. Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line unsubscribe linux-scsi in
Re: [PATCH 05/20] [SCSI] mpt3sas: MPI 2.5 Rev I (2.5.4) specifications.
Sreekanth Reddy sreekanth.re...@avagotech.com writes: Update MPI 2.5 Release: MPI 2.5 Rev I (2.5.4) specification and 2.00.33 header files Below is the change set from the MPI specification for I Rev Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line unsubscribe linux-scsi in
Re: [PATCH v1 01/20] [SCSI] mpt3sas: Added Combined Reply Queue feature to extend up-to 96 MSIX vector support
Sreekanth == Sreekanth Reddy sreekanth.re...@avagotech.com writes:
Sreekanth,
It's fine that you outline the 96 / 12 = 8 layout in the patch
description. But that relationship is not made clear when reading the
code. Please add a comment describing why things are set up this way.
@@ -1009,8 +1009,15 @@ _base_interrupt(int irq, void *bus_id)
}
wmb();
- writel(reply_q-reply_post_host_index | (msix_index
- MPI2_RPHI_MSIX_INDEX_SHIFT), ioc-chip-ReplyPostHostIndex);
+ if (ioc-msix96_vector) {
+ writel(reply_q-reply_post_host_index | ((msix_index 7)
+ MPI2_RPHI_MSIX_INDEX_SHIFT),
+ ioc-replyPostRegisterIndex[msix_index/8]);
+ } else {
+ writel(reply_q-reply_post_host_index | (msix_index
+ MPI2_RPHI_MSIX_INDEX_SHIFT),
+ ioc-chip-ReplyPostHostIndex);
+ }
Too many brackets. Why don't you do:
index = reply_q-reply_post_host_index |
((msix_index 7) MPI_RPHI_MSIX_INDEX_SHIFT);
if (ioc-msix96_vector)
writel(index, ioc-replyPostRegisterIndex[msix_index / 8]);
else
writel(index, ioc-chip-ReplyPostHostIndex);
+ if (ioc-msix96_vector ioc-reply_queue_count 8) {
+ /* If this is an 96 vector supported device,
+ set up ReplyPostIndex addresses */
Bad comment formatting.
+ ioc-replyPostRegisterIndex = kcalloc(12,
+ sizeof(resource_size_t *), GFP_KERNEL);
[...]
+ for (i = 0; i 12; i++) {
Make 12 a constant or at the very least a variable with a comment.
+ ioc-replyPostRegisterIndex[i] = (resource_size_t *)
+ ((u8 *)ioc-chip-Doorbell +
+ MPI25_SUP_REPLY_POST_HOST_INDEX_OFFSET +
+ (i * 0x10));
0x10 - Another magic constant.
@@ -4522,8 +4554,16 @@ _base_make_ioc_operational(struct MPT3SAS_ADAPTER
*ioc, int sleep_flag)
/* initialize reply post host index */
list_for_each_entry(reply_q, ioc-reply_queue_list, list) {
- writel(reply_q-msix_index MPI2_RPHI_MSIX_INDEX_SHIFT,
- ioc-chip-ReplyPostHostIndex);
+ if (ioc-msix96_vector) {
+ writel((reply_q-msix_index 7)
+MPI2_RPHI_MSIX_INDEX_SHIFT,
+ioc-replyPostRegisterIndex[reply_q-msix_index/8]);
+ } else {
+ writel(reply_q-msix_index
+ MPI2_RPHI_MSIX_INDEX_SHIFT,
+ ioc-chip-ReplyPostHostIndex);
+ }
+
Too many brackets.
--
Martin K. Petersen Oracle Linux Engineering
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
Re: [PATCH 03/20] [SCSI] mpt3sas: Don't block the drive when drive addition under the control of SML
During hot-plugging of a disk(having a flaky link), the disk addition stops and any further disk addition or removal doesn't happen on that controller. This is because, when driver receives DELAY_NOT_RESPONDING event for a disk while it is undergoing addition at the SCSI Transport layer, the driver would block the I/O to that disk resulting in a deadlock. i.e the disk addition work couldn't be completed at the SCSI Transport Layer as it can't send any I/Os (such as Inquiry, Report LUNs etc) to the disk as I/Os are blocked to this drive. Also any subsequent device removal (TARGET_NOT_RESPONDING) or link update(RC_PHY_CHANGED) event couldn't be processed as they are in the queue to get processed after disk addition event. Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line unsubscribe linux-scsi in
Re: [PATCH v1 02/20] [SCSI] mpt3sas: Get IOC_FACTS information using handshake protocol only after HBA card gets into READY or Operational state.
== Sreekanth Reddy sreekanth.re...@avagotech.com writes: Driver initialization fails if driver tries to send IOC facts request message when the IOC is in reset or in a fault state. This patch will make sure that 1.Driver to send IOC facts request message only if HBA is in operational or ready state. 2.If IOC is in fault state, a diagnostic reset would be issued. 3.If IOC is in reset state then driver will wait for 10 seconds to exit out of reset state. If the HBA continues to be in reset state, then the HBA wouldn't be claimed by the driver. Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line unsubscribe linux-scsi in
