- 27 Aug, 2015 26 commits
-
-
Matthew R. Ochs authored
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 <mrochs@linux.vnet.ibm.com> Signed-off-by:
Manoj N. Kumar <manoj@linux.vnet.ibm.com> Reviewed-by:
Michael Neuling <mikey@neuling.org> Reviewed-by:
Wen Xiong <wenxiong@linux.vnet.ibm.com> Reviewed-by:
Brian King <brking@linux.vnet.ibm.com> Signed-off-by:
James Bottomley <JBottomley@Odin.com>
-
Matthew R. Ochs authored
Introduce support for enhanced I/O error handling. A device state is added to track 3 possible states of the device: Normal - the device is operating normally and is fully operational Limbo - the device is in a reset/recovery scenario and its operational status is paused Failed/terminating - the device has either failed to be reset/recovered or is being terminated (removed); it is no longer operational All operations are allowed when the device is operating normally. When the device transitions to limbo state, I/O must be paused. To help accomplish this, a wait queue is introduced where existing and new threads can wait until the device is no longer in limbo. When coming out of limbo, threads need to check the state and error out gracefully when encountering the failed state. When the device transitions to the failed/terminating state, normal operations are no longer allowed. Only specially designated operations related to graceful cleanup are permitted. Signed-off-by:Daniel Axtens <dja@axtens.net> Reviewed-by:
-
Himanshu Madhani authored
Signed-off-by:
Himanshu Madhani <himanshu.madhani@qlogic.com> Signed-off-by:
Giridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by:
-
Sawan Chandak authored
Signed-off-by:
Sawan Chandak <sawan.chandak@qlogic.com> Signed-off-by:
-
Arun Easi authored
On certain conditions, login failures will just invoke qla2x00_mark_device_lost() with the intend to do login again; but if login_retry has been set already, that would fail to set the relogin needed flag which is required to wakeup the DPC to retry. Signed-off-by:
Arun Easi <arun.easi@qlogic.com> Signed-off-by:
-
Himanshu Madhani authored
Signed-off-by:
-
Chad Dupuis authored
Fix for memory leak when command is not found by firmware due to mismatch in sp reference count. Signed-off-by:
Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by:
-
Sawan Chandak authored
Signed-off-by:
-
Chad Dupuis authored
Instead of resetting the adapter wait for the login to timeout and retry. Resetting the adapter can cause extended path recovery times. Signed-off-by:
-
Chad Dupuis authored
If an SRB is NULL but the handle is in range just drop the command instead of also resetting the adapter. If the handle is in range then the command was valid at some point and may have been aborted. Resetting the adapter can lead to extended recovery times in this case. Signed-off-by:
-
Hiral Patel authored
Aovid crashing the system in the scenario where firmware just completes the command and it can not find the command during abort mailbox processing. This scenario can lead to sp reference counter being zero. Instead of crashing the system, use WARN_ON to print warning in log file. Signed-off-by:
Hiral Patel <hiral.patel@qlogic.com> Signed-off-by:
-
Saurav Kashyap authored
Signed-off-by:
Saurav Kashyap <saurav.kashyap@qlogic.com> Signed-off-by:
-
Joe Carnuccio authored
Signed-off-by:
Joe Carnuccio <joe.carnuccio@qlogic.com> Signed-off-by:
-
Joe Carnuccio authored
Execute qla25xx_manipulate_risc_semaphore() only for ssdid 0x0175 and 0x0240. Signed-off-by:
-
Joe Carnuccio authored
When we get logged out, mark the port lost and set dpc flag for relogin. Signed-off-by:
-
Joe Carnuccio authored
Signed-off-by:
-
jiang.biao2@zte.com.cn authored
scsi_error: should not get sense for timeout IO in scsi error handler When an IO timeout occurs, the IO will be aborted in scsi_abort_command() and SCSI_EH_ABORT_SCHEDULED will be set. Because of that, the SCSI_EH_CANCEL_CMD will be clear in scsi_eh_scmd_add(). So when scsi error handler starts, it will get sense for this timeout IO and the scmd of the IO request will be reused. In that case, the scmd may be double released when racing with io_done(), which will result in crash. SO SCSI_EH_ABORT_SCHEDULED should also be checked when getting sense. The bug maybe reproduced when the link between host and disk is unstable. Signed-off-by:
Jiang Biao <jiang.biao2@zte.com.cn> Signed-off-by:
Long Chun <long.chun@zte.com.cn> Reviewed-by:
Tan Hu <tan.hu@zte.com.cn> Reviewed-by:
Chen Donghai <chen.donghai@zte.com.cn> Reviewed-by:
Cai Qu <cai.qu@zte.com.cn> Signed-off-by:
-
Viswas G authored
Bump pm80xx driver version to 0.1.38. Signed-off-by:
Viswas G <Viswas.G@pmcs.com> Reviewed-by:
Suresh Thiagarajan <Suresh.Thiagarajan@pmcs.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
Jack Wang <jinpu.wang@profitbricks.com> Reviewed-by:
Tomas Henzl <thenzl@redhat.com> Signed-off-by:
-
Viswas G authored
The request has to be retried incase if the length of the SSP Response IU is invalid. Signed-off-by:
-
Viswas G authored
PORT RECOVERY TIMEOUT is the maximum time between the controller's detection of the PHY down until the receipt of the ID_Frame (from the same remote SAS port). If the time expires before the ID_FRAME is received, the port is considered INVALID and can be removed. The IOP_EVENT_PORT_RECOVERY_TIMER_TMO event is reported following the IOP_EVENT_ PHY_DOWN event when the PHY/port does not recover after Port Recovery Time. Signed-off-by:
-
Viswas G authored
If the link error happens, we don't need to disconnect the phy, which will remove the drive. Instead acknowledging the controller and logging the error will be enough. Signed-off-by:
-
Viswas G authored
In pm8001_ccb_task_free(), the dma unmapping is done based on ccb->n_elem value. This should be initialized to zero in the task_abort(). Otherwise, pm8001_ccb_task_free() will try for dma_unmap_sg() which is invalid for task abort and can lead to kernel crash. Changes From V1: None Signed-off-by:
-
Viswas G authored
Thermal page code has been changed to 7 for the 12G controllers. Signed-off-by:
-
Viswas G authored
In Nexus reset the device state request are not needed. Signed-off-by:
-
Viswas G authored
Updated 12G linkrate to libsas. Signed-off-by:
-
Jack Wang authored
Company has policy to use company email address, so update my email address to company address. Signed-off-by:
-
- 26 Aug, 2015 14 commits
-
-
Sebastian Herbszt authored
Use logical instead of bitwise AND. Signed-off-by:
Sebastian Herbszt <herbszt@gmx.de> Reviewed-by:
James Smart <james.smart@avagotech.com> Signed-off-by:
-
Dilip Kumar Uppugandla authored
Invoking get_cmd_state for qla2xxx always returns 0. Instead change it to return the actual fabric state from qla_tgt_cmd. This will help with debugging. Signed-off-by:
Dilip Kumar Uppugandla <dilip@purestorage.com> Signed-off-by:
Spencer Baugh <sbaugh@catern.com> Acked-by:
-
Don Brace authored
The driver is calling hpsa_shutdown before calling scsi_remove_host. hpsa_shutdown is disabling interrupts. scsi_remove_host can trigger I/O operations, such as SYNCHRONIZE CACHE when multipath is enabled which hang the system. Call scsi_remove_host before calling hpsa_shutdown. Reviewed-by:
Kevin Barnett <kevin.barnett@pmcs.com> Reviewed-by:
Scott Teel <scott.teel@pmcs.com> Reviewed-by:
Don Brace <don.brace@pmcs.com> Signed-off-by:
-
shane.seymour authored
A regression was introduced into the hpsa driver a while back so non-zero LUNs of multi-LUN devices may no longer be presented via a SAS based Smart Array. I have not done a bisection to discover the change that caused it. The CISS firmware specification (available on sourceforge) defines an 8 byte lunid that describes devices that the Smart Array can see/present to the system. The current code in the hpsa driver attempts to find matches for non-zero LUNs with LUN 0 for a bus/target by zeroing out byte 4 of the lunid and find a match. This method is sufficient for SCSI based Smart Arrays because byte 5 is always 0. For SAS based Smart arrays byte 5 of the lunid contains the path number for a multipath device and either one or two bits (the documentation does not define how many bits are used but it appears it may be one only) that indicate if the given path number in byte 5 must always be used to access that device. Byte 5 may not always be zero. The following are lunids (spaces added for clarity) for a MSL2024 single drive library connected via a H241 Smart Array: 00 00 00 00 01 00 00 01 (changer) 00 00 00 00 00 80 00 01 (tape) In the 4th byte (counting from 0) you can see that the tape is LUN 0 and the changer is LUN 1. The 0x80 set in the 5th byte for the tape drive means the driver should force access to path 0 (the library in this case was connected to one path only anyway). After the changes we can see the following in the dmesg output: scsi 0:3:0:0: RAID HP H241 1.18 \ PQ: 0 ANSI: 5 scsi 0:2:0:0: Sequential-Access HP Ultrium 6-SCSI 354W \ PQ: 0 ANSI: 6 scsi 0:2:0:1: Medium Changer HP MSL G3 Series 8.70 \ PQ: 0 ANSI: 5 Showing that the changer is correctly identified as LUN 1 of bus 2 target 0. Before the change the changer device is not seen. Suggested-by:
shane.seymour <shane.seymour@hp.com> Reviewed-by:
-
Scott Benesh authored
prevent adding volumes that are not available. Reviewed-by:
Justin Lindley <justin.lindley@pmcs.com> Reviewed-by:
-
Kevin Barnett authored
Reviewed-by:
-
Don Brace authored
Reviewed-by:
-
Don Brace authored
showing that tables have been updated unnecessarily. Reviewed-by:
-
Joe Handzik authored
host no, bus, target, lun, scsi_device_type for hba mode add: box and bay information report if the path is active/inactive Reviewed-by:
-
Don Brace authored
need to add PMC to copyright notice and update the Hewlett-Packard copyright notification. Reviewed-by:
-
Don Brace authored
Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Don Brace authored
Reported-by:
-
Don Brace authored
Reported-by:
-
Sreekanth Reddy authored
Driver crashes if the BIOS do not set up at least one memory I/O resource. This failure can happen if the device is too slow to respond during POST and is missed by the BIOS, but Linux then detects the device later in the boot process. Based on a patch from Timothy Pearson <tpearson@raptorengineeringinc.com> Signed-off-by:
Sreekanth Reddy <Sreekanth.Reddy@avagotech.com> Reviewed-by:
-
