- 04 Jan, 2018 17 commits
-
-
Raghava Aditya Renukunta authored
Edit function that retrieves phy lun information to use common bmic function Signed-off-by:
Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Raghava Aditya Renukunta authored
safw command submission is duplicated across many functions. Move the safw submission code from bmic identify into its own function for common use Signed-off-by:
-
Raghava Aditya Renukunta authored
Ideally driver needs to wait for IO to be submitted or responded to before shutdown. Move code to wait for IO completion into shutdown path Signed-off-by:
-
Raghava Aditya Renukunta authored
Refactored the reset_host store function to make consistent across code bases Signed-off-by:
-
Raghava Aditya Renukunta authored
It is possible to restart the controller via the use of the reset_host sysfs variable. This does work for controllers that can no longer respond, since driver will attempt to send down a shutdown in this path. Check if the controller is able to receive commands before sending down a shutdown Signed-off-by:
-
Raghava Aditya Renukunta authored
Driver would hang when attempting to send reset from the ioctl interface, since it would wait to retrieve the ioctl mutex at send shutdown. Set adapter shutdown and unlock mutex before sending down reset request. Signed-off-by:
-
Raghava Aditya Renukunta authored
As part of the recovery process, the drivers removes offline devices ( done by the kernel) and then tries to add them back in the rescan code. Removing the device is like taking a sledgehammer to a nail. Set the device as running if it is marked offline. Signed-off-by:
-
Raghava Aditya Renukunta authored
Driver attempts to perform a device scan and device add after coming out of reset. At times when the kdump kernel loads and it tries to perform eh recovery, the device scan hangs since its commands are blocked because of the eh recovery. This should have shown up in normal eh recovery path (Should have been obvious) Remove the code that performs scanning.I can live without the rescanning support in the stable kernels but a hanging kdump/eh recovery needs to be fixed. Fixes: a2d0321d (scsi: aacraid: Reload offlined drives after controller reset) Cc: <stable@vger.kernel.org> Reported-by:
Douglas Miller <dougmill@linux.vnet.ibm.com> Tested-by:
Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com> Fixes: a2d0321d (scsi: aacraid: Reload offlined drives after controller reset) Signed-off-by:
-
Raghava Aditya Renukunta authored
Check if the adapter can receive abort requests, before sending aborts Signed-off-by:
-
Raghava Aditya Renukunta authored
When udev requests for a devices inquiry string, it might create multiple threads causing a race condition on the shared inquiry resource string. Created a buffer with the string for each thread. Cc: <stable@vger.kernel.org> Fixes: 3bc8070f ([SCSI] aacraid: SMC vendor identification) Signed-off-by:
-
Randy Dunlap authored
Fix kernel-doc warnings in drivers/scsi/ that are related to iscsi support interfaces. Fixes these kernel-doc warnings: (tested by adding these files to a new target.rst documentation file: WIP) ../drivers/scsi/libiscsi.c:2740: warning: No description found for parameter 'dd_size' ../drivers/scsi/libiscsi.c:2740: warning: No description found for parameter 'id' ../drivers/scsi/libiscsi.c:2961: warning: No description found for parameter 'cls_conn' ../drivers/scsi/iscsi_tcp.c:313: warning: No description found for parameter 'conn' ../drivers/scsi/iscsi_tcp.c:363: warning: No description found for parameter 'conn' ../drivers/scsi/libiscsi_tcp.c:810: warning: No description found for parameter 'tcp_conn' ../drivers/scsi/libiscsi_tcp.c:810: warning: No description found for parameter 'segment' ../drivers/scsi/libiscsi_tcp.c:887: warning: No description found for parameter 'offloaded' ../drivers/scsi/libiscsi_tcp.c:887: warning: No description found for parameter 'status' ../drivers/scsi/libiscsi_tcp.c:887: warning: Excess function parameter 'offload' description in 'iscsi_tcp_recv_skb' ../drivers/scsi/libiscsi_tcp.c:964: warning: Excess function parameter 'conn' description in 'iscsi_tcp_task_init' ../drivers/scsi/libiscsi_tcp.c:964: warning: Excess function parameter 'sc' description in 'iscsi_tcp_task_init' Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: "Nicholas A. Bellinger" <nab@linux-iscsi.org> Cc: linux-scsi@vger.kernel.org Cc: target-devel@vger.kernel.org Cc: Sagi Grimberg <sagi@grimberg.me> Cc: linux-rdma@vger.kernel.org Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Signed-off-by:
-
Chaitra P B authored
1. In IO path, setting of "ATA command pending" flag early before device removal, invalid device handle etc., checks causes any new commands to be always returned with SAM_STAT_BUSY and when the driver removes the drive the SML issues SYNC Cache command and that command is always returned with SAM_STAT_BUSY and thus making SYNC Cache command to requeued. 2. If the driver gets an ATA PT command for a SATA drive then the driver set "ATA command pending" flag in device specific data structure not to allow any further commands until the ATA PT command is completed. However, after setting the flag if the driver decides to return the command back to upper layers without actually issuing to the firmware (i.e., returns from qcmd failure return paths) then the corresponding flag is not cleared and this prevents the driver from sending any new commands to the drive. This patch fixes above two issues by setting of "ATA command pending" flag after checking for whether device deleted, invalid device handle, device busy with task management. And by setting "ATA command pending" flag to false in all of the qcmd failure return paths after setting the flag. Signed-off-by:
Chaitra P B <chaitra.basappa@broadcom.com> Signed-off-by:
Suganath Prabu S <suganath-prabu.subramani@broadcom.com> Signed-off-by:
-
Colin Ian King authored
Several statements are indented too far, fix these Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Colin Ian King authored
localport is being dereferenced to assign lport and then immediately afterwards localport is being sanity checked to see if it is null. Fix this by only dereferencing localport until after it has been null checked. Detected by CoverityScan, CID#1463038 ("Dereference before null check") Fixes: 3a8cefbfc5ee ("scsi: lpfc: Beef up stat counters for debug") Signed-off-by:Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
-
James Smart authored
The define names specified 64Bit/128Bit, not 64GBIT/128GBIT. Correct the names. Signed-off-by:
James Smart <james.smart@broadcom.com> Reviewed-by:
-
Andy Shevchenko authored
The function sas_parse_addr() could be easily substituted by hex2bin() which is in kernel library code. Cc: Christoph Hellwig <hch@lst.de> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by:
Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by:
-
Rafael David Tinoco authored
If, for any reason, userland shuts down iscsi transport interfaces before proper logouts - like when logging in to LUNs manually, without logging out on server shutdown, or when automated scripts can't umount/logout from logged LUNs - kernel will hang forever on its sd_sync_cache() logic, after issuing the SYNCHRONIZE_CACHE cmd to all still existent paths. PID: 1 TASK: ffff8801a69b8000 CPU: 1 COMMAND: "systemd-shutdow" #0 [ffff8801a69c3a30] __schedule at ffffffff8183e9ee #1 [ffff8801a69c3a80] schedule at ffffffff8183f0d5 #2 [ffff8801a69c3a98] schedule_timeout at ffffffff81842199 #3 [ffff8801a69c3b40] io_schedule_timeout at ffffffff8183e604 #4 [ffff8801a69c3b70] wait_for_completion_io_timeout at ffffffff8183fc6c #5 [ffff8801a69c3bd0] blk_execute_rq at ffffffff813cfe10 #6 [ffff8801a69c3c88] scsi_execute at ffffffff815c3fc7 #7 [ffff8801a69c3cc8] scsi_execute_req_flags at ffffffff815c60fe #8 [ffff8801a69c3d30] sd_sync_cache at ffffffff815d37d7 #9 [ffff8801a69c3da8] sd_shutdown at ffffffff815d3c3c This happens because iscsi_eh_cmd_timed_out(), the transport layer timeout helper, would tell the queue timeout function (scsi_times_out) to reset the request timer over and over, until the session state is back to logged in state. Unfortunately, during server shutdown, this might never happen again. Other option would be "not to handle" the issue in the transport layer. That would trigger the error handler logic, which would also need the session state to be logged in again. Best option, for such case, is to tell upper layers that the command was handled during the transport layer error handler helper, marking it as DID_NO_CONNECT, which will allow completion and inform about the problem. After the session was marked as ISCSI_STATE_FAILED, due to the first timeout during the server shutdown phase, all subsequent cmds will fail to be queued, allowing upper logic to fail faster. Signed-off-by:
Rafael David Tinoco <rafael.tinoco@canonical.com> Reviewed-by:
Lee Duncan <lduncan@suse.com> Signed-off-by:
-
- 21 Dec, 2017 20 commits
-
-
James Smart authored
Prior patch mixed up what argument in the macro was what, so min value was placed as the "default" argument, and the default value was placed as the "min" argument. Thus, when the default was applied, it looked like the default was smaller than the allowed min. Swap argument postions to correct. [mkp: fixed checkpatch warning] Signed-off-by:
-
Himanshu Madhani authored
This patch fixes following warnings reported by smatch: drivers/scsi/qla2xxx/qla_mid.c:586 qla25xx_delete_req_que() error: we previously assumed 'req' could be null (see line 580) drivers/scsi/qla2xxx/qla_mid.c:602 qla25xx_delete_rsp_que() error: we previously assumed 'rsp' could be null (see line 596) Fixes: 7867b98d ("scsi: qla2xxx: Fix memory leak in dual/target mode") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Himanshu Madhani <himanshu.madhani@cavium.com> Signed-off-by:
-
Jia-Ju Bai authored
The driver may sleep under a spinlock. The function call path is: qedi_cpu_offline (acquire the spinlock) qedi_fp_process_cqes qedi_mtask_completion qedi_process_tmf_resp kzalloc(GFP_KERNEL) --> may sleep To fix it, GFP_KERNEL is replaced with GFP_ATOMIC. This bug is found by my static analysis tool(DSAC) and checked by my code review. Signed-off-by:Jia-Ju Bai <baijiaju1990@gmail.com> Acked-by:
Manish Rangankar <Manish.Rangankar@cavium.com> Signed-off-by:
-
Ching Huang authored
Simplify arcmsr_request_device_map routine. Signed-off-by:
Ching Huang <ching2048@areca.com.tw> Signed-off-by:
-
Ching Huang authored
Simplify all arcmsr_hbaX_get_config routine by call a new get_adapter_config function. Signed-off-by:
-
Ching Huang authored
Simplify arcmsr_hbaE_get_config function. Signed-off-by:
-
Ching Huang authored
Waiting for iop firmware ready before issue get_config command to iop for adapter type A and D. Signed-off-by:
-
Ching Huang authored
Simplify arcmsr_hbaC_get_config function. Signed-off-by:
-
James Smart authored
Update the driver version to 11.4.0.6 Signed-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
-
James Smart authored
If log verbose in not turned on, its hard to tell when certain error paths get hit. Add stats counters and corresponding logic to debugfs/sysfs to aid understanding what paths were traversed. Signed-off-by:
-
James Smart authored
When unregistering a remote port the lpfc driver would eventually wait for the remoteport_unreg done callback. But the driver never completed the io aborts that would allow the connections to terminate thus the unreg done callback was never issued. Turns out the coding style of the driver allowed for the wait to occur on the same cpu that the deferred isr is called on. The blocking for the wait, blocked the isr, and as the isr didn't run, the io aborts wouldn't finish. Turns out there was never a good reason to block waiting for the unreg done in the first place. The driver can continue execution and the ref counting within the driver will do the right thing. Resolve by removing the wait and patching up a few cases where the ref counting didn't look right - mainly cases where the remote port comes back before the aborts had completed and the unreg done had been called. Additionally, a few places which used pointer values to guide driver actions weren't protected by lock, so correct those. Signed-off-by:
-
James Smart authored
In the lpfc discovery engine, when as a nvme target, where the driver was performing mailbox io with the adapter for port login when a NVME PRLI is received from the host. Rather than queue and eventually get back to sending a response after the mailbox traffic, the driver rejected the io with an error response. Turns out this particular initiator didn't like the rejection values (unable to process command/command in progress) so it never attempted a retry of the PRLI. Thus the host never established nvme connectivity with the lpfc target. By changing the rejection values (to Logical Busy/nothing more), the initiator accepted the response and would retry the PRLI, resulting in nvme connectivity. Signed-off-by:
-
James Smart authored
When enabled for both SCSI and NVME support, and connected pt2pt to a SCSI only target, the driver nodelist entry for the remote port is left in PRLI_ISSUE state and no SCSI LUNs are discovered. Works fine if only configured for SCSI support. Error was due to some of the prli points still reflecting the need to send only 1 PRLI. On a lot of fabric configs, targets were NVME only, which meant the fabric-reported protocol attributes were only telling the driver one protocol or the other. Thus things worked fine. With pt2pt, the driver must send a PRLI for both protocols as there are no hints on what the target supports. Thus pt2pt targets were hitting the multiple PRLI issues. Complete the dual PRLI support. Track explicitly whether scsi (fcp) or nvme prli's have been sent. Accurately track protocol support detected on each node as reported by the fabric or probed by PRLI traffic. Signed-off-by:
-
James Smart authored
Increased the sizes of the SCSI WQ's and CQ's so that SCSI operation is similar to that used by NVME. However, size increase restricted only to those newer adapters that can support the larger WQE size, thus bigger queue sizes. Signed-off-by:
-
James Smart authored
Handling a rcv'ed PRLI incorrectly can cause the ndlp to end up in the wrong state or the driver to ACC and PRLI when it should send LS_RJT. The cause was due to the driver not properly looking at the PRLI type and taking the multiple protocol support into consideration. Resolved by adding checks in the various PRLI receive points to validate PRLI type and reject if not valid for the enabled protocols and mode (host vs target). Signed-off-by:
-
James Smart authored
The driver is all set to handle the defer_rcv api for the nvmet_fc transport, yet didn't properly recognize the return status when the defer_rcv occurred. The driver treated it simply as an error and aborted the io. Several residual issues occurred at that point. Finish the defer_rcv support: recognize the return status when the io request is being handled in a deferred style. This stops the rogue aborts; Replenish the async cmd rcv buffer in the deferred receive if needed. Signed-off-by:
-
James Smart authored
NVME targets appear to randomly disconnect from the initiator when running heavy IO. The error is due to the host aggregate (across all controllers) io load was beyond the maximum exchange count for nvme on the adapter. The driver was properly returning a resource busy status, but the io load was so great heartbeat commands would be bounced and not have a successful retry within the fuzz amount for the nvme heartbeat (yes, a very high io load!). Thus the target was terminating the controller due to a keep alive failure. Resolve by reserving a few exchanges (by counters) which can be used when the adapter is out of normal exchanges and the command is a NVME heartbeat command. As counters are used, while the reserved command is outstanding, as soon as any other exchange completes, the counters are adjusted and the reserved count is replenished. The heartbeat completes execution in a normal fashion. Signed-off-by:
-
Xiang Chen authored
For v3 hw SAS, it supports configuring power state from D0 to D3 for entering Low Power status and power state from D3 to D0 for quit Low Power status. When power state from D0 to D3, HW will send FLR to clear the registers of ECAM and BAR space, and when power state from D3 to D0, it will clear the registers of ECAM space only. So when suspend, need to do like controller reset (including disable interrupts/DQ/PHY/BUS), and also release slots after FLR. When resume, re-config the registers of BAR space. Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
Xiang Chen authored
In function sas_suspend_devices(), it requires callback lldd_port_deformed callback to be implemented if lldd_port_deformed is implemented. So add a stub for lldd_port_deformed. Callback lldd_port_deformed was not required as the port deformation is done elsewhere in the LLDD. Signed-off-by:
-
Xiang Chen authored
This patch fix SAS_QUEUE_FULL problem. The test situation is close port while running IO. In sas_eh_handle_sas_errors(), SCSI EH will free sas_task of the device if lldd_I_T_nexus_reset() return TMF_RESP_FUNC_COMPLETE or -ENODEV. But in our SAS driver, we only free slots of the device when the return value is TMF_RESP_FUNC_COMPLETE. So if the return value is -ENODEV, the slot resource will not free any more. As an solution, we should also free slots of the device in lldd_I_T_nexus_reset() if the return value is -ENODEV. Signed-off-by:
Xiaofei Tan <tanxiaofei@huawei.com> Signed-off-by:
-
- 15 Dec, 2017 3 commits
-
-
Xiaofei Tan authored
We should do internal abort dev before TMF_ABORT_TASK_SET and TMF_LU_RESET. Because we may only have done internal abort for single IO in the earlier part of SCSI EH process. Even the internal abort to the single IO, we also don't know whether it is successful. Besides, we should release slots of the device in hisi_sas_abort_task_set() if the abort is successful. Signed-off-by:
-
Xiaofei Tan authored
Normally, hardware should ensure that internal abort timeout will never happen. If happen, it would be an SoC failure. What's more, HW will not process any other commands if an internal abort hasn't return CQ, and they will time out also. So, we should judge the result of internal abort in SCSI EH, if it is failed, we should give up to do TMF/softreset and return failure to the upper layer directly. This patch do following things to achieve this: 1. When internal abort timeout happened, we set return value to -EIO in hisi_sas_internal_task_abort(). 2. If prep_abort() is not support, let hisi_sas_internal_task_abort() return TMF_RESP_FUNC_FAILED. 3. If hisi_sas_internal_task_abort() return an negative number, it can be thought that it not executed properly or internal abort timeout. Then we won't do behind TMF or softreset, and return failure directly. Signed-off-by:
-
Xiaofei Tan authored
We should do link reset of PHY when identify timeout or STP link timeout. They are internal events of SOC and are notified to driver through interrupts of CHL_INT2. Besides, we should add an delay work to do link reset as it needs sleep. So, this patch add an new PHY event HISI_PHYE_LINK_RESET for this. Notes: v2 HW doesn't report the event of STP link timeout. So, we only need to handle event of identify timeout for v2 HW. Signed-off-by:
-
