- 28 7月, 2010 40 次提交
-
-
由 Giridhar Malavali 提交于
Signed-off-by: NGiridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Arun Easi 提交于
Signed-off-by: NGiridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Lalit Chandivade 提交于
Driver was not unprotecting correctly, use correct bits to unprotect the flash on ISP 82xx. Signed-off-by: NGiridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Santosh Vernekar 提交于
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: NGiridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Lalit Chandivade 提交于
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: NGiridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Harish Zunjarrao 提交于
Used bootloder address from FLT while loading FW from flash as well. Signed-off-by: NGiridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Andrew Vasquez 提交于
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: NGiridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Sarang Radke 提交于
Signed-off-by: NGiridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Giridhar Malavali 提交于
Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by: NGiridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Andrew Vasquez 提交于
* 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: NGiridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Giridhar Malavali 提交于
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: NAndrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by: NGiridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Giridhar Malavali 提交于
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: NAndrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by: NGiridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Andrew Vasquez 提交于
This helps to correlate submission/completion messages during triaging. Signed-off-by: NGiridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Giridhar Malavali 提交于
The CRB drive active register is cleared when driver is unloaded or when driver enters failed state. Signed-off-by: NGiridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Stephen M. Cameron 提交于
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Stephen M. Cameron 提交于
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: NDon Brace <brace@beardog.cce.hp.com> Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Stephen M. Cameron 提交于
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Stephen M. Cameron 提交于
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Stephen M. Cameron 提交于
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Stephen M. Cameron 提交于
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Stephen M. Cameron 提交于
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Stephen M. Cameron 提交于
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Stephen M. Cameron 提交于
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Stephen M. Cameron 提交于
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Stephen M. Cameron 提交于
before trying to enter simple mode transport method. Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Stephen M. Cameron 提交于
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Stephen M. Cameron 提交于
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Stephen M. Cameron 提交于
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Stephen M. Cameron 提交于
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Stephen M. Cameron 提交于
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Stephen M. Cameron 提交于
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Stephen M. Cameron 提交于
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Stephen M. Cameron 提交于
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Stephen M. Cameron 提交于
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Stephen M. Cameron 提交于
and delete duplicated comment Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Stephen M. Cameron 提交于
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Stephen M. Cameron 提交于
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Stephen M. Cameron 提交于
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Julia Lawall 提交于
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: NJulia Lawall <julia@diku.dk> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Ryan Kuester 提交于
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: N"Desai, Kashyap" <Kashyap.Desai@lsi.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-