- 24 Feb, 2013 5 commits
-
-
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:
James Bottomley <JBottomley@Parallels.com>
-
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:
K. Y. Srinivasan <kys@microsoft.com> Cc: stable@vger.kernel.org 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 35 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:Paul Bolle <pebolle@tiscali.nl> 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:
-
Chad Dupuis authored
If another function on the port has initiated a loopback operation do not process the current request. Signed-off-by:
-
Joe Carnuccio authored
When the Read SFP mailbox command fails on the thermal device, print a message explaining that thermal is not supported. Signed-off-by:
-
Masanari Iida authored
Signed-off-by:
Masanari Iida <standby24x7@gmail.com> Signed-off-by:
-
Saurav Kashyap authored
Signed-off-by:
-
Andrew Vasquez authored
There's a subtle race in the loop/bus-reset handling whereby a VHA's loop-state can get incorrectly set to 'down' after the loop-reset and firmware's completion of link re-negotiation. The original code incorrectly assumes that firmware AENs would arrive only after mailbox-command execution to initiate the link-flap. Here's a good case with the old code (AENs arrive after mailbox-command completion): qla2xxx [0000:03:00.1]-8012:91: BUS RESET ISSUED nexus=91:0:4. qla2xxx [0000:03:00.1]-287d:91: FCPort state transitioned from ONLINE to LOST - portid=010100. qla2xxx [0000:03:00.1]-580e:91: Asynchronous P2P MODE received. qla2xxx [0000:03:00.1]-287d:91: FCPort state transitioned from ONLINE to LOST - portid=010400. qla2xxx [0000:03:00.1]-802b:91: BUS RESET SUCCEEDED nexus=91:0:4. qla2xxx [0000:03:00.1]-480b:91: Reset marker scheduled. qla2xxx [0000:03:00.1]-5812:91: Port database changed ffff 0006 0000. qla2xxx [0000:03:00.1]-505f:91: Link is operational (4 Gbps). qla2xxx [0000:03:00.1]-480c:91: Reset marker end. qla2xxx [0000:03:00.1]-480f:91: Loop resync scheduled. qla2xxx [0000:03:00.1]-8837:91: F/W Ready - OK. qla2xxx [0000:03:00.1]-883a:91: fw_state=3 (7, 0, 0, 0) curr time=170b8f315. qla2xxx [0000:03:00.1]-280e:91: HBA in F P2P topology. qla2xxx [0000:03:00.1]-2812:91: qla2x00_configure_hba success qla2xxx [0000:03:00.1]-2814:91: Configure loop -- dpc flags = 0x5260. notice how the 'Port database changed' (8014) arrived after the bus-reset handler completed 'BUS RESET SUCCEEDED'. Now, here's a failing case with the old code (AENs arrive before mailbox-command completion): qla2xxx [0000:03:00.1]-8012:91: BUS RESET ISSUED nexus=91:0:0. qla2xxx [0000:03:00.1]-580e:91: Asynchronous P2P MODE received. qla2xxx [0000:03:00.1]-287d:91: FCPort state transitioned from ONLINE to LOST - portid=010100. qla2xxx [0000:03:00.1]-287d:91: FCPort state transitioned from ONLINE to LOST - portid=010400. qla2xxx [0000:03:00.1]-4800:91: DPC handler sleeping. qla2xxx [0000:03:00.1]-5812:91: Port database changed ffff 0006 0000. qla2xxx [0000:03:00.1]-505f:91: Link is operational (4 Gbps). qla2xxx [0000:03:00.1]-802b:91: BUS RESET SUCCEEDED nexus=91:0:0. qla2xxx [0000:03:00.1]-480b:91: Reset marker scheduled. qla2xxx [0000:03:00.1]-480c:91: Reset marker end. qla2xxx [0000:03:00.1]-480f:91: Loop resync scheduled. qla2xxx [0000:03:00.1]-8837:91: F/W Ready - OK. qla2xxx [0000:03:00.1]-883a:91: fw_state=3 (7, 0, 0, 0) curr time=170be9eb2. qla2xxx [0000:03:00.1]-280e:91: HBA in F P2P topology. qla2xxx [0000:03:00.1]-2812:91: qla2x00_configure_hba success qla2xxx [0000:03:00.1]-2814:91: Configure loop -- dpc flags = 0x5260. qla2xxx [0000:03:00.1]-281e:91: Needs RSCN update and loop transition. qla2xxx [0000:03:00.1]-286a:91: qla2x00_configure_loop *** FAILED ***. qla2xxx [0000:03:00.1]-4810:91: Loop resync end. qla2xxx [0000:03:00.1]-4800:91: DPC handler sleeping. This race would ultimately lead to devices go unexpectedly offline until another link-flap or chip-reset would cause driver re-discovery to take place. Signed-off-by:
-
Saurav Kashyap authored
Signed-off-by:
-
Arun Easi authored
Signed-off-by:
Arun Easi <arun.easi@qlogic.com> Signed-off-by:
-
Arun Easi authored
Signed-off-by:
-
