Sun Storage 3510 FC Array
 

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

On a Sun StorEdge 3510 FC array, both controllers in a dual-controller configuration may appear as "Primary", causing a race condition. Also, a controller replacement in a dual controller configuration may cause a performance impact or result in the replaced controller to be unrecognized.

One of the following four conditions can occur with this issue:

A) Neither controller will function as the primary, causing a "race condition" (also known as a "deadlock")

B) Both controllers in a dual-controller configuration appear as primary, causing the host to lose access to the LUNs.

C) A controller that has been replaced might not be recognized and can go into a failed status with an amber LED.

D) Performance slows down after controller replacement.

Note: Cases C) and D) occur when there is a controller replacement. 

This issue can occur on the following platforms:

• Sun StorEdge 3510 FC Array without firmware version 4.21

Note: This issue has been seen on SE3510 but may also occur on the SE3511.

To determine the 3510 firmware revision, run the following command:

    sccli> show inquiry
    Vendor: SUN
    Product: StorEdge 3510
    Revision: 327P
    Peripheral Device Type: 0x0

There are two possible conditions to indicate a race condition has occurred:

Normally, in a dual-controller configuration, one controller is the primary controller and the other is the secondary. The primary controller is identified by a blinking green LED, the secondary is identified by a solid green LED.

A) When replacing a failed controller, LEDs on both controllers display as solid green, indicating neither of them are the primary (also known as a "race condition" or "deadlock"). This condition may also cause issues with the serial port and not allow a telnet(1) session to the array, and the host will be unable to access the array.

Or,

B) LEDs on both controllers are blinking green (indicating that both are primary) and the host loses access to LUNs.

In the case of the unrecognized controller:

C) the affected controller has an amber LED and viewing peripheral devices indicated "Scanning"(I/O is continued, ctl+w didn't work):

    redundancy-mode
    Primary controller serial number: 8013914
    Primary controller location: Lower
    Redundancy mode: Active-Active
    Redundancy status: Scanning
    Secondary controller serial number: 0 <-- couldn't identify inserted
    controller.

In the slow performance case:

D) the array front disk LED blinks rarely every couple of seconds and host/applications may complain.

Follow the procedure given below when inserting a controller, in order to avoid the controller replacement issues:

1. Insert the controller FRU into the slot, and push forward until you begin to feel resistance as the connecting pins engage.
2. Slowly push the controller FRU the rest of the way until the connecting pins are fully seated and the RAID controller fits flush against the back plate of the RAID array.

Refer to the Sun StorEdge 3000 Family FRU Installation Guide (816-7326-19.pdf) for more details on how to install an I/O controller module.

Note: For cases A, B, and D:

A reset or power cycle may only temporarily avoid the "race condition". Resetting controller or powering-off the array also helps recover from case D.

For case C, stopping all I/O and reseating the replaced controller may help.

This issue is addressed in the following release:

• Sun StorEdge 3510 FC Array with firmware version 4.21 (as delivered in patch 113723-18 or later)

Change History

16-Jun-2005:

• Updated Impact, Contributing Factors, and Workaround sections

• Updated Contributing Factors and Resolution sections
• State: Resolved

This issue has been seen on SE3510 but may also occur on the SE3511.

This (below) applies to cases A & B only:

This issue has been filed as bug 6217572 and still under investigation by the PDE. It may be very difficult to reproduce this issue and hence it would take a lot of time to find the root cause and the same is true with the resolution.

We could reproduce a variant of the problem "a" mentioned above seen at customer place. The details are in the bug report. What we found out was that if there is a controller failure and when we do the controller replacement, if the replacement controller came from a standalone unit "and" the replacment controller is configured as be active controller only (with redundant controller option disabled) then upon replacement both controllers would want to be active and freeze the box. This problem was reproduced in the PTS and the engineering lab too. However, with the customer system, the problem was resolved after the reset whereas in our test cases, the problem still remained after the array reset and only after the controller was pulled out, the problem went away.

For additional information, please see SRDB 79042 at http://sunsolve.central.sun.com/search/document.do?assetkey=1-25-79042-1

Cases C & D can occur when inserting a new controller with excessive insertion force and speed.

This solution has no attachment