kernel.git/drivers/scsi/hpsa_cmd.h, branch linux-3.2.y

hpsa: dial down lockup detection during firmware flash

2012-10-17T02:50:02Z

commit e85c59746957fd6e3595d02cf614370056b5816e upstream. Dial back the aggressiveness of the controller lockup detection thread. Currently it will declare the controller to be locked up if it goes for 10 seconds with no interrupts and no change in the heartbeat register. Dial back this to 30 seconds with no heartbeat change, and also snoop the ioctl path and if a firmware flash command is detected, dial it back further to 4 minutes until the firmware flash command completes. The reason for this is that during the firmware flash operation, the controller apparently doesn't update the heartbeat register as frequently as it is supposed to, and we can get a false positive. Signed-off-by: Stephen M. Cameron Signed-off-by: James Bottomley [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

[SCSI] hpsa: fix potential array overflow in hpsa_update_scsi_devices

2011-10-30T10:34:04Z

The currentsd[] array in hpsa_update_scsi_devices had room for 256 devices. The code was iterating over however many physical and logical devices plus an additional number of possible external MSA2XXX controllers, which together could potentially exceed 256. We increased the size of the currentsd array to 1024 + 1024 + 32 + 1 elements to reflect a reasonable maximum possible number of devices which might be encountered. We also don't just walk off the end of the array if the array controller reports more devices than we are prepared to handle, we just ignore the excessive devices. Signed-off-by: Scott Teel Signed-off-by: Stephen M. Cameron Signed-off-by: James Bottomley

[SCSI] hpsa: use new doorbell-bit-5 reset method

2011-05-17T07:07:01Z

The bit-2-doorbell reset method seemed to cause (survivable) NMIs on some systems and (unsurvivable) IOCK NMIs on some G7 servers. Firmware guys implemented a new doorbell method to alleviate these problems triggered by bit 5 of the doorbell register. We want to use it if it's available. Signed-off-by: Stephen M. Cameron Signed-off-by: James Bottomley Signed-off-by: James Bottomley

[SCSI] hpsa: do a better job of detecting controller reset failure

2011-05-17T07:04:11Z

Detect failure of controller reset by noticing if the 32 bytes of "driver version" we store on the hardware in the config table fail to get zeroed out. Previously we noticed if the controller did not transition to "simple mode", but this did not detect reset failure if the controller was already in simple mode prior to the reset attempt (e.g. due to module parameter hpsa_simple_mode=1). Signed-off-by: Stephen M. Cameron Signed-off-by: James Bottomley Signed-off-by: James Bottomley

[SCSI] hpsa: delete old unused padding garbage

2011-05-17T07:03:32Z

Signed-off-by: Stephen M. Cameron Signed-off-by: James Bottomley Signed-off-by: James Bottomley

[SCSI] hpsa: Inform controller we are using 32-bit tags.

2011-02-18T18:33:52Z

Controller will transfer only 32-bits on completion if it knows we are only using 32-bit tags. Also, some newer controllers apparently (and erroneously) require that we only use 32-bit tags, and that we inform the controller of this. Signed-off-by: Stephen M. Cameron Signed-off-by: James Bottomley

[SCSI] hpsa: do not re-order commands in internal queues

2011-02-18T18:31:19Z

Driver's internal queues should be FIFO, not LIFO. This is a port of an almost identical patch from cciss by Jens Axboe. Signed-off-by: Stephen M. Cameron Signed-off-by: James Bottomley

[SCSI] hpsa: fixup DMA address before freeing.

2011-01-24T17:29:05Z

Some low bits might have been set by the driver, causing a message like this to come out: [ 13.288062] ------------[ cut here ]------------ [ 13.293211] WARNING: at lib/dma-debug.c:803 check_unmap+0x1a1/0x654() [ 13.300387] Hardware name: ProLiant DL180 G6 [ 13.305335] hpsa 0000:06:00.0: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x000000007f81e001] [size=640 bytes] Signed-off-by: Stephen M. Cameron Signed-off-by: James Bottomley

[SCSI] hpsa: Fix hard reset code.

2010-07-27T17:02:00Z

Smart Array controllers newer than the P600 do not honor the PCI power state method of resetting the controllers. Instead, in these cases we can get them to reset via the "doorbell" register. This escaped notice until we began using "performant" mode because the fact that the controllers did not reset did not normally impede subsequent operation, and so things generally appeared to "work". Once the performant mode code was added, if the controller does not reset, it remains in performant mode. The code immediately after the reset presumes the controller is in "simple" mode (which previously, it had remained in simple mode the whole time). If the controller remains in performant mode any code which presumes it is in simple mode will not work. So the reset needs to be fixed. Unfortunately there are some controllers which cannot be reset by either method. (eg. p800). We detect these cases by noticing that the controller seems to remain in performant mode even after a reset has been attempted. In those case, we proceed anyway, as if the reset has happened (and skip the step of waiting for the controller to become ready -- which is expecting it to be in "simple" mode.) To sum up, we try to do a better job of resetting the controller if "reset_devices" is set, and if it doesn't work, we print a message and try to continue anyway. Signed-off-by: Stephen M. Cameron Signed-off-by: James Bottomley

[SCSI] hpsa: remove unneeded defines

2010-05-02T15:02:17Z

This patch removes unnecessary #define's from hpsa. The SCSI midlayer handles all this for us. Signed-off-by: Mike Miller Signed-off-by: James Bottomley