- 27 Jul, 2010 40 commits
-
-
Giridhar Malavali authored
Signed-off-by:
Giridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de>
-
Arun Easi authored
Signed-off-by:
-
Lalit Chandivade authored
Driver was not unprotecting correctly, use correct bits to unprotect the flash on ISP 82xx. Signed-off-by:
-
Santosh Vernekar authored
Outstanding mailbox commands, have no way to recover on f/w hung, and we timeout on waiting for mbx response. This in turn affects the recovery process as follows: - We might already be in dpc while waiting for mbx to complete, so recovery for that pci function will never get invoked. Reset Timeout (10 sec) is far less than mbx timeout (30 sec). - Other mbx cmds will get stuck due to serial mbx access. Solution is to identify fw-hung scenario and handle outstanding mbx commands to have an early-exit instead of waiting for response. Other mbx commands waiting for access will also do an early-exit if fw-hung is still applicable. Signed-off-by:
-
Lalit Chandivade authored
After topology change ISP is reset and VPs are re-enabled. If the topology is not fabric, VPs could falsely get enabled. Signed-off-by:
-
Harish Zunjarrao authored
Used bootloder address from FLT while loading FW from flash as well. Signed-off-by:
-
Andrew Vasquez authored
In case of both target and initiator capabilities reported by fc port, the fc port port capability is made mutualy exclusive with priority given for target capabilities. Signed-off-by:
-
Sarang Radke authored
Signed-off-by:
-
Giridhar Malavali authored
Signed-off-by:
Andrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by:
-
Andrew Vasquez authored
* hold the hardware_lock throughout the duration of ctx-sp timeout handling -- could result in use-after-free oops. * retry a timed-out login-request. * done() routines are called with the hardware-lock held, issue qla2x00_mark_device_lost() with proper 'defer' flag. * FCP2 capabilities are only relevant to target devices. Signed-off-by:
-
Giridhar Malavali authored
Hold a reference to the srb (sp) while aborting an I/O -- as the I/O can/will complete from within the interrupt-context. Signed-off-by:
-
Giridhar Malavali authored
The TMFs used for pre-24xx ISPs incorrectly assumed 'cpu' tag data could be valid. These chips have no multi-q/cpu-affinity support. This corrects an oops seen on ISP23xx parts. Signed-off-by:
-
Andrew Vasquez authored
This helps to correlate submission/completion messages during triaging. Signed-off-by:
-
Giridhar Malavali authored
The CRB drive active register is cleared when driver is unloaded or when driver enters failed state. 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
We have 32 (MAXSGENTRIES) scatter gather elements embedded in the command. With all these, the total command size is about 576 bytes. However, the last entry in the block fetch table is 35. (the block fetch table contains the number of 16-byte chunks the firmware needs to fetch for a given number of scatter gather elements.) 35 * 16 = 560 bytes, which isn't enough. It needs to be 36. (36 * 16 == 576) or, MAXSGENTRIES + 4. (plus 4 because there's a bunch of stuff at the front of the command before the first scatter gather element that takes up 4 * 16 bytes.) Without this fix, the controller may have to perform two DMA operations to fetch the command since the first one may not get the whole thing. Signed-off-by:
Don Brace <brace@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:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
before trying to enter simple mode transport method. Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
and delete duplicated comment Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Julia Lawall authored
The end of the function is reachable both when host is and is not NULL. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r exists@ expression E,E1; identifier f; statement S1,S2,S3; @@ if ((E == NULL && ...) || ...) { ... when != if (...) S1 else S2 when != E = E1 * E->f ... when any return ...; } else S3 // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Signed-off-by:
-
Ryan Kuester authored
I may have an explanation for the LSI 1068 HBA hangs provoked by ATA pass-through commands, in particular by smartctl. First, my version of the symptoms. On an LSI SAS1068E B3 HBA running 01.29.00.00 firmware, with SATA disks, and with smartd running, I'm seeing occasional task, bus, and host resets, some of which lead to hard faults of the HBA requiring a reboot. Abusively looping the smartctl command, # while true; do smartctl -a /dev/sdb > /dev/null; done dramatically increases the frequency of these failures to nearly one per minute. A high IO load through the HBA while looping smartctl seems to improve the chance of a full scsi host reset or a non-recoverable hang. I reduced what smartctl was doing down to a simple test case which causes the hang with a single IO when pointed at the sd interface. See the code at the bottom of this e-mail. It uses an SG_IO ioctl to issue a single pass-through ATA identify device command. If the buffer userspace gives for the read data has certain alignments, the task is issued to the HBA but the HBA fails to respond. If run against the sg interface, neither the test code nor smartctl causes a hang. sd and sg handle the SG_IO ioctl slightly differently. Unless you specifically set a flag to do direct IO, sg passes a buffer of its own, which is page-aligned, to the block layer and later copies the result into the userspace buffer regardless of its alignment. sd, on the other hand, always does direct IO unless the userspace buffer fails an alignment test at block/blk-map.c line 57, in which case a page-aligned buffer is created and used for the transfer. The alignment test currently checks for word-alignment, the default setup by scsi_lib.c; therefore, userspace buffers of almost any alignment are given directly to the HBA as DMA targets. The LSI 1068 hardware doesn't seem to like at least a couple of the alignments which cross a page boundary (see the test code below). Curiously, many page-boundary-crossing alignments do work just fine. So, either the hardware has an bug handling certain alignments or the hardware has a stricter alignment requirement than the driver is advertising. If stricter alignment is required, then in no case should misaligned buffers from userspace be allowed through without being bounced or at least causing an error to be returned. It seems the mptsas driver could use blk_queue_dma_alignment() to advertise a stricter alignment requirement. If it does, sd does the right thing and bounces misaligned buffers (see block/blk-map.c line 57). The following patch to 2.6.34-rc5 makes my symptoms go away. I'm sure this is the wrong place for this code, but it gets my idea across. Acked-by:"Desai, Kashyap" <Kashyap.Desai@lsi.com> Signed-off-by:
-
