HP 3PAR OS 3.1.2 MU5 Release Notes

DescriptionItemIssue ID
The only impact this has is the suspension of periodic resyncs for the
duration of the online upgrade.
After a soft reset of the DCN1 cage's controllers, we noticed the
following events being generated.
eventlog: Critical Cluster thermal
shutdown seen during soft reset of
DCN1 cages
81222
2012-10-26 09:27:41 PDT 0 Critical Cluster thermal
shutdown hw_node:0 Node 0
We have not noticed any issues caused by the generation of this
event.
A volume that has been thinly imported via Peer Motion or converted
to a thin volume using online conversion will not have the zero detect
A Newly Converted/Imported TPVV
should have Zero Detect on by
Default
81383
policy set by default. This does not affect the conversion process,
which will perform zero detection correctly. The work around for this
is to manually set the zero detect policy after the import or conversion
has completed.
In an RC setup with periodic sync, it is possible for the HP 3PAR OS
to hit the limit of VV objects that can be created. When that happens,
the periodic sync may not complete and the sync cycle may be missed.
System jammed with max limit of
VV objects when running RC...
81507
SP-4.1.0.-60: The simple upgrade
from 3.1.1 + Patches to 3.1.2
wasn't successful
81667
Due to an inconsistency in how PCI slot information is returned,
checkhealth may display incorrect information about PCI cards
being incorrectly matched between nodes.
Check Health sometimes incorrectly
reports matching empty slots
81772
(also
75517)
Example of erroneous output:
Checking node Component
----------------Description----------------- Qty
Node PCI card model differs for slot in node pair
2 Component -Identifier-
----------------------Description----------------------
Node node:0 PCI card in Slot:4 is empty, but is
not empty in Node:1 Node node:1 PCI card in Slot:4
is empty, but is not empty in Node:0
Certain IO requests issued by HP-UX 11i v2 hosts have strict timeouts
associated with them. If the HP 3PAR array to which the host is issuing
IO timeout with HP-UX 11i v283492
IOs experiences a node reboot, the outstanding IOs may experience
stalls while the node recovers. If the stall exceeds the timeouts, IOs
can be marked as failed. This is a temporary condition. If the IO
requests are tried again after the node recovery, they will succeed.
HP recommends that a supported multipathing solution be installed
and configured on the HP-UX 11i v2 host. This will automatically retry
the IOs that timeout.
Persistent Ports Limitations
The goal of the persistent ports feature is to quickly transfer the WWN of one Inserv HBA port to
another. Done quickly enough, the host multipathing software should not mark any paths as
offline/unusable. However, with the current 3.1.2 release, the transition is sometimes not quick
enough. The result is that, in some scenarios, the host multipathing software does notice the
transition. In addition, in one scenario, the transition is actually too fast for the host to handle it
correctly.
The following scenarios have been observed during testing:
• SLES11.1 Host with Device Mapper Multipathing
Periodically, there will be multipath errors during failover or failback. These errors describe
devices going offline and within seconds the devices are back on line. This is an intermittent
issue seen about 10% of the time.
Known Issues with the OS 17