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-71-1010599.1
Update Date:2009-01-05
Keywords:

Solution Type  Technical Instruction Sure

Solution  1010599.1 :   Sun StorEdge[TM] 3510/3511 FC Array: Scgdevs cluster command may cause SE3510 arrays to reset.  


Related Items
  • Sun Storage 3510 FC Array
  •  
  • Sun Storage 3511 SATA Array
  •  
Related Categories
  • GCS>Sun Microsystems>Storage - Disk>Modular Disk - 3xxx Arrays
  •  

PreviouslyPublishedAs
214582


Description
Scsi-3 reservations may be stored on the 3510/3511, causing the array to reset
when certain cluster commands such as scgdev's or scrub keys function are
issued.

Steps to Follow
This document describes Scsi-3 reservations that may be stored on the 3510/3511, causing the array to reset when certain cluster commands such as scgdev's or scrub keys function are issued.
As described in Bug ID: 4955390, customers have seen instances where the 3510
array resets after cluster commands that store persistent reservations on
the array are issued. Problem seems to manifest itself after a logical
drive in the 3510 array is modified (i.e., deleted and then recreated).

The RAID controller stores persistent reservations and keys on a reserved
area of each disk used by the logical drive that is being reserved. The
controller has some residual keys or reservations stored on the
the physical drives when the logical drive is deleted and a new one built
using the same physical drives.  The firmware attempts to use this data for
the new logical drive, but it contains invalid values resulting in
controller failure.


Symptoms on the host will include losing access to the 3510 array,
and may include the following daemon error message indicating a reservation
failure:

Oct 24 15:31:03 threeofeight-w1 Cluster.CCR: [ID 925953 daemon.warning]
reservation error(node_join) - do_scsi3_register() error for disk
/dev/did/rdsk/d95s2
Oct 24 15:31:03 threeofeight-w1 Cluster.CCR: [ID 925953 daemon.warning]
reservation error(node_join) - do_scsi3_register() error for disk
/dev/did/rdsk/d94s2

And the following, indicating lost array access:

Oct 24 15:37:21 threeofeight-w1 SUNWscsdMonitor[1150]: [ID 828762
daemon.error]
[SUNWscsd 0x1060801: Critical] <rctrl8001> Unable to inquire Raid
Controller.
Chassis FRU Item: 370-5535-02 Serial No: 00116A HW Revision: 02
Description:
SE3510 FC Chassis/backplane Vendor JEDEC ID: 0x7F7F7F01 Date: Tue Jul 29
11:13:43 2003   Chassis FRU Item: 370-5535-01 Serial No: 002493 HW
Revision: 01
Description: SE3510 FC Chassis/backplane Vendor JEDEC ID: 0x7F7F7F01 Date:
Fri
May  9 19:08:13 2003   {SN#003439}

The above mentioned problem is fixed in the 4.11I release firmware.

Notes:-

1. Even though 3510 is mentioned above, this problem can potentially happen on
   SE3511 as well.

2. This bug got fixed with Patch ID: 113724-04 which contained the 4.11I. However,
   it would be recommended that we check the latest available patch for SE3510
   and SE3511 and and apply that patch.


Product
Sun StorageTek 3510 FC Array
Sun StorageTek 3511 SATA Array

3510, 3511, cluster, scgdevs, reset, persistent reservations, scrub keys, reservation failure, lost access
Previously Published As
73109

Change History
Date: 2005-11-14
User Name: 95826
Action: Approved
Comment: - verified metadata
- changed review date to 2006-11-14
- checked for TM - none added
- checked audience : contract
Publishing
Version: 5
Date: 2005-11-14
User Name: 95826
Action: Accept
Comment:
Version: 0

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