Closed as fixed if next.
If a VIOS becomes unresponsive (VIOS appears to be hung), a reboot of the VIOS may be required to resolve. A VIO client will mark the paths to the VIOS as failed. However after a successful reboot of the VIOS, the client does not recover the failed paths, even with health check enabled and the disks in an opened state. The sequence of errors in the AIX client's error log should show a VSCSI_ERR2, followed some time later by SC_DISK_ERR7, and finally VSCSI_ERR1 after the VIOS is back up again: VSCSI_ERR2 - Underlying transport error (Error Number 002E in Detail Data) SC_DISK_ERR7 - path has failed VSCSI_ERR1 - Temporary VSCSI software error (Error Number 005B in Detail Data) However, the output of the "lspath" command still shows the paths in a Failed state. An inspection of the current status of the adapter from snap data collected shows the state of the adapter is VSCSI_LOGGED, but SRVR_IS_HALTED flag is set, h_dropped count is non-zero, and ping_tmo value is high.
Remove the affected vscsi adapter instance on the client, and reconfigure the adapter.
If a VIOS becomes unresponsive (appears to be hung), a reboot might be required to resolve it. Any client having VSCSI disks to the VIOS will mark paths a failed. But even after VIOS reboot, the client VSCSI paths may not recover.
This APAR is being closed FIN. This means that a solution to this APAR is expected to be delivered from IBM in a release (if any) to be available within the next 24 months.
Reported component name
Reported component ID
Last modified date
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Applicable component levels