HP A3550A User Manual - A3661-90001 - Page 306

Table 6-14 Most Common Microcode Panic Codes (Continued) Value Description 0x00220056 0x00220060 0x00220064 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 HewlettPackard service representative. 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. 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