Sun Storage 6140 Array
 
Sun Storage 6540 Array
 
Sun Storage 6130 Array
 

PLA-Support>Sun Systems>DISK>Arrays>SN-DK: 6130
 
_Old GCS Categories>Sun Microsystems>Storage - Disk>Modular Disk - 6xxx Arrays
 

Applies to:

Symptoms

After creating a remote replication set(repset), the secondary array throws the
following alarm in Common Array Manager(CAM):

Alarm Id : alarm1965
Severity : Critical
Type : 6140.ProblemEvent
Topic : REC_REMOTE_NO_LUN
Event Code : 57.66.1054
Date : 2007-04-05 13:33:38
Device : 6140array[SUN.xxxxxxxxxxx.xxxxxxxxxx]
Description : Unable to contact remote volume dcretekdr_v6 on a reachable array.

Cause

 The problem is that the heartbeat being sent to the primary array is somehow being rejected.

Solution

To resolve this issue:

• Attempt to delete the repset and recreate it
• Delete all repsets from the primary, and deactivate/activate Remote Replication. Then recreate the repsets.

If the above fails, please contact Oracle Support for further help in resolving this issue.

Additional Information
Creating a repset in the reverse direction results in an alarm similar to:

Alarm ID : alarm17
Description: Unsynchronized mirror error, local: testrep1, remote: NDF
Severity : Critical
Element : 600A0B800029838800006AA3461B641C
GridCode : 57.66.1053
Date : 2007-04-10 13:42:32

The most common symptom of this issue is the Destination Driver event below:

Date/Time: Tue Apr 10 01:44:56 EDT 2007

Sequence number: 220838
Event type: 1012
Event category: Error
Priority: Informational
Description: Destination driver event
Event specific codes: 5000205/25/0
Component type: Drive
Component location: None
Logged by: Controller in slot A


Raw data:
4d 45 4c 48 02 00 00 00 a6 5e 03 00 00 00 00 00
12 10 11 10 58 24 1b 46 13 00 00 00 00 00 00 00
06 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00
01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 04 7c 00 00
20 00 12 01 05 02 00 05 25 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
03 46 0b ec 20 00 12 81 00 00 00 00 ff 01 01 04
ee ee ee ee 00 00 05 00 02 52 25 00 02 94 05 00
02 52 25 00 07 44 05 03 20 00 12 81 02 b4 06 06
09 d8 05 03 02 b4 06 06 0c 6c 05 01 ff 06 00 00
0f 00 05 01 ff 09 00 00 00 00 00 00 0c 00 12 81
00 00 00 00 00 00 00 00 00 00 00 00




This DDE occurs on both A and B controllers, and appears to indicate:

5000205/25/0

05 cc
00 dd
02 ss
05 Sense
25 ASC
0 ASCQ
byte 175= 04
channel 5
detected by target
failed command
last error illegal request logical unit not supported

This DDE only occurs while a replication set is enabled on the secondary array.

If you delete all active replication sets(primary and secondary) for the array pair, the DDE will no longer occur, since there is no further replication activity taking place.

Experience with this problem has dictated that if the array is suffering from this condition, a simple delete and create will not fix this issue. Since we cannot reproduce the issue, we would want new instances tracked by an escalation. The escalation engineer should employ the following technique to gather more data on the problem:

1. Delete all RVM sets

2. On both controllers(on BOTH ARRAYS) set the following options in VKI_EDIT_OPTIONS
actToDq=1
traceOn 5,3
traceOn 24,3




3. Attempt to create RVM Mirror

4. If the mirror is not successful dump active trace(from each controller on both arrays).

dqprint "trace"

5. After log data is collected, escalate to LSI, providing the following additional command set
luall 0x14
luall 0x13
luall
ionShow 99
spmShow




6. Based on customer necessity, the resolution may be provided as either clearing stable storage, or resetting the array to factory defaults via
sscs(1M).


NOTE 1: Clearing stable storage removes lun mappings, array licenses, and any user created pool and profile associations with volumes. All of these will need to be put back after performing this process. It does not remove any data volumes or vdisks, nor does it change the FEID on the array(which would invalidate the current customer licenses).

NOTE 2: System reset(sscs reset -a arrayname array) resets the array back to factory defaults, much like the "sysWipe" command. This removes data partitions, mappings, pools, and profiles. It does not affect licensing.

NOTE 3: Replication will have to be re-activated after this procedure.

6130, 6140, 6540, RVM, alarm, CAM, repset, replication
Previously Published As
89108


Change History
Date: 2007-04-29
User Name: 31620
Action: Approved
Comment: Verified Metadata -
Verified Keywords -
Verified still correct for audience - currently set to contract
Audience left at contract as per FvF at
http://kmo.central/howto/content/voyager-contributor-standards.html
Checked review date - currently set to 2008-04-20
Checked for TM - ok as presented
Publishing under the current publication rules of 18 Apr 2005:
Version: 4
Date: 2007-04-27
User Name: 31620
Action: Accept
Comment:
Version: 0

This solution has no attachment