talos-op-linux/drivers/block/cciss.c, branch v2.6.36-rc5

cciss: fix reporting of max queue depth since init

2010-08-25T17:58:53+00:00

The ioctl path and the scsi tape path were not accounting for their additions to the queue depth. Signed-off-by: Stephen M. Cameron Signed-off-by: Jens Axboe

cciss: handle allocation failure

2010-08-23T10:28:15+00:00

If kmalloc() fails then cleanup and return failure (-1). Signed-off-by: Dan Carpenter Acked-by: Stephen M. Cameron Signed-off-by: Jens Axboe

cciss: disable doorbell reset on reset_devices

2010-08-23T09:02:17+00:00

The doorbell reset initially appears to work correctly, the controller resets, comes up, some i/o can even be done, but on at least some Smart Arrays in some servers, it eventually causes a subsequent controller lockup due to some kind of PCIe error, and kdump can end up leaving the root filesystem in an unbootable state. For this reason, until the problem is fixed, or at least isolated to certain hardware enough to be avoided, the doorbell reset should not be used at all. Signed-off-by: Stephen M. Cameron Signed-off-by: Jens Axboe

Merge branch 'for-2.6.36' of git://git.kernel.dk/linux-2.6-block

2010-08-10T22:22:42+00:00

* 'for-2.6.36' of git://git.kernel.dk/linux-2.6-block: (149 commits) block: make sure that REQ_* types are seen even with CONFIG_BLOCK=n xen-blkfront: fix missing out label blkdev: fix blkdev_issue_zeroout return value block: update request stacking methods to support discards block: fix missing export of blk_types.h writeback: fix bad _bh spinlock nesting drbd: revert "delay probes", feature is being re-implemented differently drbd: Initialize all members of sync_conf to their defaults [Bugz 315] drbd: Disable delay probes for the upcomming release writeback: cleanup bdi_register writeback: add new tracepoints writeback: remove unnecessary init_timer call writeback: optimize periodic bdi thread wakeups writeback: prevent unnecessary bdi threads wakeups writeback: move bdi threads exiting logic to the forker thread writeback: restructure bdi forker loop a little writeback: move last_active to bdi writeback: do not remove bdi from bdi_list writeback: simplify bdi code a little writeback: do not lose wake-ups in bdi threads ... Fixed up pretty trivial conflicts in drivers/block/virtio_blk.c and drivers/scsi/scsi_error.c as per Jens.

cciss: cleanup interrupt_not_for_us

2010-08-07T16:52:30+00:00

cciss: cleanup interrupt_not_for_us In the case of MSI/MSIX interrutps, we don't need to check if the interrupt is for us, and in the case of the intx interrupt handler, when checking if the interrupt is for us, we don't need to check if we're using MSI/MSIX, we know we're not. Signed-off-by: Stephen M. Cameron Signed-off-by: Jens Axboe

cciss: change printks to dev_warn, etc.

2010-08-07T16:52:30+00:00

cciss: change printks to dev_warn, etc. Signed-off-by: Stephen M. Cameron Signed-off-by: Jens Axboe

cciss: separate cmd_alloc() and cmd_special_alloc()

2010-08-07T16:52:30+00:00

cciss: separate cmd_alloc() and cmd_special_alloc() cmd_alloc() took a parameter which caused it to either allocate from a pre-allocated pool, or allocate using pci_alloc_consistent. This parameter is always known at compile time, so this would be better handled by breaking the function into two functions and differentiating the cases by function names. Same goes for cmd_free(). Signed-off-by: Stephen M. Cameron Signed-off-by: Jens Axboe

cciss: use consistent variable names

2010-08-07T16:52:30+00:00

cciss: use consistent variable names "h", for the hba structure and "c" for the command structures. and get rid of trivial CCISS_LOCK macro. Signed-off-by: Stephen M. Cameron Signed-off-by: Jens Axboe

cciss: forbid hard reset of 640x boards

2010-08-07T16:52:30+00:00

cciss: forbid hard reset of 640x boards The 6402/6404 are two PCI devices -- two Smart Array controllers -- that fit into one slot. It is possible to reset them independently, however, they share a battery backed cache module. One of the pair controls the cache and the 2nd one access the cache through the first one. If you reset the one controlling the cache, the other one will not be a happy camper. So we just forbid resetting this conjoined mess. Signed-off-by: Stephen M. Cameron Signed-off-by: Jens Axboe

cciss: sanitize max commands

2010-08-07T16:52:30+00:00

cciss: sanitize max commands Some controllers might try to tell us they support 0 commands in performant mode. This is a lie told by buggy firmware. We have to be wary of this lest we try to allocate a negative number of command blocks, which will be treated as unsigned, and get an out of memory condition. Signed-off-by: Stephen M. Cameron Signed-off-by: Jens Axboe