- 20 Jun, 2019 13 commits
-
-
Finn Thain authored
Some targets introduce delays when handshaking the response to certain commands. For example, a disk may send a 96-byte response to an INQUIRY command (or a 24-byte response to a MODE SENSE command) too slowly. Apparently the first 12 or 14 bytes are handshaked okay but then the system bus error timeout is reached while transferring the next word. Since the scsi bus phase hasn't changed, the driver then sets the target borken flag to prevent further PDMA transfers. The driver also logs the warning, "switching to slow handshake". Raise the PDMA threshold to 512 bytes so that PIO transfers will be used for these commands. This default is sufficiently low that PDMA will still be used for READ and WRITE commands. The existing threshold (16 bytes) was chosen more or less at random. However, best performance requires the threshold to be as low as possible. Those systems that don't need the PIO workaround at all may benefit from mac_scsi.setup_use_pdma=1 Cc: Michael Schmitz <schmitzmic@gmail.com> Cc: stable@vger.kernel.org # v4.14+ Fixes: 3a0f64bf ("mac_scsi: Fix pseudo DMA implementation") Signed-off-by:
Finn Thain <fthain@telegraphics.com.au> Tested-by:
Stan Johnson <userm57@yahoo.com> Tested-by:
Michael Schmitz <schmitzmic@gmail.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Finn Thain authored
A PDMA error is handled in the core driver by setting the device's 'borken' flag and aborting the command. Unfortunately, do_abort() is not dependable. Perform a SCSI bus reset instead, to make sure that the command fails and gets retried. Cc: Michael Schmitz <schmitzmic@gmail.com> Cc: stable@vger.kernel.org # v4.20+ Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Finn Thain authored
The reselection interrupt gets disabled during selection and must be re-enabled when hostdata->connected becomes NULL. If it isn't re-enabled a disconnected command may time-out or the target may wedge the bus while trying to reselect the host. This can happen after a command is aborted. Fix this by enabling the reselection interrupt in NCR5380_main() after calls to NCR5380_select() and NCR5380_information_transfer() return. Cc: Michael Schmitz <schmitzmic@gmail.com> Cc: stable@vger.kernel.org # v4.9+ Fixes: 8b00c3d5 ("ncr5380: Implement new eh_abort_handler") Signed-off-by:
-
Finn Thain authored
This reverts commit 4822827a. The purpose of that commit was to suppress a timeout warning message which appeared to be caused by target latency. But suppressing the warning is undesirable as the warning may indicate a messed up transfer count. Another problem with that commit is that 15 ms is too long to keep interrupts disabled as interrupt latency can cause system clock drift and other problems. Cc: Michael Schmitz <schmitzmic@gmail.com> Cc: stable@vger.kernel.org Fixes: 4822827a ("scsi: ncr5380: Increase register polling limit") Signed-off-by:
-
Ondrej Zary authored
Host reset oopses because it calls wd719x_chip_init, which calls request_firmware, under a spinlock. Stop the RISC first, then flush active SCBs under a spinlock. Finally call wd719x_chip_init unlocked. Also found and fixed more bugs during tests: Affected active SCBs were not flushed during abort, bus and device reset. This caused problems in a following host reset (hang or oops). Device and bus reset failed under load because the result of the reset command is WD719X_SUE_TERM or WD719X_SUE_RESET. Don't treat these codes as error in wd719x_wait_done. wd719x_direct_cmd for RESET/ABORT commands didn't work properly, causing timeouts. Looks like it was caused by the WD719X_DISABLE_INT bit. Not setting it for RESET/ABORT commands seems to fix the probem. Also lower the log level of the corresponding "direct command completed" message to debug. Unfortunately, my documentation is missing some pages, including page 67 (SPIDER67.gif) about resets :( Reported-by:
Hariprasad Kelam <hariprasad.kelam@gmail.com> Signed-off-by:
Ondrej Zary <linux@zary.sk> Signed-off-by:
-
Bart Van Assche authored
The previous patch guarantees that srp_queuecommand() does not get invoked while reconnecting occurs. Hence remove the code from srp_queuecommand() that prevents command queueing while reconnecting. This patch avoids that the following can appear in the kernel log: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:747 in_atomic(): 1, irqs_disabled(): 0, pid: 5600, name: scsi_eh_9 1 lock held by scsi_eh_9/5600: #0: (rcu_read_lock){....}, at: [<00000000cbb798c7>] __blk_mq_run_hw_queue+0xf1/0x1e0 Preemption disabled at: [<00000000139badf2>] __blk_mq_delay_run_hw_queue+0x78/0xf0 CPU: 9 PID: 5600 Comm: scsi_eh_9 Tainted: G W 4.15.0-rc4-dbg+ #1 Hardware name: Dell Inc. PowerEdge R720/0VWT90, BIOS 2.5.4 01/22/2016 Call Trace: dump_stack+0x67/0x99 ___might_sleep+0x16a/0x250 [ib_srp] __mutex_lock+0x46/0x9d0 srp_queuecommand+0x356/0x420 [ib_srp] scsi_dispatch_cmd+0xf6/0x3f0 scsi_queue_rq+0x4a8/0x5f0 blk_mq_dispatch_rq_list+0x73/0x440 blk_mq_sched_dispatch_requests+0x109/0x1a0 __blk_mq_run_hw_queue+0x131/0x1e0 __blk_mq_delay_run_hw_queue+0x9a/0xf0 blk_mq_run_hw_queue+0xc0/0x1e0 blk_mq_start_hw_queues+0x2c/0x40 scsi_run_queue+0x18e/0x2d0 scsi_run_host_queues+0x22/0x40 scsi_error_handler+0x18d/0x5f0 kthread+0x11c/0x140 ret_from_fork+0x24/0x30 Reviewed-by:Hannes Reinecke <hare@suse.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Laurence Oberman <loberman@redhat.com> Cc: Jason Gunthorpe <jgg@mellanox.com> Cc: Leon Romanovsky <leonro@mellanox.com> Cc: Doug Ledford <dledford@redhat.com> Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
-
Bart Van Assche authored
Several SCSI transport and LLD drivers surround code that does not tolerate concurrent calls of .queuecommand() with scsi_target_block() / scsi_target_unblock(). These last two functions use blk_mq_quiesce_queue() / blk_mq_unquiesce_queue() for scsi-mq request queues to prevent concurrent .queuecommand() calls. However, that is not sufficient to prevent .queuecommand() calls from scsi_send_eh_cmnd(). Hence surround the .queuecommand() call from the SCSI error handler with code that avoids that .queuecommand() gets called in the blocked state. Note: converting the .queuecommand() call in scsi_send_eh_cmnd() into code that calls blk_get_request() + blk_execute_rq() is not an option since scsi_send_eh_cmnd() must be able to make forward progress even if all requests have been allocated. Cc: Ming Lei <ming.lei@redhat.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
-
Bart Van Assche authored
The ability to modify the SCSI device state was introduced by commit 638127e5 ("[PATCH] Fix error handler offline behaviour"; v2.6.12). That same commit introduced the following device states: { SDEV_CREATED, "created" }, { SDEV_RUNNING, "running" }, { SDEV_CANCEL, "cancel" }, { SDEV_DEL, "deleted" }, { SDEV_QUIESCE, "quiesce" }, { SDEV_OFFLINE, "offline" }, The SDEV_BLOCK state was introduced later to avoid that an FC cable pull would immediately result in an I/O error (commit 1094e682; "[PATCH] suspending I/Os to a device"; v2.6.12). That same patch introduced the ability to set the SDEV_BLOCK state from user space. I'm not sure whether that ability was introduced on purpose or accidentally. Since there is agreement that only writing "running" or "offline" into the SCSI sysfs device state attribute makes sense, restrict sysfs writes to these values. This patch makes sure that SDEV_BLOCK is only used for its original purpose, namely to allow transport drivers and LLDs to block further .queuecommand() calls while transport layer or adapter recovery is in progress. Note: a web search for "/sys/class/scsi_device" AND "device/state" revealed several storage configuration guides. The instructions I found in these guides tell users to write the value "running" or "offline" in the SCSI device state sysfs attribute and no other values. [mkp: typo] Cc: Christoph Hellwig <hch@lst.de> Cc: Ming Lei <ming.lei@redhat.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Johannes Thumshirn <jthumshirn@suse.de> Cc: James Smart <james.smart@broadcom.com> Cc: Ewan D. Milne <emilne@redhat.com> Cc: Laurence Oberman <loberman@redhat.com> Signed-off-by:
-
Varun Prakash authored
IEEE_8021QAZ_APP_SEL_STREAM is a valid selector for iSCSI connections, so add code to use IEEE_8021QAZ_APP_SEL_STREAM selector to get priority mask. Signed-off-by:
Varun Prakash <varun@chelsio.com> Signed-off-by:
-
Christophe JAILLET authored
Use 'kasprintf()' instead of: - snprintf(NULL, 0... - kmalloc(... - snprintf(... This is less verbose and saves 7 bytes (i.e. the space for '/(null)') if 'udev->dev_config' is NULL. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by:
Mike Christie <mchristi@redhat.com> Signed-off-by:
-
Branden Bonaby authored
Adding functionality to allow the SCSI queue depth to be changed by utilizing the "scsi_change_queue_depth" function. [mkp: checkpatch] Signed-off-by:
Branden Bonaby <brandonbonaby94@gmail.com> Reviewed-by:
Michael Kelley <mikelley@microsoft.com> Reviewed-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warning: drivers/scsi/mpt3sas/mpt3sas_base.c: In function _base_update_ioc_page1_inlinewith_perf_mode : drivers/scsi/mpt3sas/mpt3sas_base.c:4510:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (ioc->high_iops_queues) { ^ drivers/scsi/mpt3sas/mpt3sas_base.c:4530:2: note: here case MPT_PERF_MODE_LATENCY: ^~~~ Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Fixes: 30cb97023f38 ("scsi: mpt3sas: Introduce perf_mode module parameter") Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
John Garry authored
Many times in libsas, and in LLDDs which use libsas, the check for an expander device is re-implemented or open coded. Use dev_is_expander() instead. We rename this from sas_dev_type_is_expander() to not spill so many lines in referencing. Signed-off-by:
John Garry <john.garry@huawei.com> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Reviewed-by:
Jack Wang <jinpu.wang@cloud.ionos.com> Signed-off-by:
-
- 18 Jun, 2019 27 commits
-
-
Suganath Prabu S authored
Update driver version from 28.100.00.00 to 29.100.00.00 This is equivalent to Phase 10 OOB driver. Signed-off-by:
Suganath Prabu S <suganath-prabu.subramani@broadcom.com> Signed-off-by:
-
Suganath Prabu S authored
1. Introduce module parameter perf_mode for only Aero/Sea generation HBAs. 2. Update IOC page1 fields according to performance mode. Below are the performance modes that can be enabled with module parameter perf_mode: 0: Balanced - Few high iops reply queues will be enabled. Interrupt coalescing will be enabled only for these high iops reply descriptor queues. 1: Iops - Interrupt coalescing will be enabled on all reply queues. Coalescing timeout is set to 0x20.This is default value for Aero. 2: Latency - Interrupt coalescing will be enabled on all reply queues. Coalescing timeout is set to 0xA. This is a legacy behavior similar to Ventura & Invader HBA series. Default perf mode set by driver will be balanced mode if the following conditions are met: - CPU vendor = Intel; - Aero controller working in 16GT/s pcie speed Performance mode will be set to latency mode for all other cases. 4k Random Read IO performance numbers on 24 SAS SSD drives for above three permormance modes. Performance data is from Intel Skylake and HGST SS300 (drive model SDLL1DLR400GCCA1). IOPs: ----------------------------------------------------------------------- |perf_mode | qd = 1 | qd = 64 | note | |-------------|--------|---------|------------------------------------- |balanced | 259K | 3061k | Provides max performance numbers | | | | | both on lower QD workload & | | | | | also on higher QD workload | |-------------|--------|---------|------------------------------------- |iops | 220K | 3100k | Provides max performance numbers | | | | | only on higher QD workload. | |-------------|--------|---------|------------------------------------- |latency | 246k | 2226k | Provides good performance numbers | | | | | only on lower QD worklaod. | ----------------------------------------------------------------------- Avarage Latency: ----------------------------------------------------- |perf_mode | qd = 1 | qd = 64 | |-------------|--------------|----------------------| |balanced | 92.05 usec | 501.12 usec | |-------------|--------------|----------------------| |iops | 108.40 usec | 498.10 usec | |-------------|--------------|----------------------| |latency | 97.10 usec | 689.26 usec | ----------------------------------------------------- Signed-off-by: -
Suganath Prabu S authored
Enable interrupt coalescing only on high iops queues. In ioc config page 1, offset 0x14 (ProductSpecific field) is used to determine interrupt coalescing enabled/disabled on per reply descriptor post queue group(8) basis. If 31st bit is zero, then interrupt coalescing is enabled for all reply descriptor post queues. If 31st bit is set to one, then user can enable/disable interrupt coalescing on per reply descriptor post queue group(8) basis. So to enable interrupt coalescing only on first reply descriptor post queue group (i.e. on high iops queues), set bit 0 and 31. This configuration should reset during driver unload or shutdown to the default settings. For this, the driver takes copy of default ioc page 1 and copies back the default or unmodified ioc page1 during unload and shutdown. This means that on next driver load (e.g. if older version driver is loaded by user), current modified changes on ioc page1 won't take effect. Signed-off-by:
-
Suganath Prabu S authored
High iops queues are mapped to non-managed irqs. Set affinity of non-managed irqs to local numa node. Low latency queues are mapped to managed irqs. Driver reserves some reply queues for max iops (through pci_alloc_irq_vectors_affinity and .pre_vectors interface). The rest of queues are for low latency. Based on io workload in io submission path, driver will decide which group of reply queues (either high iops queues or low latency queues) to be used. High iops queues will be mapped to local numa node of controller and low latency queues will be mapped to cpus across numa nodes. In general, high iops and low latency queues should fit into 128 reply queues which is the max number of reply queues supported by Aero/Sea. Signed-off-by:
-
Suganath Prabu S authored
In the IO submission path _base_get_msix_index is called twice. Initially while getting the smid and subsequently while posting the request descriptor (RD). Refactor code to query msix index only while posting the request descriptor. Save determined msix index in msix_io field. Signed-off-by:
-
Suganath Prabu S authored
The driver will use round-robin method for io submission in batches within the high iops queues when the number of in-flight ios on the target device is larger than 8. Otherwise the driver will use low latency reply queues. Signed-off-by:
-
Suganath Prabu S authored
Code refactoring. In function _base_get_msix_index, add scmd as second argument. This change is made in preparation for the next patch where we introduce a new function to get the MSI-X index for high iops queues. Signed-off-by:
-
Suganath Prabu S authored
Aero controllers support balanced performance mode through the ability to configure queues with different properties. Reply queues with interrupt coalescing enabled are called "high iops reply queues" and reply queues with interrupt coalescing disabled are called "low latency reply queues". The driver configures a combination of high iops and low latency reply queues if: - HBA is an AERO controller; - MSI-X vectors supported by the HBA is 128; - Total CPU count in the system more than high iops queue count; - Driver is loaded with default max_msix_vectors module parameter; and - System booted in non-kdump mode. Signed-off-by:
-
Suganath Prabu S authored
If the Aero HBA supports Atomic Request Descriptors, it sets the Atomic Request Descriptor Capable bit in the IOCCapabilities field of the IOCFacts Reply message. Driver uses an Atomic Request Descriptor as an alternative method for posting an entry onto a request queue. The posting of an Atomic Request Descriptor is an atomic operation, providing a safe mechanism for multiple processors on the host to post requests without synchronization. This Atomic Request Descriptor format is identical to first 32 bits of Default Request Descriptor and uses only 32 bits. Signed-off-by:
-
Suganath Prabu S authored
This code refactoring introduces function pointers. Host uses Request Descriptors of different types for posting an entry onto a request queue. Based on controller type and capabilities, host can also use atomic descriptors other than normal descriptors. Using function pointer will avoid if-else statements Signed-off-by:
-
Geert Uytterhoeven authored
Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Geert Uytterhoeven authored
Signed-off-by:
-
YueHaibing authored
Remove including <linux/version.h> that don't need it. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
Sumit Saxena <sumit.saxena@broadcom.com> Signed-off-by:
-
Tomas Henzl authored
Use existing macros. No functional change. Signed-off-by:
Tomas Henzl <thenzl@redhat.com> Acked-by:
-
Tomas Henzl authored
Checkpatch emits a warning when using symbolic permissions. Use octal permissions instead. No functional change. Signed-off-by:
-
Tomas Henzl authored
Support is easier with all driver parameters visible in sysfs. Signed-off-by:
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warnings: drivers/scsi/megaraid/megaraid_sas_base.c: In function megasas_fw_crash_buffer_show: drivers/scsi/megaraid/megaraid_sas_base.c:3138:16: warning: variable buff_addr set but not used [-Wunused-but-set-variable] drivers/scsi/megaraid/megaraid_sas_base.c: In function megasas_get_pd_list: drivers/scsi/megaraid/megaraid_sas_base.c:4426:13: warning: variable ci_h set but not used [-Wunused-but-set-variable] 'buff_addr' is never used since inroduction in commit fc62b3fc ("megaraid_sas : Firmware crash dump feature support") 'ci_h' is not used since commit 9b3d028f ("scsi: megaraid_sas: Pre-allocate frequently used DMA buffers") Signed-off-by:
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/scsi/megaraid/megaraid_sas_base.c: In function megasas_create_frame_pool: drivers/scsi/megaraid/megaraid_sas_base.c:4124:6: warning: variable sge_sz set but not used [-Wunused-but-set-variable] It's not used any more since commit 200aed58 ("megaraid_sas: endianness related bug fixes and code optimization") Signed-off-by:
-
Nathan Chancellor authored
When building powerpc pseries_defconfig or powernv_defconfig: drivers/scsi/lpfc/lpfc_nvmet.c:224:1: error: unused function 'lpfc_nvmet_get_ctx_for_xri' [-Werror,-Wunused-function] drivers/scsi/lpfc/lpfc_nvmet.c:246:1: error: unused function 'lpfc_nvmet_get_ctx_for_oxid' [-Werror,-Wunused-function] These functions are only compiled when CONFIG_NVME_TARGET_FC is enabled. Use that same condition so there is no more warning. While the fixes commit did not introduce these functions, it caused these warnings. Fixes: 4064b27417a7 ("scsi: lpfc: Make some symbols static") Signed-off-by:Nathan Chancellor <natechancellor@gmail.com> Acked-by:
James Smart <james.smart@broadcom.com> Signed-off-by:
-
Jack Wang authored
Lindar's email addess is bouncing for some time, just remove it. ProfitBricks was rebranded to 1 & 1 Cloud IONOS, so update my email address too. Signed-off-by:
-
Nathan Chancellor authored
clang warns: drivers/scsi/ibmvscsi/ibmvscsi.c:2126:7: warning: variable 'rc' is used uninitialized whenever switch case is taken [-Wsometimes-uninitialized] case IBMVSCSI_HOST_ACTION_NONE: ^~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/ibmvscsi/ibmvscsi.c:2151:6: note: uninitialized use occurs here if (rc) { ^~ Initialize rc in the IBMVSCSI_HOST_ACTION_UNBLOCK case statement then shuffle IBMVSCSI_HOST_ACTION_NONE down to the default case statement and make it return early so that rc is never used uninitialized in this function. Fixes: 035a3c4046b5 ("scsi: ibmvscsi: redo driver work thread to use enum action states") Link: https://github.com/ClangBuiltLinux/linux/issues/502Suggested-by:Michael Ellerman <mpe@ellerman.id.au> Suggested-by:
Tyrel Datwyler <tyreld@linux.ibm.com> Signed-off-by:
-
YueHaibing authored
Fix sparse warnings: drivers/scsi/lpfc/lpfc_sli.c:115:1: warning: symbol 'lpfc_sli4_pcimem_bcopy' was not declared. Should it be static? drivers/scsi/lpfc/lpfc_sli.c:7854:1: warning: symbol 'lpfc_sli4_process_missed_mbox_completions' was not declared. Should it be static? drivers/scsi/lpfc/lpfc_nvmet.c:223:27: warning: symbol 'lpfc_nvmet_get_ctx_for_xri' was not declared. Should it be static? drivers/scsi/lpfc/lpfc_nvmet.c:245:27: warning: symbol 'lpfc_nvmet_get_ctx_for_oxid' was not declared. Should it be static? drivers/scsi/lpfc/lpfc_init.c:75:10: warning: symbol 'lpfc_present_cpu' was not declared. Should it be static? Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warnings: drivers/scsi/lpfc/lpfc_init.c: In function lpfc_setup_cq_lookup: drivers/scsi/lpfc/lpfc_init.c:9359:30: warning: variable qp set but not used [-Wunused-but-set-variable] It's not used since commit e70596a60f88 ("scsi: lpfc: Fix poor use of hardware queues if fewer irq vectors") Signed-off-by: -
Enzo Matsumiya authored
Remove double assignment in qla2x00_update_fcport(). Signed-off-by:
Enzo Matsumiya <ematsumiya@suse.de> Acked-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
-
Xiang Chen authored
For v3 hw, stash is enabled to promote performance, but it does little to improve performance according to current tests. What's more, it causes exceptions for some situations, so disable it. Signed-off-by:
Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by:
-
Luo Jiaxing authored
Several error codes will be generated between PHY down to up. This issue was introduced by HW design. The designers came to the conclusion that we should ignore these errors. Signed-off-by:
Jiaxing Luo <luojiaxing@huawei.com> Signed-off-by:
-
Xiang Chen authored
It reports a error as follows from some tools at two places in our code: runtime error: left shift of 4 by 29 places cannot be represented in type 'int' So change the type of the two numbers to unsigned to avoid the error. Signed-off-by:
-
