HP IO Accelerator Driver and Management Software Version 3.2.3 Release Notes

Errata 24
Kernels 2.6.34/35 don't handle switching interrupt types
Linux kernels around 2.6.34/35 might have problems processing interrupts if the driver is loaded using one
interrupt type, unloaded, and then loaded again using a different interrupt type. The primary symptom is that
the IO Accelerator device is unusable and the kernel logs have errors containing doIRQ. For example, the
following sequence on an affected system would likely result in errors:
1. Load the driver with a default of disable_msi=1 which selects APIC interrupts:
$ modprobe iomemory-vsl
$ modprobe -r iomemory-vsl
2. Load the driver and enable MSI interrupts:
$ modprobe iomemory-vsl disable_msi=0
To work around this issue, if you see the error, reboot the system. Also, always load with the same interrupt
type selected. To change between interrupt types, reboot the system first.
RHEL6 udevd warning
When using an IO Accelerator under RHEL6 (or any Linux distribution with udev script version 147 or later),
udevd might emit the following messages:
udevd[154]: worker [19174] unexpectedly returned with status 0x0100
udevd[154]: worker [19174] failed while handling
'/devices/virtual/block/fioa'
These messages are innocuous, and you can ignore them.
RHEL6 gives a warn_slowpath message during device attach
When attaching an IO Accelerator device under RHEL6, you might see log messages similar to the following:
kernel: ------------[ cut here ]------------
kernel: WARNING: at fs/fs-writeback.c:967 __mark_inode_dirty+0x108/0x160()
(Tainted: P ---------------- )
.
.
.
[<ffffffff8106b857>] warn_slowpath_common+0x87/0xc0
[<ffffffff8106b8aa>] warn_slowpath_null+0x1a/0x20
.
.
.
This is due to a bug in the 2.6.32 kernel, and the messages can safely be ignored.