The Solaris Fault Manager tracks software, hardware and specific device problems by identifying error telemetry information that indicate a specific symptom in an error log and then reporting actual fault diagnosis when the error symptom results in an actual fault.
The following command identifies any software or hardware related fault.
# fmadm faulty
Use the above command routinely to identify failed services or devices.
Use the following command routinely to identify hardware or device related errors.
# fmdump -eV | more
Error messages in this log file that describe vdev.open_failed, checksum, or io_failure issues need your attention or they might evolve into actual faults that are displayed with the fmadm faulty command.
If the above indicates that a device is failing, then this is a good time to make sure you have a replacement device available.
You can also track additional device errors by using iostat command. Use the following syntax to identify a summary of error statistics.
# iostat -en ---- errors --- s/w h/w trn tot device 0 0 0 0 c0t5000C500335F95E3d0 0 0 0 0 c0t5000C500335FC3E7d0 0 0 0 0 c0t5000C500335BA8C3d0 0 12 0 12 c2t0d0 0 0 0 0 c0t5000C500335E106Bd0 0 0 0 0 c0t50015179594B6F11d0 0 0 0 0 c0t5000C500335DC60Fd0 0 0 0 0 c0t5000C500335F907Fd0 0 0 0 0 c0t5000C500335BD117d0
In the above output, errors are reported on an internal disk c2t0d0. Use the following syntax to display more detailed device errors.
Persistent SCSI transport errors that refer to retries or resets can be caused by down-rev firmware, a bad disk, a bad cable, or a faulty hardware connection. Some transient transport errors can be resolved by upgrading your HBA or device firmware. If transport errors persist after firmware is updated and all devices are deemed operational, then look for a bad cable or other faulty connection between hardware components.