Sun Storage 2540-M2 Array
 
Sun Storage 2530-M2 Array
 
Sun Storage Common Array Manager (CAM)
 

PLA-Support>Sun Systems>DISK>Arrays>SN-DK: ST25xx
 

In this Document

Goal

Solution

References

Oracle Confidential PARTNER - Available to partners (SUN).
Reason: This document includes internal shell commands that cannot be used by customers or non trained Oracle engineers.

Applies to:

Goal

This document provides the steps to follow to recover a Sun Storage 2500-M2 Array that has been downgraded by mistake from firmware 07.84.xx.xx to 07.80.xx.xx.

New Sun Storage 2500-M2 arrays are delivered with firmware 07.84.xx.xx, which requires Sun Storage Common Array Manager (CAM) 6.9 as well as specific patches. Refer to <Document 1526721.1> Minimum Sun Storage Common Array Manager (CAM) Release Supported with Firmware 07.84.xx.xx.

If these requirements are not followed and the user proceeds with the "Upgrade Firmware Baseline" procedure in CAM, the array can be downgraded by mistake to 07.80.xx.xx. Because firmware 07.80.xx.xx is not supported with the DACstore in the drives that arrived with 07.84.xx.xx, the firmware downgrade will hang and CAM will timeout the procedure, leaving controller A with firmware 07.80.xx.xx and unable to boot, while controller B still has firmware 07.84.xx.xx. At this time, two possible scenarios can occur:

Scenario A: If the user does not attempt any other manipulations, controller A will have firmware 07.80.xx.xx and controller B will have 07.84.xx.xx. The signature for this issue is described below.

Scenario B: If the user power cycles the array, both controllers reboot and controller B auto-syncs with controller A. At that time both controllers are running firmware 07.80.xx.xx, and this alarm code is raised: 93.66.1204 "Tray.X.Drive.Y has DACstore data written by a later revision of firmware than exists on this array".

This document only applies to the above scenario A. If the issue is related to scenario B, please refer to <Document 1527751.1> Sun Storage Common Array Manager (CAM) Reports the Alarm "Tray.X.Drive.Y has DACstore data written by a later revision of firmware than exists on this array".

Here is the signature for the issue described in the above scenario A.

• When looking at storageArrayProfile.txt, the following output can be observed:
      
  
  Current configuration
        Firmware version:             07.84.44.10
        NVSRAM version:               N2540-784843-003
     Pending configuration
        Staged firmware areas are valid and can be activated: true
        Firmware version:             07.50.33.0a
        NVSRAM version:               4e.32.35.34.30.2d.37.38.30.38.34.33.2d.30.30.38.00
        Tranferred on:                Wed Jan 09 15:39:14 GMT 2013
  
     Tray.99.Controller.A
        Status:                        Optimal
        Current configuration
           Firmware version:
              Appware version:         07.80.51.10
              Bootware version:        07.80.51.10
  
     Tray.99.Controller.B
        Status:                        Optimal
        Current configuration
           Firmware version:
              Appware version:         07.84.44.10
              Bootware version:        07.84.44.10
   

Solution

The array configuration will need to be wiped after completing this solution. A remote connection (Webex or SharedShell) to the CAM server will be required. If a remote connection is not authorized by the customer, dispatch a Field Engineer (FE) onsite with the action plan.

1. Enable the telnet port on controller B (which is still running 07.84.xx.xx), by executing the following command on the CAM server:
   
   
   # service -d <arrayname> -c enable -t b -q remote
     
   The `service` command is under:
   Solaris: /opt/SUNWsefms/bin/
   Linux:  /opt/sun/cam/private/fms/bin/
   Windows: C:\Program Files\Sun\Common Array Manager\Component\fms\bin\
    
2. Telnet to controller B.
   
   
   Telnet access (username/password) will not be documented. If you received the appropriate training mentioned above you should know it; otherwise please open a collaboration with TSC L2.
    
3. Execute the following commands on controller B in order to wipe the array configuration. Both controllers A and B will reboot.
   
   -> loadDebug
   -> sysWipeAllConfigData
     
   
   Example:
   
   -> sysWipeAllConfigData
   Executing configuration reset. Boards will reboot on completion.
   01/09/13-16:29:31 (tShell0): WARN:  resetConfiguration, Exception: IconSendInfeasibleException Error caught trying to clear alt
   01/09/13-16:29:31 (tShell0): WARN:  PSTOR wipe for alternate controller failed. Run pstorWipeAllConfigData on alternate controller
    
4. After the controller reboots complete, both controllers A and B should be running 07.80.xx.xx and the DACstore revision on the drives should be 6.0. Confirm the DACstore revision with the following command:
   
   -> dsmShow
     
   
   Example:
   
   -> dsmShow
   Current Drives (12):
   ptr       Devnum     Drv Cap       Size(Mb) Rev   Lo   MT  WWN
   0x15a6980 0x00010009 0x00022ecb25c 512      (6.0) ( 0) 256 5000c50039b506b30000000000000000
   0x15a6d00 0x00010005 0x00022ecb25c 512      (6.0) ( 0) 256 5000c5003a2ad07b0000000000000000
   0x15a6c20 0x00010006 0x00022ecb25c 512      (6.0) ( 0) 256 5000c5003aadad430000000000000000
   0x15a6b40 0x00010007 0x00022ecb25c 512      (6.0) ( 0) 256 5000c5003aadb14b0000000000000000
   0x15a67c0 0x0001000b 0x00022ecb25c 512      (6.0) ( 0) 256 5000c5003aadb7530000000000000000
   0x15a68a0 0x0001000a 0x00022ecb25c 512      (6.0) ( 0) 256 5000c5003aadbae70000000000000000
   0x15a7160 0x00010000 0x00022ecb25c 512      (6.0) ( 0) 256 5000c5003aadbc570000000000000000
   0x15a6de0 0x00010004 0x00022ecb25c 512      (6.0) ( 0) 256 5000c5003ab475f70000000000000000
   0x15a6fa0 0x00010002 0x00022ecb25c 512      (6.0) ( 0) 256 5000c5003ab4782b0000000000000000
   0x15a6a60 0x00010008 0x00022ecb25c 512      (6.0) ( 0) 256 5000c5003ab479b70000000000000000
   0x15a6ec0 0x00010003 0x00022ecb25c 512      (6.0) ( 0) 256 5000c5003ab47a070000000000000000
   0x15a7080 0x00010001 0x00022ecb25c 512      (6.0) ( 0) 256 5000c5003ab47aaf0000000000000000
   
   212 objects on UnusedDrives list
   
   value = 0 = 0x0
   ->
      
   
   In rare situations, after both controllers reboot, controller A will be online and controller B offline/failed. In these situations, execute the shell command cmgrSetAltToOptimal from controller A to bring controller B online.
     
   
   
5. Close the telnet port on controller B by executing the following command on the CAM server:
   
   # service -d <arrayname> -c disable -t b -q remote
     
   
   

References

This solution has no attachment