HP A3550A - High Availability Disk Arrays Model 20 Storage Enclosure User Manual page 306

Table 6-14 Most Common Microcode Panic Codes (Continued)
Value Description
0x00220056 I/O panic. The microcode would occasionally panic during a rebuild if another disk
faulted during a write operation.
The following was a cause of this panic:
– A large write requests (larger than 0x200 sectors) is received by the microcode
and broken into multiple parts.
– Due to lack of resources (a busy system) the parts are placed on a waiting queue.
– Some other request completes, but does not free the specific resources the
waiting requests need.
– The microcode de-queues the first event on the waiting queue in an attempt to
restart it. But since the resources it needs are still not available, it can not be
started. The microcode then places the event back on the waiting queue.
– At some point in the future, the microcode attempts to start the next event on the
waiting queue, which is now the second part of the request. This causes the
0x00220056 panic because the first part of the request has not yet been executed.
Another instance can be induced by write only I/O while the Battery Test was
active. This has only been seen on RAID-3 LUNs. Fixed in microcode revision
9.x5.
If this panic occurs with the latest revision of microcode, obtain the Unsolicited Event
Logs from both SPs and the memory dump disk and give them to your Hewlett-
Packard service representative.
0x00220060 Miscellaneous panic. The microcode might panic with a 0x00220060 under
excessive trespass activity coupled with heavy I/O traffic. Fixed in microcode
revisions 8.26, 8.58, and 9.04.
0x00220064 Firmware resources exhausted. Under extremely heavy I/O conditions with one or
more rebuilds or equalizers in process, the microcode would intermittently panic.
Usually this was a result of one or more firmware resources being exhausted
because the array was managing a heavy workload.
The following causes of the 0x00220064 panics have also been fixed:
– Binding more than 12 LUNs concurrently or binding during extremely heavy
I/O.
– The microcode would issue a large number of resets due to a hung backend bus
while I/O was still active on the remaining backend buses causing timeouts to
occur.
– The microcode has been made more robust in dealing with the shutdown and
release of LUNs in support of unit trespass.
– The microcode has been coded to eliminate internal resource deadlocks between
SNiiFFER and normal I/O operations.
– Resource starvation caused by heavy I/O operations during rebuilds. All known
occurrences of this panic have been fixed in microcode revisions 9.x4 and later.
If this panic occurs obtain a memory dump and Unsolicited Event Logs from both
SPs and give them to your Hewlett-Packard service representative for failure
analysis.
6-58 Unsolicited Event Log