HP Smart Array CCISS driver


  • Downloads
  • News
  • All Downloads
  • About Source RPMs
  • About Source DEBs
  • About Source tarballs
  • binary drivers from hp.com
  • HW/FW Documentation
  • cciss utilities
  • Supported Hardware
  • Contact
  • Recent kernel mailing list traffic related to "cciss"
  • Recent kernel mailing list traffic related to "hpsa"
  • HP.com
  • PMCS.com
  • Kernel.org
  • Here you will find source RPMs and source tarballs for the cciss driver for HP's Smart Array line of hardware RAID controllers. Most likely, you do not need these, as the cciss driver has been in the Linux kernel for a very long time, and most distributions will already have a cciss driver which will work for you as is.

    From time to time there may be instances in which hardware or driver features are not supported by the cciss driver which comes with your distribution or kernel, because it is too old, or the hardware is too new, etc. In these instances you may wish to try the source RPMs or tarballs provided here.

    If you are looking for binary RPMs or driver diskette images

    We do not supply any binary RPMs from this page. HP does supply binary RPMs and driver diskettes (for loading drivers during OS installation) for supported Linux distributions on hp.com. See these search results from hp.com. You can use these if you have a supported distribution running a supported kernel.


    News

    *New* PMC Licenses HP Smart Array Intellectual Property to Accelerate Growth in Server Storage Solutions

    *New* The cciss driver has been removed from RHEL7 and SLES12. If you really want cciss on RHEL7 checkout the elrepo directory.

    A new Smart Array driver called "hpsa" has been accepted into the main line linux kernel as of Dec 18, 2009, in linux-2.6.33-rc1. This new driver will support new Smart Array products going forward, and the cciss driver will eventually be deprecated. Initially, there was some overlap in the boards which these two drivers support.

    The current list of supported controllers for hpsa:

      Gen6/7 Controllers
    • Smart Array P212
    • Smart Array P410
    • Smart Array P410i
    • Smart Array P411
    • Smart Array P812
    • Smart Array P712m
    • Smart Array P711m
      Gen8 Controllers
    • Smart Array P222
    • Smart Array P420
    • Smart Array P420i
    • Smart Array P421
    • Smart Array P822
    • Smart Array P220i
    • Smart Array P721
      Gen8.5 Controllers
    • Smart Array P430
    • Smart Array P430i
    • Smart Array P431
    • Smart Array P830
    • Smart Array P830i
    • Smart Array P831
    • Smart Array P731m
    • Smart Array P230i
    • Smart Array P530
    • Smart Array P531
      Gen9 Controllers
    • Smart Array P440
    • Smart Array P441
    • Smart Array P840
    • Smart Array P440ar
    • Smart Array P244br
    • Smart HBA H240
    • Smart HBA H241
    • Smart HBA H240ar
    • Smart HBA H244br
      Storage Appliance Controllers
    • HP StorageWorks 1210m
    • HP Storage P1224 Array Controller
    • HP Storage P1228 Array Controller
    • HP Storage P1228m Array Controller
    • HP Storage P1224e Array Controller
    • HP Storage P1228e Array Controller
    • HP Storage P1228em Array Controller

    Some development versions (2.6.33-rc1 up to 2.6.36-ish) of the linux kernel (as of Jan 8, 2009) on kernel.org have cciss and hpsa drivers which currently both support some Smart Array controllers. That is, there are some kernels which have overlapping sets of controllers supported by both hpsa and cciss. The intent with newer kernels (2.6.36-ish) is to remove this overlap so the sets of controllers supported by hpsa and cciss are disjoint.

    The current list of controllers that are supported by cciss only:

    • Smart Array 5300
    • Smart Array 5312
    • Smart Array 532
    • Smart Array 5i
    • Smart Array 6400
    • Smart Array 6400 EM
    • Smart Array 641
    • Smart Array 642
    • Smart Array 6422
    • Smart Array 6i
    • Smart Array E200
    • Smart Array E200i
    • Smart Array E500
    • Smart Array P600
    • Smart Array P400
    • Smart Array P400i
    • Smart Array P700m
    • Smart Array P800

    The following list of controllers are supported by cciss on distributions based on kernels before 2.6.33:

    • Smart Array P212
    • Smart Array P410
    • Smart Array P410i
    • Smart Array P411
    • Smart Array P812
    • Smart Array P712m
    • Smart Array P711m
    • Smart Array P222
    • Smart Array P420
    • Smart Array P420i
    • Smart Array P421
    • Smart Array P822
    • Smart Array P220i
    • Smart Array P721
    • Smart Array P430
    • Smart Array P430i
    • Smart Array P431
    • Smart Array P830
    • Smart Array P830i
    • Smart Array P831
    • Smart Array P731m
    • Smart Array P230i

    In the case of kernels with cciss and hpsa drivers which do have overlapping sets of supported controllers, by default, cciss will claim these devices if it is loaded prior to hpsa (which it normally will be). If you're already running cciss on these devices, and upgrade to a kernel containing the hpsa driver, you shouldn't have to do anything, as cciss will continue to claim these devices. If you would like to run hpsa instead, there is a new module parameter to cciss, "cciss.cciss_allow_hpsa=1", which will cause the cciss driver to ignore the controllers on the above list, which will permit the hpsa driver to claim those devices. NOTE: The hpsa driver is a SCSI driver, while the cciss driver is a block driver. This means that logical drives which would be presented with devices nodes like "/dev/cciss/c0d0", etc. will now be presented as "/dev/sda", etc.

    This means that if you are currently using cciss with the above controllers and decide to switch to hpsa, you've got to adjust your /etc/fstab, grub configuration files, etc. to make this work. For a new install of a distribution using the hpsa driver, the "cciss.cciss_allow_any=1" boot parameter should allow hpsa to be used easily. If you've been using cciss already on these controllers, it is not recommended that you attempt to upgrade your running system to switch from cciss to hpsa unless you have a very good reason to do so and know what you are doing. This is simply because making the switch is somewhat complex and it is easy to make a mistake or forget something and get your system into an unbootable state. With all the various distributions, it is difficult to come up with a set of bulletproof universal instructions for making such a switch, so we recommend that you simply continue to use cciss in such instances.

    Hpsa should be fine for new installs on these controllers, however.

    The cciss driver previously contained a feature which would enable it by default to run on Smart Array controllers which it did not explicitly recognize except so far as to be able to determine that they were some sort of Smart Array. This feature has been removed, as any Smart Arrays not known to cciss are now presumed to be claimed by the hpsa driver. The hpsa driver has the ability to claim unknown Smart Arrays, however this is turned off by default so that it does not try to claim older controllers meant to be claimed by the cciss driver. To enable this feature of hpsa, the module parameter hpsa.hpsa_allow_any=1 can be used.

    The usual HP utilities, ACU, the SNMP storage agents, and cciss_vol_status should also work with hpsa. There may be other software designed to work with cciss (e.g. Arrayprobe) which may need modifications to work with the hpsa driver.

    The hpsa driver is available in the kernel.org kernels, and in RHEL6 by default, and in SLES11 (but not by default).


    Source RPMs:

    You may try to use these to build a binary RPM.

    To install, download the RPM file, and use

    rpm -ihv rpmfile

    This will deposit the cciss.spec file in /usr/src/redhat/SPECS, for instance on Redhat's distribution. (Your distribution may differ.) Change to this directory, and execute:

    	cd /usr/src/redhat/SPECS
    	rpmbuild -bb cciss.spec
    

    This will create the binary RPM in, for instance, /usr/src/redhat/RPMS/`arch` directory. (Your distribution may differ.) This binary RPM may then be installed in the usual way, for instance:

    	rpm -ihv cpq_cciss-2.6.14-7.ia64.rpm
    

    Note: The binary RPMs produced by the source RPMs here are a greatly simplified version of the binary RPMs distributed by HP. The binary RPMs distributed by HP do many things like modifying grub configuration files or lilo.conf as needed, modifying /etc/modules.conf, etc. The binary RPMs created by the source RPMs here do not do these things, they only build the driver module and initrd image. It is up to you to make any changes to your grub or lilo configuration files and /etc/modules.conf (or modprobe.conf) files as needed.

    Oct 4, 2007: Note: There has been a report that sometimes the OS supplied /sbin/mkinitrd script used by the RPM will get the wrong cciss.*.ko file out of /lib/modules/`uname -r`/kernel/drivers/block and put it in the initrd image. So far, I haven't had any luck duplicating this problem.


    Source DEBs:

    Debian source package copies cciss files to /var/hp/storage/cciss directory and builds cciss module against installed kernel's source. It is required to have kernel source code available at /usr/src/linux-x.x.xx. If necessary, deb package will compile kernel as well.

    To install, download Debian cciss source package (.deb file) and issue following command

    prompt>dpkg -i hpcciss-src-x_x_xx.deb

    This will copy cciss source files to /var/hp/storage/cciss directory and build cciss module binary against installed kernel. Newly built cciss driver will be placed under /var/hp/storage/cciss, if build is successful.

    Note: Debian package is greatly simplified. It neither modifies bootloader (grub or lilo.conf) configuration files, nor modify /etc/modules.conf, nor build initrd. Debian package only builds binary cciss module. It is up to the user to make any changes to bootloader configuration files, /etc/modules.conf (or modprobe.conf) files and initrd as needed.


    Source tarballs:

    NOTICE: the source tarballs do not create a single parent directory, so it is up to you do so yourself.

    To build the source tarballs:

    1. Create a directory and unpack the tarball.
      	[scameron@quandary somedir]$ mkdir cciss-3.6.14
      	[scameron@quandary somedir]$ cd cciss-3.6.14
      	[scameron@quandary cciss-3.6.14]$ tar xzvf ../cciss-3.6.14.tar.gz
      	configure
      	Documentation/
      	Documentation/mkdev.cciss
      	Documentation/cciss.txt
      	Documentation/rmdev_dyn.cciss
      	Documentation/mkdev_dyn.cciss
      	drivers/
      	drivers/block/
      	drivers/block/cciss_cmd.h
      	drivers/block/cciss.h
      	drivers/block/cciss_scsi.c
      	drivers/block/cciss.c
      	drivers/block/cciss_scsi.h
      	drivers/block/Makefile
      	include/
      	include/linux/
      	include/linux/cciss_ioctl.h
      	INSTALL
      -->	MAKEFILE
      	Makefile_redhat
      	Makefile_suse
      -->	README
      	RELEASE
      	UNINSTALL
      
      The source tarballs are copies of what is used by the source RPMs. In fact, you could extract the source tarballs from the source RPMs by using rpm2cpio.
    2. Read the README file for information about how the tarball is used in the source RPM.
    3. Read MAKEFILE1 for further instructions on building the driver from the tarball without any involvement of RPMs.

      1Yes, I know MAKEFILE is traditionally one of the names of files that the make command usually reads. In this case, it is just a text file, documentation, meant for human consumption.


    Downloads

    HPSA 3.0 tarballs
    Last updated September 17, 2014, latest version is 3.4.6-170
    CCISS 4.6 tarballs
    CCISS 4.6 source rpms
    CCISS 4.6 source deb
    Last updated March 4, 2013 latest version is 4.6.28-22 These are meant for 2.6.26 or later kernels (typically, SUSE SLES11, etc.)
    CCISS 3.6 source RPMs
    CCISS 3.6 source tarballs
    CCISS 3.6 kdump source RPMs
    CCISS 3.6 kdump source tarballs
    Use these for systems using 2.6 kernels later than about 2.6.15. From 2.6.11 to 2.6.15 is kind of a gray area during which some kernel interfaces the driver relies upon were in flux.
    Last updated March 4, 2013 latest version is 3.6.28-22

    Changes since 3.6.28-6:

    • Updates for kdump support

    Changes since 3.6.20-20:

    • TBD.

    Changes since 3.6.20-16:

    • TBD.

    Changes since 3.6.18-17:

    • Fixed bug where deleting logical volumes could hang the system.
    • Fixed a memory leak in rebuild_lun_table code.
    • Fixed a panic that could arise during an insmod and rmmod of the cciss driver.
    • Fix procfs regression. This patch will get called only once for each controller. The earlier fix would be called anytime something changed.
    • Fixed wrong usage of a pointer for sysfs symlink.
    • Fix firmware version not being printed in procfs.
    • Fixed sysfs link issue.
    • Added check_unit_attention() to catch UA's on MSA2000. The function prints a message then retries the command that returned with a unit attention.
    • Fixed a bug found by the L1 test suite. The system would panic when deleting many logical volumes at one time.
    • Removed unneeded lock in sysfs code.
    • Updated rebuild_lun_table to avoid pulling a logical volume out from under acuxe or hpacucli.
    • Cleaned up code for adding and removing logical volumes.
    • Mkinitrd has changed on rhel5u1 and higher systems. It can no longer find the rhel5 base media cciss driver following an uninstalled of an HP cciss rpm. Without this fix the system will panic on reboot when the HP cciss rpm has been uninstalled.
    • Fixed race condition that could show up during driver init.
    • Fixed "out of memory" error introduced in the 2.6.20-4 aand 3.6.20-4 drivers
    • Added 1024 lun support. OS distros with warnings.
    • Added a procfs interface so users can tell the driver to rescan our devices. Needed for MSA2012 support since MSA2012 does not report configuration changes back to the driver.
    • Added dynamic outstanding command turning on a per controller basis.
    CCISS 2.6 source RPMs
    CCISS 2.6 source tarballs
    Use these for 2.6 kernel up to about 2.6.11. RHEL 4.x and SLES 9.x are examples of systems based upon such kernels. From kernels 2.6.11 to 2.6.15 is kind of a gray area during which some kernel interfaces the driver relies upon were in flux.
    Last updated Tue Oct 16, 2009 latest version is 2.6.20-23

    Changes since 2.6.20-16

    • TBD.

    Changes since 2.6.18-16

    • Fixed bug where deleting logical volumes could hang the system.
    • Fixed issue where ACU would hang after several operations.
    • Fixed a panic that could arise during an insmod and rmmod of the cciss driver.
    • Changed kzalloc back to kmalloc + memset to continue support for older OS version.
    • Fix procfs regression. This patch will get called only once for each controller. The earlier fix would be called anytime something changed.
    • Fixed wrong usage of a pointer for sysfs symlink.
    • Fix firmware version not being printed in procfs.
    • Fixed issue where controllers that had no configured volumes did not show up in the OS.
    • Fixed sysfs link issue.
    • Added check_unit_attention() to catch UA's on MSA2000. The function prints a message then retries the command that returned with a unit attention.
    • Updated rebuild_lun_table to avoid pulling a logical volume out from under acuxe or hpacucli.
    • Cleaned up code for adding and removing logical volumes.
    • Fixed race condition that could show up during driver init.
    • Fixed "out of memory" error introduced in the 2.6.20-4 aand 3.6.20-4 drivers
    • Added 1024 lun support.
    • Added dynamic outstanding command turning on a per controller basis.
    CCISS 2.4 source RPMs
    CCISS_2.4 source tarballs
    Use these for 2.4 based kernels, such as RHEL 3.x, SLES 8 or (SuSE) United Linux 1.0. These won't work with very old kernels such as the 2.4.7 series used by SLES 7.0, etc.

    BTW, if you happen across a 2.6.12 version of the cciss driver, or patches to bring the driver up to 2.6.12, don't use them as this version will hang. (You'll find out soon enough if you do try to use it.) There are newer versions. Use those instead.


    Hardware/Firmware Documentation


    CCISS Utilities

    • cciss_vol_status May 24, 2013: New release: v. 1.11. -- a very lightweight program to report the status of logical drives on Smart Array controllers and also fibre channel attached MSA1000. Changes since 1.10: Support for new Smart Array controllers was added and added the ability to report status of non-volatile cache. No longer spins up idle spare drives. Should work on most any linux and FreeBSD (no MSA1000 support for FreeBSD though. Martin Matuska added cciss_vol_status to the FreeBSD ports tree here. Here's what it would take to get MSA1000 support on FreeBSD Feel free to send in a patch.)

      Here's the man page.. This program is licensed under the Gnu GPL v. 2.

    • Arrayprobe (offsite) makes a report of events recorded by Smartarray contollers. Here's a sample report from arrayprobe 2.0.
    • Cpqarrayd: (offsite) "Cpqarrayd is a daemon to monitor HP (compaq) arraycontrollers. It reports any status changes, like failing disks, to the syslog and optionally to a remote host using SNMP traps." This program works by monitoring events from Smartarray controllers, originally written for first generation Compaq array controllers, (those which use the cpqarray driver) but extended to also work with 2nd generation controllers (those which use the cciss driver.) Logs to syslog, and optionally, sends SNMP traps. You can think of this as a daemonized version of arrayprobe, in that both of them detect failures in the same way (by looking at "events" reported by the controller, cpqarrayd in real time, arrayprobe after the fact.)
    • smartmontools -- described on the smartmontools website as "two utility programs (smartctl and smartd) to control and monitor storage systems using the Self-Monitoring, Analysis and Reporting Technology System (SMART) built into most modern ATA and SCSI hard disks."
    • array-info I just found this one, Fri Jun 1 22:29:47 PDT 2007. I can't comment on this much as I haven't tried it, but from my so far very brief perusing of the code it appears to be alright at first glance, basically doing the expected things. (Interestingly, it predates cciss_vol_status, so the authors are to be congratulated for figuring out how to do it despite extremely sketchy to non-existent documentation.) Later, after checking this one out a bit more, I'll edit this to reflect what I find.

    Supported Hardware

    • Smart Array 5300
    • Smart Array 5312
    • Smart Array 532
    • Smart Array 5i
    • Smart Array 6400
    • Smart Array 6400 EM
    • Smart Array 641
    • Smart Array 642
    • Smart Array 6422
    • Smart Array 6i
    • Smart Array E200
    • Smart Array E200i
    • Smart Array E500
    • Smart Array P600
    • Smart Array P400
    • Smart Array P800
    • Smart Array P700m
    • Smart Array P400i
    • Smart Array P212
    • Smart Array P410
    • Smart Array P410i
    • Smart Array P411
    • Smart Array P812
    • Smart Array P712m
    • Smart Array P711m
    • MSA 500 G2
    • MSA 20
    • Smart Array P222
    • Smart Array P420
    • Smart Array P421
    • Smart Array P822
    • Smart Array P420i
    • Smart Array P220i
    • Smart Array P721
    • Smart Array P430i
    • Smart Array P830i
    • Smart Array P430
    • Smart Array P431
    • Smart Array P830
    • Smart Array P831
    • Smart Array P731m
    • Smart Array P230i
    • Smart Array P531
    • Smart Array P530
    • Smart Array P440
    • Smart Array P441
    • Smart Array P840
    • Smart Array P440ar
    • Smart Array P244br
    • Smart HBA H240
    • Smart HBA H241
    • Smart HBA H240ar
    • Smart HBA H244br
    • HP StorageWorks 1210m
    • HP Storage P1224 Array Controller
    • HP Storage P1228 Array Controller
    • HP Storage P1228m Array Controller
    • HP Storage P1224e Array Controller
    • HP Storage P1228e Array Controller
    • HP Storage P1228em Array Controller

    Contact: