Corrective Action: Failure On Ldev 350 And 351; Corrective Action: Timeout/No Reply For Ldev 451 - HP e3000 MPE/iX Manual

Appendix - A

Corrective Action: Failure on Ldev 350 and 351

As indicated by the primary path status for Ldev 350, it is possible that the array
controller has failed. This should be verified by your official support
representative and the system diagnosed to verify the actual broken component.
If it is the array controller, then in many cases, array controllers can be replaced
on-line with the host powered-up and array powered-up. (Note also that IF the
controller for path 0/4/0/0 is broken, then the Ldevs352 and 353 have no "fail
over" path.)
After the array controller has been replaced, the primary path should be re-
enabled for optimal system I/O performance and protection. Use SYSGEN >
IO > HA > GO 350 and GO 351 command to force Ldev 350 and 351's
device manager to try the primary path after online repairs.

Corrective Action: Timeout/No Reply for Ldev 451

As indicated by the primary path status for Ldev 451, a timeout value has been
exceeded for an I/O to this Ldev. It possible that a hardware error occurred OR
that too many I/Os are being generated for the array to handle within the time
frame that HAFO expects.
In the example, you can see that Ldev 450 and Ldev 451 share the same
primary I/O path. If there are I/Os being done to both devices and only one
shows an error, it is unlikely that there is a "hard" failure in any component of
the primary path.
This situation requires further troubleshooting. If it has been determined that
I/Os are timing out and the status is not generated because of some other
hardware problem, then one corrective action may be to disable the HAFO
timeout detection feature. You may disable timeouts by deleting the device from
the HAFOCONF file, then re-adding the device with the timeout flag set to
"false".
As documented in the " " command a system administrator should be
ADDCONF
cautious when disabling HAFO timeout checks. In this example, IF the disk
array is "slow" for Ldev 451, then likely it will cause HAFO timeouts for other
Ldevs (450, 452, 453) on this array in the future. As disk arrays may be shared
by several systems, it may be a complex issue to determine why the array is
"slow".
50