Sun Storage 3510 FC Array
 
Sun Storage 3310 Array
 
Sun Storage 3511 SATA Array
 

GCS>Sun Microsystems>Sun Alert>Criteria Category>Availability
 
GCS>Sun Microsystems>Sun Alert>Release Phase>Resolved
 

Event hardware failure messages without a unique FRU identifier may result in the replacement of the wrong FRU on a Sun StorEdge 3310 SCSI or 3510/3511 FC array.

The serial number in the event messages is always the serial number of the primary controller regardless of which CPU has the fault. As a result, the good FRU that matches the serial number may incorrectly be replaced while the bad FRU remains in the system. If an event occurs on the bad controller at the time the good controller is being replaced, a full array outage is possible.

This issue can occur on the following platforms:

SPARC Platform

• Sun StorEdge 3310 SCSI Array without patch 113722-10
• Sun StorEdge 3510 FC Array without patch 113723-10
• Sun StorEdge 3511 FC Array without patch 113724-04

Example event messages:

    [0123] #298: StorEdge Array SN#26103 Peripheral Device ALERT: CPU high
temperature threshold exceeded ( 96.00C)
Mon Feb 14 12:45:31 2005 [01A3] #299: StorEdge Array SN#26103 Peripheral
Device NOTICE: CPU temperature high temperature now back to non-critical
level ( 92.00C)

Based upon the serial number, the primary controller was replaced. The above messages are from the primary controller AFTER the replacement, indicating that the wrong FRU was replaced. Aside from the serial number, there is no identifying FRU information contained in the message.

There is no workaround. Please see the "Resolution" section below.

This issue is addressed in the following releases:

SPARC Platform

• Sun StorEdge 3310 SCSI Array with patch 113722-10 or later
• Sun StorEdge 3510 FC Array with patch 113723-10 or later
• Sun StorEdge 3511 FC Array with patch 113724-04 or later

• Updated Contributing Factors and Resolution sections

14-Jun-2005:

• Updated Contributing Factors

• Updated Contributing Factors and Resolution sections

• State: Resolved
• Updated Contributing Factors and Resolution sections

References

The 4.11/2.0 release will fix this problem by providing the correct information for the controller at fault. The 4.11/2.0 will not include the serial number, but it will indicate primary or secondary controller.

Following is a sample of event logs that can be obtained through telnet:

    "Thu Mar  3 13:38:22 2005

     [Primary]       Alert

     Peripheral Device ALERT: CPU Hot Temperature Detected(60.0(C) )



     Thu Mar  3 13:39:16 2005

     [Primary]       Alert

     SES(C2 I12)Temp Sensor 4:Over Temperature Failure



     Thu Mar  3 13:39:16 2005

     [Primary]       Alert

     SES(C2 I12)Temp Sensor 5:Over Temperature Failure



     Thu Mar  3 13:39:30 2005

     [Secondary]     Alert

     Peripheral Device ALERT: CPU Hot Temperature Detected(60.0(C) )



     Thu Mar  3 13:40:15 2005

     [Primary]       Notification

     SES(C2 I12)Temp Sensor 4:Temperature Back To Non-Critical LVs



     Thu Mar  3 13:40:15 2005

     [Primary]       Notification

     SES(C2 I12)Temp Sensor 5:Temperature Back To Non-Critical LVs

     sccli>"

The Primary/Secondary controller can be identified by either of the following methods:

1. By Checking the controller's green LED.

The primary controller's LED continuously blinks, while the secondary controller's LED is steadily ON.

2. Telnet/user serial connection to the controller.

In the main menu check under "System Information" where it shows the primary controller in either slot A or B.

Slot A = the top slot

Slot B = the bottom slot

References

This solution has no attachment