- 20 Dec, 2018 40 commits
-
-
Mahesh Rajashekhara authored
- when OFA event occurs, driver will stop traffic to RAID/HBA path. Driver waits for all the outstanding requests to complete. - Driver sends OFA event acknowledgment to firmware. - Driver will wait until the new firmware is up and running. - Driver will free up the resources. - Driver calls SIS/PQI initialization and rescans the device list. - Driver will resume the traffic to RAID/HBA path. Reviewed-by:
Murthy Bhat <murthy.bhat@microsemi.com> Signed-off-by:
Mahesh Rajashekhara <mahesh.rajashekhara@microsemi.com> Signed-off-by:
Don Brace <don.brace@microsemi.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Mahesh Rajashekhara authored
Problem: - during the driver initialization, driver will poll fw for KERNEL_UP in a 30 seconds timeout. - if the firmware is not ready after 30 seconds, driver will not be loaded. Fix: - change timeout from 30 seconds to 3 minutes. Reported-by:
Feng Li <lifeng1519@gmail.com> Reviewed-by:
Ajish Koshy <ajish.koshy@microsemi.com> Reviewed-by:
Dave Carroll <david.carroll@microsemi.com> Reviewed-by:
Kevin Barnett <kevin.barnett@microsemi.com> Signed-off-by:
-
Don Brace authored
Reviewed-by:
Gerry Morong <gerry.morong@microsemi.com> Reviewed-by:
-
Don Brace authored
Reviewed-by:
Scott Benesh <scott.benesh@microsemi.com> Reviewed-by:
Scott Teel <scott.teel@microsemi.com> Reviewed-by:
-
Kevin Barnett authored
Problem: The Linux kernel takes a logical volume offline after a LUN reset. This is generally accompanied by this message in the dmesg output: Device offlined - not ready after error recovery Root Cause: The root cause is a "quirk" in the timeout handling in the Linux SCSI layer. The Linux kernel places a 30-second timeout on most media access commands (reads and writes) that it send to device drivers. When a media access command times out, the Linux kernel goes into error recovery mode for the LUN that was the target of the command that timed out. Every command that timed out is kept on a list inside of the Linux kernel to be retried later. The kernel attempts to recover the command(s) that timed out by issuing a LUN reset followed by a TEST UNIT READY. If the LUN reset and TEST UNIT READY commands are successful, the kernel retries the command(s) that timed out. Each SCSI command issued by the kernel has a result field associated with it. This field indicates the final result of the command (success or error). When a command times out, the kernel places a value in this result field indicating that the command timed out. The "quirk" is that after the LUN reset and TEST UNIT READY commands are completed, the kernel checks each command on the timed-out command list before retrying it. If the result field is still "timed out", the kernel treats that command as not having been successfully recovered for a retry. If the number of commands that are in this state are greater than two, the kernel takes the LUN offline. Fix: When our RAIDStack receives a LUN reset, it simply waits until all outstanding commands complete. Generally, all of these outstanding commands complete successfully. Therefore, the fix in the smartpqi driver is to always set the command result field to indicate success when a request completes successfully. This normally isn’t necessary because the result field is always initialized to success when the command is submitted to the driver. So when the command completes successfully, the result field is left untouched. But in this case, the kernel changes the result field behind the driver’s back and then expects the field to be changed by the driver as the commands that timed-out complete. Reviewed-by:
-
Dave Carroll authored
- fix race condition when a unit is deleted after an RLL, and before we have gotten the LV_STATUS page of the unit. - In this case we will get a standard inquiry, rather than the desired page. This will result in a unit presented which no longer exists. - If we ask for LV_STATUS, insure we get LV_STATUS Reviewed-by: -
Dave Carroll authored
Reviewed-by:
-
Ajish Koshy authored
Reviewed-by:
-
Mahesh Rajashekhara authored
- wait on all outstanding I/O to complete before the device is removed. - check for null device pointers in IO entry/completion functions. Reviewed-by:
-
Ajish Koshy authored
Reviewed-by:
-
Sagar Biradar authored
- set pci_dev->dev to 0 only if the node is NO_NUMA_NODE. If not, do not reset the value but retain it. Reviewed-by:
Sagar Biradar <sagar.biradar@microsemi.com> Signed-off-by:
-
Dave Carroll authored
- set allow_restart option during scsi_device init. This allows the kernel to send a START/STOP Unit command to the drive if it encounters a 4/2 check condition in sense data. Reviewed-by:
-
Murthy Bhat authored
- fix a formatting issue. Reviewed-by:
-
Murthy Bhat authored
Reviewed-by:
-
Dave Carroll authored
- add sysfs device attributes, unique_id, lunid and path_info. Reviewed-by:
-
Dave Carroll authored
Clean up the common code which creates a raid path request for the controller LUNID and sends it synchronously, into a common routine; Reviewed-by:
-
Dave Carroll authored
- allow update the luns for PTRAID devices. Reviewed-by:
Justin Lindley <justin.lindley@microsemi.com> Reviewed-by:
-
Mahesh Rajashekhara authored
Reviewed-by:
-
Dave Carroll authored
During slave_alloc, for logical volumes include no_write_same into the scsi_device structure. This will insure that WRITE_SAME will not be used for LD's. Reviewed-by:
-
Mahesh Rajashekhara authored
Reviewed-by:
-
Kevin Barnett authored
Add support for new IUs and parsing of the Firmware Features section of the PQI Config Table to implement the "handshake" between the driver and firmware to communicate firmware features supported and enabled by the driver. Reviewed-by:
-
James Smart authored
Update lpfc version to 12.0.0.10 Signed-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
-
James Smart authored
This patch adds a "pci_bus_reset" option to the board_mode sysfs attribute. This option uses the pci_reset_bus() api to reset the PCIe link the adapter is on, which will reset the chip/adapter. Prior to issuing this option, all functions on the same chip must be placed in the offline state by the admin. After the reset, all of the instances may be brought online again. The primary purpose of this functionality is to support cases where firmware update required a chip reset but the admin did not want to reboot the machine in order to instantiate the firmware update. Sanity checks take place prior to the reset to ensure the adapter is the sole entity on the PCIe bus and that all functions are in the offline state. Signed-off-by:
-
James Smart authored
Current messages report generic actions (like send GID_FT), but misses reporting for what protocol type the action is taken. Revise the messages to reflect the FC4 protocol type being worked on. [mkp: typo] Signed-off-by:
-
James Smart authored
When a target's link dropped, an RSCN was received to communicate the change. The driver detected the loss of the target and issued and UNREG_RPI mailbox command. While that was being processed, another RSCN was received to communicate the port coming back. The driver deferred the PLOGI to the port until the mailbox command finishes. When the mailbox command completed it saw the pending port and called the routines to issue the PLOGI. However, it forgot to clear the UNREG_INP state flag, so the PLOGI xmt routine nooped the PLOGI request assuming it needed to wait for the mailbox command. At this point, login would never be re-attempted. Clear UNREG_INP before issuing the deferred PLOGI. Signed-off-by:
-
James Smart authored
Currently, when a trunk link goes down due to some fault, the driver snapshots the fault code. If the link then comes back up, meaning there is no fault, the driver is not clearing the fault code so the sysfs link_state entry reports old/stale data. Revise the logic so that on successful link up the fault code is cleared. Signed-off-by:
-
James Smart authored
The existing MDS loopback diagnostics support processing received frames in the slowpath work thread. It caps the number of frames it will process at 64, before waiting for another event to indicate additional frame reception. The net-net is this results in very slow frame processing during loopback tests and sometimes orphans an io, causing the loopback test to report failure by the switch. Move MDS loopback frame processing out of the slow path worker thread and into the normal RQ processing routines. Signed-off-by:
-
James Smart authored
If the adapter is taken offline, the trunk link port attributes continue to report trunk links as up even though all links are down as the adapter is offline. Clear the trunk links state as part of taking the adapter offline. Signed-off-by:
-
Colin Ian King authored
There is a break statement with an extra space that needs removed and a call to bfa_trc that is indented one level too much. Fix these. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Colin Ian King authored
There is a tab missing on a return statement, add the missing tab. Signed-off-by:
-
Varun Prakash authored
In case of ->vport_create() call scsi_add_host_with_dma() instead of scsi_add_host() to pass correct dma device. Signed-off-by:
Varun Prakash <varun@chelsio.com> Signed-off-by:
-
Christoph Hellwig authored
The old DAC960 driver was fine with merging over segment boundaries, so this new driver should be too. [mkp: typos] Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Christoph Hellwig authored
The old DAC960 driver was fine with merging over segment boundaries, so this new driver should be too. [mkp: typos] Signed-off-by:
-
Shivasharan S authored
Signed-off-by:
Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Signed-off-by:
-
Shivasharan S authored
Although MegaRAID controllers support 64-bit DMA addressing, as per hardware design, DMA address with all 64-bits set (0xFFFFFFFF-FFFFFFFF) results in a firmware fault. Driver will set 63-bit DMA mask to ensure the above address will not be used. Cc: stable@vger.kernel.org Signed-off-by:
-
Shivasharan S authored
Due to hardware errata in Aero controllers, reads to certain fusion registers could intermittently return zero. This behavior is transient in nature and subsequent reads will return valid value. For Aero controllers, any calls to readl to read from certain registers will be retried for maximum three times, if read returns zero. Signed-off-by:
-
Shivasharan S authored
Instead of the register address, pass the instance pointer to clear_intr and read_fw_status_reg functions. This is done in preparation for adding adapter type based checks in these functions in later patches of this series. Signed-off-by:
-
Shivasharan S authored
Identify all Aero controller PCI IDs with new adapter type. Signed-off-by:
-
Shivasharan S authored
In preparation for the new Aero series adapter type, all the places where we check adapter type for Ventura series needs to include any later adapter types. Signed-off-by:
-
Stephan Günther authored
With commit 09c2f95a ("scsi: mpt3sas: Swap I/O memory read value back to cpu endianness"), 64bit writes in _base_writeq() were rewritten to use __raw_writeq() instad of writeq(). This introduced a bug apparent on powerpc64 systems such as the Raptor Talos II that causes the HBA to drop from the PCIe bus under heavy load and being reinitialized after a couple of seconds. It can easily be triggered on affacted systems by using something like fio --name=random-write --iodepth=4 --rw=randwrite --bs=4k --direct=0 \ --size=128M --numjobs=64 --end_fsync=1 fio --name=random-write --iodepth=4 --rw=randwrite --bs=64k --direct=0 \ --size=128M --numjobs=64 --end_fsync=1 a couple of times. In my case I tested it on both a ZFS raidz2 and a btrfs raid6 using LSI 9300-8i and 9400-8i controllers. The fix consists in resembling the write ordering of writeq() by adding a mandatory write memory barrier before device access and a compiler barrier afterwards. The additional MMIO barrier is superfluous. Signed-off-by:
Stephan Günther <moepi@moepi.net> Reported-by:
Matt Corallo <linux@bluematt.me> Acked-by:
Sreekanth Reddy <Sreekanth.Reddy@broadcom.com> Signed-off-by:
-
