Fabric OS Troubleshooting and Diagnostics Guide v7.0.0 (53-1002150-02, June 2011)

Fabric OS Troubleshooting and Diagnostics Guide 13
53-1002150-02
Switch boot
2
Symptom MQ errors are appearing in the switch log.
Probable cause and recommended action
An MQ error is a message queue error. Identify an MQ error message by looking for the two letters
MQ followed by a number in the error message:
2004/08/24-10:04:42, [MQ-1004], 218,, ERROR, ras007, mqRead, queue =
raslog-test- string0123456-raslog, queue I
D = 1, type = 2
MQ errors can result in devices dropping from the switch’s Name Server or can prevent a switch
from joining the fabric. MQ errors are rare and difficult to troubleshoot; resolve them by working
with the switch supplier. When encountering an MQ error, issue the supportSave command to
capture debug information about the switch; then, forward the supportSave data to the switch
supplier for further investigation.
Symptom I
2
C bus errors are appearing in the switch log.
Probable cause and recommended action
I
2
C bus errors generally indicate defective hardware or poorly seated devices or blades; the specific
item is listed in the error message. Refer to the Fabric OS Message Reference for information
specific to the error that was received. Some Chip-Port (CPT) and Environmental Monitor (EM)
messages contain I
2
C-related information.
If the I
2
C message does not indicate the specific hardware that may be failing, begin debugging the
hardware, as this is the most likely cause. The next sections provide procedures for debugging the
hardware.
Symptom Core file or FFDC warning messages appear on the serial console or in the system log.
Probable cause and recommended action
Issue the supportSave command. The messages can be dismissed by issuing the supportSave -R
command after all data is confirmed to be collected properly.
Error example:
*** CORE FILES WARNING (10/22/08 - 05:00:01 ) ***
3416 KBytes in 1 file(s)
use "supportsave" command to upload
Switch boot
Symptom The enterprise-class platform model rebooted again after an initial bootup.
Probable cause and recommended action
This issue can occur during an enterprise-class platform boot up with two CPs. If any failure occurs
on active CP, before the standby CP is fully functional and has obtained HA sync, the Standby CP
may not be able to take on the active role to perform failover successfully.
In this case, both CPs reboot to recover from the failure.