Sun Microsystems, Inc.  Sun System Handbook - ISO 3.4 June 2011 Internal/Partner Edition
   Home | Current Systems | Former STK Products | EOL Systems | Components | General Info | Search | Feedback

Asset ID: 1-72-1011457.1
Update Date:2010-08-26
Keywords:

Solution Type  Problem Resolution Sure

Solution  1011457.1 :   Sun StorEdge[TM] 6130/Sun StorageTek[TM] 6140/6540: Secondary Array in Remote Replication Pair Logs Alarm Against Primary Volume  


Related Items
  • Sun Storage 6540 Array
  •  
  • Sun Storage 6130 Array
  •  
  • Sun Storage 6140 Array
  •  
Related Categories
  • GCS>Sun Microsystems>Storage - Disk>Modular Disk - 6xxx Arrays
  •  

PreviouslyPublishedAs
215699


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 : spine6140[SUN.54065460150.0648AWF0D0]
Description : Unable to contact remote volume dcretekdr_v6 on a reachable array.



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

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 Sun Services 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



Product
Sun StorageTek 6540 Array
Sun StorageTek 6140 Array
Sun StorageTek 6130 Array (SATA)
Sun StorageTek 6130 Array

Internal Comments
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

Attachments
This solution has no attachment
  Copyright © 2011 Sun Microsystems, Inc.  All rights reserved.
 Feedback