Table of Contents

hpacucli or ssacli, depending on the driver version are used interchangeably such that when hpacucli is mentioned on this page, hpacucli can be substituted for ssacli.

Getting Back Control over Hardware Registers on Linux

The symptoms are to be observed on kernels above 3.6 that may report the following: 

[Firmware Bug]: the BIOS has corrupted hw-PMU resources (MSR 38d is 330)

this is caused by the HP BIOS using hardware performance monitoring built into the firmware that Linux is attempting to access as well.

To grant Linux access to the registers, you have to press F9 after rebooting the server and hearing the POST audible beep. Once in the setup utility, press Ctrl+Alt in order to bring up the Service Menu and follow the sub-menus to disable hardware performance counters: Service Options → Processor Power and Utilization Monitoring → Disable

LUKS and SATA Drives

When running cryptsetup to setup a LUKS encrypted drive on a HP SmartArray that is filled with SATA drives instead of SAS, then regardless of the filesystem (although XFS seems to make the problem manifest more often), you might get errors such as: 

[12570.106019] INFO: task kworker/u65:0:29268 blocked for more than 120 seconds.
[12570.106020]       Tainted: G          I     3.12.0-1-amd64 #1 Debian 3.12.6-1
[12570.106020] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[12570.106021] kworker/u65:0   D    0 29268      2 0x00000000
[12570.106024] Workqueue: writeback wb_workfn (flush-254:8)
[12570.106026] Call Trace:
[12570.106027]  ? __schedule+0x3c5/0x850
[12570.106029]  ? schedule+0x32/0x80
[12570.106030]  ? io_schedule+0x12/0x40
...

when files are being written to the RAID array. Most likely, this is due to the slowness of SATA drives vs. SAS drives along with the extra overhead from the encryption.

The issue seems to be resolved by turning on drive write caching on the controller using the hpacucli tool: 

hpacucli controller slot=5 modify drivewritecache=enable

where:

Unfortunately, the clear drawback is that by enabling the drive write cache, on a system that is not UPS backed, will make the controller pass the data to the individual physical drives' caches such that if a power failure occurs, then the data in the drives' caches will be lost - note that the drive write cache setting relates to the individual physical drives' caches and not the battery-backed SmartArray RAID controller cache.

Installing a License Key

Installing a license key can either be done via rebooting the machine and entering the RAID controller setup utility, from the SmartArray management webpage in case the HP vendor software is installed or via hpacucli.

To install a SmartArray license key on Linux using hpacucli, first issue: 

hpacucli controller slot=5 lk all show

where:

to show all installed keys.

Next, issue: 

hpacucli controller slot=5 add licensekey=XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

where:

Unfortunately, a lot of controllers have reached their end of life and even purchasing the "Smart Array Advanced Pack" is next to impossible. In such cases a Google search for HPiLOKeyGenv3.zip may yield good results.

Migrating RAID Level

To migrate to a different RAID level, say, from RAID 5 to RAID 6, the general procedure consists in:

  1. adding a physical drive to suit the target RAID level (in this case, RAID 6)
  2. using hpacucli to add the newly inserted drive to the current RAID array; at this point, the current RAID will be rebuilt
  3. converting to the target RAID level using hpacucli

To convert from RAID 5 to RAID 6, first set the RAID rebuild priority to high to speed up the process: 

hpacucli ctrl slot=1 modify rebuildpriority=high

where:

Then add all the newly inserted (and yet unassigned) disks to the RAID array: 

hpacucli ctrl slot=1 logicaldrive 1 add drives=allunassigned

where:

At this point, the RAID array will synchronize - you can watch the process by issuing: 

hpacucli ctrl slot=1 show config detail

and locating: 

Status: Transforming, 2% complete
Parity Initialization Status: In Progress

Note that this may take a long while. After the process has completed, issue: 

hpacucli ctrl slot=1 logicaldrive 1 modify raid=6

where:

which should migrate the RAID array from level 5 to level 6.

Increase Array Size for Underlying Operating System

When new drives are physically added to the array, the array can be extended with the extra added drives by issuing: 

hpacucli ctrl slot=1 logicaldrive 1 add drives=allunassigned

However, just extending the array will not modify the size of the underlying logical drive and the operating system will still report the old size. To extend the logical drive issue: 

hpacucli ctrl slot=1 logicaldrive 1 modify size=max

In both cases the commands operate on the RAID controller in slot 1 (the first slot) and set parameters for the first logical drive 1.

Note that setting the size of the logical drive cannot be performed whilst the controller is busy extending the array (as per the first command).

Correlating S.M.A.R.T. Output to Physical HP SmartArray Drives

Drives connected to a SmartArray controller are handled either by the older cciss or the newer hpsa driver. Polling for S.M.A.R.T. parameters in either case can be done by issuing: 

smartctl -a -d cciss,N /dev/DRIVER

where:

Note that the cciss parameter to -d applies for both cciss and hpsa drivers.

Whilst the N parameter for the smartctl command is a zero-based index, hpacucli (or, newer ssacli) as well as the chassis indicators are not zero-based indices and start from 1.

Even though the smartctl command with the N parameter should be incremental such that the -d cciss,0 will correspond to the first drive, -d cciss,1 will correspond to the second drive, etc. however in order to make sure that the drive queried by smartctl corresponds to the physicial drive in the chassis, smartctl can be issued in inquire mode: 

smartctl -i -d cciss,N /dev/DEVICE

and the serial number can be compared to the one shown by the output of the command: 

ssacli ctrl slot=SLOT show config detail

where: