- 24 Feb, 2013 13 commits
-
-
K. Y. Srinivasan authored
In preparation for handling additional sense codes, restructure and cleanup the error handling code in the command completion code path. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Reviewed-by:
Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
Olaf Hering authored
Set scsi_device->no_write_same because the host does not support it. Also blacklist WRITE_SAME to avoid (and log) accident usage. If the guest uses the ext4 filesystem, storvsc hangs while it prints these messages in an endless loop: ... [ 161.459523] hv_storvsc vmbus_0_1: cmd 0x41 scsi status 0x2 srb status 0x6 [ 161.462157] sd 2:0:0:0: [sda] [ 161.463135] Sense Key : No Sense [current] [ 161.464983] sd 2:0:0:0: [sda] [ 161.465899] Add. Sense: No additional sense information [ 161.468211] hv_storvsc vmbus_0_1: cmd 0x41 scsi status 0x2 srb status 0x6 [ 161.475766] sd 2:0:0:0: [sda] [ 161.476728] Sense Key : No Sense [current] [ 161.478284] sd 2:0:0:0: [sda] [ 161.479441] Add. Sense: No additional sense information ... This happens with a guest running on Windows Server 2012, but happens to work while running on Windows Server 2008. WRITE_SAME isnt really supported by both versions, so disable the command usage globally. Signed-off-by:
Olaf Hering <olaf@aepfle.de> Signed-off-by:
-
Paul Bolle authored
Building src.o for a 32 bit system triggers two GCC warnings: drivers/scsi/aacraid/src.c: In function ‘aac_src_deliver_message’: drivers/scsi/aacraid/src.c:410:3: warning: right shift count >= width of type [enabled by default] drivers/scsi/aacraid/src.c:434:2: warning: right shift count >= width of type [enabled by default] These warnings are caused by a right shift of 32. Use upper_32_bits() to suppress them. Signed-off-by:Paul Bolle <pebolle@tiscali.nl> Cc: Mahesh Rajashekhara <Mahesh_Rajashekhara@pmc-sierra.com> Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Shuah Khan authored
Signed-off-by:
Shuah Khan <shuah.khan@hp.com> Signed-off-by:
-
Dan Carpenter authored
This bug was introduced back in bitkeeper days in 2003. We use "dcb->dev_mode" before it has been initialized. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Oliver Neukum <oliver@neukum.org> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Martin K. Petersen authored
The range checking from fe542396 was bad. We would still end up walking beyond the array as Type 3 is defined to be 4 in the protection bitmask. Instead use ARRAY_SIZE() for the range check. Reported-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
K. Y. Srinivasan authored
Properly initialize scatterlist before using it. Signed-off-by:
-
Sreekanth Reddy authored
Defined SSDID & HW vendor brand strings. Added entries for SSDID within the function that prints the brand string. Signed-off-by:
Sreekanth Reddy <Sreekanth.Reddy@lsi.com> Signed-off-by:
-
Brian King authored
When resetting an ipr adapter, we use scsi_block_requests to block any new commands from scsi core, and then unblock after the reset. When hotplug removing an adapter, we shut it down and go through this same code, but we've seen issues with scsi_unblock_requests running after the adapter's memory has been freed. There is really no need to block/unblock when the adapter is being removed, so this patch skips the block/unblock and will immediately fail any commands that happen to make it to queuecommand while the adapter is being shutdown. Signed-off-by:
Brian King <brking@linux.vnet.ibm.com> Signed-off-by:
Wen Xiong <wenxiong@linux.vnet.ibm.com> Signed-off-by:
-
- 22 Feb, 2013 27 commits
-
-
Hiral Patel authored
Fnic Trace utility is a tracing functionality built directly into fnic driver to trace events. The benefit that trace buffer brings to fnic driver is the ability to see what it happening inside the fnic driver. It also provides the capability to trace every IO event inside fnic driver to debug panics, hangs and potentially IO corruption issues. This feature makes it easy to find problems in fnic driver and it also helps in tracking down strange bugs in a more manageable way. Trace buffer is shared across all fnic instances for this implementation. Signed-off-by:
Hiral Patel <hiralpat@cisco.com> Signed-off-by:
-
Hiral Patel authored
Added new fnic debug flags for identifying IO state at every stage of IO while debugging and also added more log messages for better debugging capability. Signed-off-by:
Sesidhar Baddela <sebaddel@cisco.com> Signed-off-by:
-
Hiral Patel authored
The issue was observed when LUN Reset is issued through IOCTL or sg_reset utility. fnic driver issues LUN RESET to firmware. On successful completion of device reset, driver cleans up all the pending IOs that were issued prior to device reset. These pending IOs are expected to be in ABTS_PENDING state. This works fine, when the device reset operation resulted from midlayer, but not when device reset was triggered from IOCTL path as the pending IOs were not in ABTS_PENDING state. execution path hits panic if the pending IO is not in ABTS_PENDING state. Changes: The fix replaces BUG_ON check in fnic_clean_pending_aborts() with marking pending IOs as ABTS_PENDING if they were not in ABTS_PENDING state and skips if they were already in ABTS_PENDING state. An extra check is added to validate the abort status of the commands after a delay of 2 * E_D_TOV using a helper function. The helper function returns 1 if it finds any pending IO in ABTS_PENDING state, belong to the LUN on which device reset was issued else 0. With this, device reset operation returns success only if the helper funciton returns 0, otherwise it returns failure. Other changes: - Removed code in fnic_clean_pending_aborts() that returns failure if it finds io_req NULL, instead of returning failure added code to continue with next io - Added device reset flags for debugging in fnic_terminate_rport_io, fnic_rport_exch_reset, and fnic_clean_pending_aborts Signed-off-by:
Narsimhulu Musini <nmusini@cisco.com> Signed-off-by:
-
Hiral Patel authored
Driver allows IOs with more SGEs than max SGEs supported by Palo. The current max SGEs supported by the fnic driver is 1024. The current register settings on Palo supports a max of 256 only. Palo would return any IO with more than 256 SGEs with an error indicating INVALID_SGLS. Fnic driver should limit the max supported SGLs in the driver to 256 to avoid this error. Signed-off-by:
-
Hiral Patel authored
1. Handling overlapped firmware resets This fix serialize multiple firmware resets to avoid situation where fnic device fails to come up for link up event, when firmware resets are issued back to back. If there are overlapped firmware resets are issued, the firmware reset operation checks whether there is any firmware reset in progress, if so it polls for its completion in a loop with 100ms delay. 2. Handling device reset timeout fnic_device_reset code has been modified to handle Device reset timeout: - Issue terminate on device reset timeout. - Introduced flags field (one of the scratch fields in scsi_cmnd). With this, device reset request would have DEVICE_RESET flag set for other routines to determine the type of the request. Also modified fnic_terminate_rport_io, fnic_rport_exch_rset, completion routines to handle SCSI commands with DEVICE_RESET flag. 3. LUN/Device Reset hangs when issued through IOCTL using utilities like sg_reset. Each SCSI command is associated with a valid tag, fnic uses this tag to retrieve associated scsi command on completion. the LUN/Device Reset issued through IOCTL resulting into a SCSI command that is not associated with a valid tag. So fnic fails to retrieve associated scsi command on completion, which causes hang. This fix allocates tag, associates it with the scsi command and frees the tag, when the operation completed. 4. Preventing IOs during firmware reset. Current fnic implementation allows IO submissions during firmware reset. This fix synchronizes IO submissions and firmware reset operations. It ensures that IOs issued to fnic prior to reset will be issued to the firmware before firmware reset. Signed-off-by: -
Sakthivel K authored
All memory regions are allocated based on variables total_len and alignment but free was based on element_size. Signed-off-by:
Sakthivel K <DL.Team.PMC.SPC.Linux.open.source@pmcs.com> Signed-off-by:
-
adam radford authored
This patch updates the megaraid_sas driver version and updates Documentation/scsi/ChangeLog.megaraid_sas. Signed-off-by:
Adam Radford <aradford@gmail.com> Signed-off-by:
-
adam radford authored
The following patch for megaraid_sas will fix an issue where the driver should not be loading the DevHandle unless FastPath is enabled. If FastPath was not enabled, this means the hardware raid map validation failed for some reason, or the map was corrupted, which could mean the DevHandle could be invalid. Signed-off-by:
-
adam radford authored
The following patch for megaraid_sas will allow Fastpath T10PI/DIF frame builds to work with 4k sector size. Signed-off-by:
-
Chad Dupuis authored
Wait for the IDC complete AEN before returning the loopback operation back to the application to make sure the port is put back into normal operations. Signed-off-by:
Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by:
Saurav Kashyap <saurav.kashyap@qlogic.com> Signed-off-by:
-
Joe Carnuccio authored
Give priority to I2C thermal. Signed-off-by:
Joe Carnuccio <joe.carnuccio@qlogic.com> Signed-off-by:
-
Saurav Kashyap authored
Signed-off-by:
Giridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by:
-
Chad Dupuis authored
Currently,the driver is processes RSCNs for each new NPIV ports that is created. Processing the RSCN includes a name server query to see what has changed at the name server side. The name server query is performed by the physical port and each virtual port on the physical adapter (since the RSCN is passed to each virtual port for processing). As the number of virtual ports being created increases, this causes a lot of traffic and busies the firmware. Processing the RSCN for a virtual port we already have a priori knowledge of is not necessary so check the 24-bit fabric ID of the RSCN entry and skip processing it if the RSCN is for a virtual port we already know about. Signed-off-by:
-
Joe Carnuccio authored
Signed-off-by:
-
Joe Carnuccio authored
Signed-off-by:
-
Andrew Vasquez authored
Code in qla24xx_report_id_acquisition() incorrectly assumed that upon completion of list iteration (with no match), the 'pos' (vp) variable passed to list_for_each_entry() would be set to NULL. In this context, if the firmware were to return an unrecognized vp_idx, the follow-on assignments to vp-members could result in corruption of the structure. Signed-off-by:
Andrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by:
-
Joe Carnuccio authored
This reverts commit c0822b63. Signed-off-by:
-
Joe Carnuccio authored
This reverts commit 4dc77c36. Signed-off-by:
-
Paul Bolle authored
Compiling qla_gs.o (part of the qla2xxx module) triggers two GCC warnings: drivers/scsi/qla2xxx/qla_gs.c: In function ‘qla2x00_fdmi_rhba’: drivers/scsi/qla2xxx/qla_gs.c:1339:7: warning: array subscript is above array bounds [-Warray-bounds] drivers/scsi/qla2xxx/qla_gs.c: In function ‘qla2x00_fdmi_register’: drivers/scsi/qla2xxx/qla_gs.c:1663:15: warning: array subscript is above array bounds [-Warray-bounds] It seems that the sequence of a strcpy followed by a strlen confuses GCC when it is keeping track of array bounds here. (It is not clear to me which array triggers this warning and by how much GCC thinks the subscript is above its bounds. Neither is it clear to me why comparable code in these two functions doesn't trigger this warning.) An easy way to silence these warnings is to use preprocessor macros and strncpy, as that apparently gives GCC enough information to keep track of array bounds. Signed-off-by: -
Saurav Kashyap authored
Signed-off-by:
-
Saurav Kashyap authored
Signed-off-by:
-
Chad Dupuis authored
If we need to do a chip reset because of a serious loopback error don't try to reset the loopback mode on the port as the mailbox command will timeout. Signed-off-by:
-
Chad Dupuis authored
Add the following error handling for loopback diagnostic mode with ISP83xx: 1. If we do not receive an MBA_DCBX_COMPLETE after our initial set port configuration command, try to reset the port back into normal operation. If that fails, take a FCoE dump and then reset the chip. 2. After completing the loopback diagnostic operation, if the reset of the port back into normal operation fails then reset the port so we take a FCoE dump and then reset the chip. 3. When we receive an IDC notification and the requested operation is loopback extend the loop down timer so the link does not appear to down for an extended period of time. [jejb: fix checkpatch issue] Signed-off-by:
-
Chad Dupuis authored
BSG code path increments ref count in the send path, but does not decrement in the return path leading to hang during unload of the driver. Signed-off-by:
-
Saurav Kashyap authored
Signed-off-by:
-
Joe Carnuccio authored
To avoid continually doing ISP resets when get loop id fails to obtain the adapter loop id, first try to do a link initialization. Signed-off-by:
-
Giridhar Malavali authored
Signed-off-by:
-
